About root zones

[Kevin Darcy]

On 1/2/2012 5:42 AM, Matus UHLAR - fantomas wrote:
>>> On 21.12.11 19:21, Peter Andreev wrote:
>>>> All these servers are slaves. They don't send notifies.
>
>> 2011/12/21 Matus UHLAR - fantomas <uhlar at fantomas.sk>:
>>> they do, unless you have turned it off...
>
> On 22.12.11 11:54, Peter Andreev wrote:
>> Of course I turned it off, it's normal practice for slaves, I assume.
>
> even sending notifies by slaves can have a reason. for example, other 
> slaves not getting notifies from master...
>
>>> Do you think if server needed to resolve something, and you would 
>>> disable
>>> it, it would work better? I think just the oposite. If a server does 
>>> lookups
>>> only when needed, then disabling required lookups would make it not 
>>> working.
>
>> I think that if server is authoritative - and - slave-only it should
>> use system resolver rather than querying by itself.
>
> 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.
>
I agree with Matus. BIND should be as self-sufficient as possible, and 
not make any assumptions about the capability of and/or the data it 
expects to get from the system resolver, which might be configured to 
look at a completely different DNS namespace, or be configured with 
non-DNS resolution methods, be broken with respect to IPv4/IPv6 
capabilities, address sorting, etc. There's lot that can go wrong when 
you make one subsystem (BIND-based DNS) dependent on another (system 
resolver, however that's set up, if it's set up at all). BIND already 
has ways to resolve names, and many different ways to precisely control 
how it does that, so it shouldn't be necessary to rely on a completely 
different subsystem for that function.

Now, what are your real complaints about an authoritative-only 
nameserver making "internal" queries? Looking back through the thread, I 
think there are two:

1) That internal lookups are generated when sending NOTIFYs. Do you 
actually need to send those NOTIFYs, or are you just leaving things with 
the default configuration (which follows the RFC 1996 algorithm of 
looking at the contents of the zone's NS records and its SOA.MNAME)? If 
you need those NOTIFYs at all, I expect that you could suppress the 
associated lookups with a combination of "also-notify" and "notify 
explicit". Then BIND only has a list of IP addresses to which to send 
NOTIFYs and I can't (offhand) see any reason for it to generate 
"internal" lookups. I haven't tested this theory, but it shouldn't be 
hard to do. Another thing to consider: even with the default NOTIFY 
behavior, named shouldn't need to generate lookups for any of the names 
associated with the NOTIFYs which are in zones for which it is 
authoritative. E.g. if you're authoritative for example.com and 
ns1.example.com is a name within that zone, then you shouldn't need to 
generate a lookup for that name if you want to send a NOTIFY to it. 
Moreover, since NS targets tend to "cluster" within groups of zones 
under common administrative control, it should only be a fairly small 
minority of NS targets which require internal lookups for NOTIFY 
purposes. Is this really a problem then?

2) "upwards referrals". If your recursion-disabled nameserver is 
configured to respond to queries outside of its authoritative zones, 
then the typical response would be an "upwards referral" to the root 
zone. But to give good, current information about the root zone, when 
the root zone is explicitly or implicitly defined with only "hints", a 
"priming" query needs to be made when named starts up (since "hints" are 
only "hints", not the real data, which is obtained by querying the 
roots). Someone mentioned defining your own root zone authoritatively 
with localhost as the only root nameserver. But that's a really bad idea 
if you're giving out upwards referrals to arbitrary Internet resolvers. 
You could poison the cache of some really old, broken nameserver. The 
link that David Forrest gave to a DNS-OARC webpage pretty much runs down 
the whole "upwards referral" issue, and I recommend you read it. You 
could combine defining your own root zone authoritatively (which will 
suppress the priming query), with carefully controlling access to that 
zone (as described on that webpage) so that no upwards referrals are 
given. I wouldn't recommend populating that root zone with "garbage" 
(such as localhost, for example); I'd put real root-zone information in 
there, just in case the ACLs in named.conf get accidentally reconfigured 
some day (perhaps by whomever inherits your config). That root-zone data 
gets stale over time, of course, but it takes many many years for it to 
become completely invalid, and if you're concerned about that, you could 
write a simple script to do a root zone query periodically (e.g. 
monthly) and refresh the contents of the zone file. Or, you could just 
let ISC do the work of compiling the latest root-zone data into each 
version of BIND they put out, and not worry so much about an occasional 
priming query.

I think the main issue here is that you got a user problem report of 
"bad DNS data" without any specifics or reproducibility, and you're 
just, frankly, grasping at straws trying to find a explanation and/or a 
solution. I can assure you, there are many thousands of sites that allow 
their "authoritative-only" BIND nameservers to perform "internal" 
queries, and never have a problem with "bad data" being presented 
randomly to users. Conversely, this is the first time I've heard anyone 
complain that the "internal" queries of an "authoritative-only" BIND 
nameserver might possibly, potentially have led to some sort of data 
inconsistency problem. So, unless you can actually identify a real 
problem here, I'd stop worrying about these "internal" queries. 
Eliminating them seems more a classic case of "a solution looking for a 
problem" rather than the other way around, and in order to "fix" things, 
you may end up making your configuration so twisted and convoluted, 
chances are you'll inadvertently introduce other, real problems that 
will affect your users negatively. Sometimes the wisest choice an IT 
and/or Network admin can make is to leave messy "imperfect" behavior alone.

There are other explanations of "bad DNS data" besides BIND as well. You 
need to look at the entire environment, every component, every step in 
the process. In most cases I've run across this symptom, it's because 
certain flavors of VPN software violate one of the fundamental 
principles of DNS resolution -- they fail over to another resolver when 
they get an NXDOMAIN or NODATA response (which they shouldn't do, since 
NXDOMAIN/NODATA are perfectly-valid responses in and of themselves). 
They then cache data from that failover lookup which can have a negative 
effect on future lookups. This is further exacerbated if their 
"failover" resolver(s) is/are run by evil ISPs that do "NXDOMAIN 
redirection" (Google that if you're not familiar with the 
concept/practice). So, you need to look further afield for the real root 
cause of the problem, rather than obsessing over the fact that an 
"authoritative-only" BIND instance, in the absence of a lot of custom 
configuration, still generates a few queries here and there for internal 
purposes, and thus is not *perfectly* "authoritative-only".

                                                                         
                                                     - Kevin