Separation of authoritative and recursive functions

[Kevin Darcy]

Niall O'Reilly wrote:

>On 5 Jul 2005, at 08:08, Stephane Bortzmeyer wrote (perhaps as a
>rhetorical question?):
>
>  
>
>>But I wonder if there is today, with the current BIND, a specific
>>technical reason to do so (such as a known security issue) or if it is
>>just good practice to put widely different functions on different
>>servers, just in case.
>>    
>>
>
>And on 5 Jul 2005, at 08:44, Mark Andrews, answering Stephane, chose not
>to grasp this particular nettle.  I can't fault him for that choice.
>
>I think it would be good if one or two people who know more about this
>issue than I do could answer the question Stephane raises, focusing, as
>he does, on the _current_ BIND.
>
>I'm sure there are a couple of such people out there. 8-)
>
>As for me, I find it useful to draw a line between
>
>	(a) advertising the domains for which I am responsible, and
>
>	(b) providing a name-resolution service to customers on the
>		networks for which I am responsible.
>
>The few servers I'm involved with provide one or other of these 
>services,
>but not both.
>
>My 'a' servers are advertised in the parent zone and in the zone(s) for
>which they provide service, are authoritative, do not provide recursion,
>and are publicly accessible.  After all, we want the world to be able to
>find us.
>
>My 'b' servers are advertised internally using DHCP and 
>customer-directed
>documentation, are recursive, may carry 'stealth' authoritative copies 
>of
>internal zones, and refuse queries from outside the networks for which
>they provide service.
>
Well, you can separate those functions at the view (query source 
address, query destination address, or TSIG-key) level, the 
listen-address level, or -- as you have indicated -- by putting the 
respective functions on different machines or sets of machines. None of 
this requires that there be separate *programs* for the two different 
functions, as the context of Stephane's message implied. When 
considering the value of having separate programs for these functions, 
one has to weigh the potential performance/efficiency benefits of 
separation (which seem to me to be rather elusive, except in special 
high-volume and/or mission-critical situations like serving Internet 
TLDs or whatnot) versus the drawback of having more 
products/packages/subsystems for the admin(s) to 
install/configure/maintain/run/monitor/troubleshoot and the broader 
skill-sets required to properly do so. For most organizations and their 
requirements, I think having a single program for both functions makes 
more sense. Note that if one is using a commercial product for DNS 
management, or a "DNS appliance", one may not know or particularly care 
whether it's one program or two that is performing the functions 
"beneath the covers".

As for the relative merits of separating the functions by view, 
listen-address or physical server(s) (irrespective of the 
one-program-or-two issue), opinions differ widely on that, and each 
admin/architect needs to decide for himself/herself, based on their 
specific security/availability/performance requirements, 
fiscal/facility/address-space constraints, support infrastructure, etc.

- Kevin