About root zones

[Peter Andreev]

2012/1/3 Lyle Giese <lyle at lcrcomputer.net>:
> On 01/03/12 07:53, Peter Andreev wrote:
>>
>> 2012/1/2 Matus UHLAR - fantomas<uhlar at fantomas.sk>:
>>>>>>>
>>>>>>> On 21.12.11 19:21, Peter Andreev wrote:
>>>>>>
>>>>>>
>>>>>> I think that if server is authoritative - and - slave-only it should
>>>>>> use system resolver rather than querying by itself.
>>>
>>>
>>>
>>>> 2012/1/2 Matus UHLAR - fantomas<uhlar at fantomas.sk>:
>>>>>
>>>>>
>>>>> BIND will not use system resolver. BIND is the resolver. Relying on
>>>>> other
>>>>>
>>>>> resolver could cause troubles. If BIND does not need to resolve, it
>>>>> will
>>>>> not. If it needs, don't block it.
>>>
>>>
>>>
>>> On 02.01.12 16:42, Peter Andreev wrote:
>>>>
>>>>
>>>> I understood your point, however it differs from mine.
>>>>
>>>> Matus, I'm afraid we won't find consent on this topic. So I offer you
>>>> to stop this discussion.
>>>> Thank you for suggestions and happy new year!
>>>
>>>
>>>
>>> I don't see your point now. I'm afraid that you will have to live with
>>> the
>>> fact that you can not disable sending queries from BIND when it needs
>>> them,
>>> you can only prevent it by configuring BIND (so it will not need them) or
>>> firewall such packets so they will not get outside (which may break its
>>> functionality).
>>
>>
>> My point: I need my servers to answer with authoritative data only. I
>> need them to not perform anything else. Only "get query - send
>> authoritative response". Where in this scenario BIND has to resolve
>> something?
>> In which scenario (except master&  notifies) BIND has to resolve
>> something?
>>
>>
>>>
>>> Maybe ISC will patch BIND to use system resolver for internal queries,
>>> but I
>>> doubt so. Maybe you can do it but imho it's not worth trying.
>>>
>>> Maybe you can set up forward only; and forwarders {}; so BIND will
>>> forward
>>> all recursive queries it generates to your recursive servers.
>>>
>>> But the way you are trying to get over this, I'm afrait you will fail and
>>> that's what I am trying to tell you.
>>
>>
>> I'm free to replace BIND with another authoritative DNS implementation.
>>
>>>
>
> Let me ask this question another way.  How do you plan to block BIND from
> making any queries outside the server?  If you want me to log any queries
> that I don't answer(refused in the logs), I think the default is to look up
> the reverse of the querying IP address.  Do you want to block that type of
> traffic also?
>
> Do you want to block this traffic at the application level or in IPTables?
>  If you block this traffic via IPTables or an external firewall, lots of
> things at the OS level get grumpy.
>
> For instance, I want to attach to the server using VNC or SSH for
> maintanence.  By default, they want to do do a reverse lookup of your ip
> address before allowing access.  Now you wait for that query to time out
> before you can do your work.  That's just a PITA.
>
> And if Bind does want to do any lookups(reverse lookups, go query the root
> servers for something), now you are forcing it to timeout rather than doing
> the lookup and continuing on it's way.  Very inefficient use of resources
> and will cause delays for legit queries.
>
> BIND was designed to be a multipurpose application and as such, it wants and
> is happier being able to do lookups as needed.  You are asking for a
> specific use case and ISC is not into generating special builds for special
> or specific use cases unless you contract with them to build and maintain
> your special build of BIND.

You are absolutely right, BIND is a general purpose DNS server and it
plays its role well. Furthermore BIND is the de facto standard (yes, I
copypasted this phrase from wikipedia). And both these statements are
true.
Unfortunately as I learning BIND more, I understand that it is not
very suitable for my requirements.

>
> Lyle Giese
> LCR Computer Services, Inc.
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
--
AP