Separating Authoratative and Resolving Servers, and DNSSEC

[Kevin Darcy]

Curt Sampson wrote:
> What's the current stance on running separate versus combined
> authoratative and resolving servers on trusted hosts? My authoratative
> name servers also deal with mail, monitoring, and a few odd sysadmin
> things, but have no login accounts other than sysadmins, and no web
> servers or other such fairly dodgy public services.
>
> Using BIND 8, for the obvious reasons, I always ran two name
> servers, a resolving one listening on localhost and an authoratative
> (non-resolving) one listening on all other interfaces.
>
> Since I upgraded to BIND 9, I've been using a single nameserver with
> an access list limited to localhost for resolving queries. Is this
> sensible, or ought one, despite this feature, still be running separate
> instances of bind for authoratative stuff? I notice that BIND does serve
> material from the cache even to outside queries, which is probably not a
> good thing.
>
>   
Yes, you should have separate caches, and disable recursion for 
untrusted hosts, while keeping it enabled for hosts you trust, but with 
BIND 9, this does *not* require you to run separate nameserver 
instances. You can instead use the "view" feature to present separate 
caches/namespaces to different queries, based on their source address or 
address range, the destination address of their queries (for multi-homed 
nameservers/resolvers), whether the queries are recursive or not, or 
whether they are signed with a particular TSIG key or not. See the BIND 
9 documentation. One "view" is typically for authoritative zones only, 
with recursion turned off, and another "view" can be for your own 
clients with recursion turned on and perhaps just a "hints" file defined 
and nothing else. The caches for the respective views will never overlap 
or intermingle.

Note that view-matching proceeds in sequence, so your more specific 
views would typically be first in named.conf, and the "default" view 
would be at the bottom, with perhaps a "match-clients { any; };" to 
catch anything that wasn't defined above it. Once a view is matched, no 
other view is consulted. This implies that names you want to be visible 
in both/all views might need to be a) resolvable from one view to 
another, which shouldn't normally be a problem, since the recursive view 
can just query the other view and pass back the answer (although NAT, as 
is often the case, may throw in a monkey wrench here), or b) defined and 
maintained in the relevant zone(s) in parallel in multiple views, e.g. 
an "internal" version of example.com defined in the "internal" view for 
the consumption of internal clients, and an "external" version for 
external clients.

- Kevin