BIND Zone Merging and Other Issues

[Kevin Darcy]

Merton Campbell Crockett wrote:
> After years and a number of mergers, I've been asked to take over the  
> corporate DNS.  I have proposed some minor changes that would improve  
> responsiveness but have met some resistance.  I suspect that the  
> resistance is based on the way BIND used to work.
>
> BIND Zone Merging
>
> In earlier versions of BIND, child zone data would be merged into the  
> parent zone.  For example, if you had a 10.IN-ADDR.ARPA zone defined  
> containing delegation records, data from the delegated zones would be  
> merged into 10.IN-ADDR.ARPA zone.  In which version of BIND did this  
> stop?
>
> BIND RFC 1918 Built-in Feature
>
> If you are not using RFC 1918 private addresses, BIND will return  
> NXDOMAIN and not forward the query to the root servers.  In which  
> version of BIND did this become a standard feature?
>
> If a name server is the master for 96.168.192.IN-ADDR.ARPA, is this  
> built-in feature disabled for all RFC 1918 address ranges or just the  
> 168.192.IN-ADDR.ARPA zone address range?
>
> If named.conf includes a global forwarders statement, is the RFC 1918  
> built-in feature disabled when no RFC 1918 zones are defined?
>
> BIND Global Forwarders Statement
>
> The current DNS architecture is based on forwarding DNS queries to  
> three regional DNS servers.  All name servers that are in the Western  
> US, forward all queries to the Western US "master" name server.  If it  
> is inaccessible, they will fall back to the Central US and then the  
> Eastern US "master" name servers.
>
> I understand why one might want to do this for Internet DNS queries.   
> I have issues with this for internal DNS queries.  The "master" name  
> servers are all located at the sites with the highest volume of  
> network activity, i.e. the most overloaded sites.  Wouldn't it be  
> better to have each name server download the delegation information  
> from the "master" name servers and use BIND to determine the "best"  
> server to query?
>
> 	zone 10.IN-ADDR.ARPA {
> 		type		slave;
> 		forwarders	{ none; };
> 		file		"slave/arpa.in-addr.010";
> 	};
>
> 	zone CORPORATION.COM {
> 		type		slave;
> 		forwarders	{ none; };
> 		file		"slave/com.corporation";
> 	};
>
> Assuming that zone information is not merged, wouldn't the above  
> provide a more robust DNS architecture and reduce, to some extent, the  
> volume of traffic sent to the "master" name servers?
>
>
> Diatribes on the "evils" of forwarding are understood but not needed.   
> I am looking for information that will produce a more robust solution.
>   
One thing you didn't make clear is whether this infrastructure needs to 
resolve Internet queries or not. If it doesn't, then there should be no 
need for "global" forwarding at all, and you won't need "forwarders { 
none; };" in your slave-zone or stub-zone definitions. You do, however, 
need "masters" clauses, as Mark pointed out.

The decision whether to use slave or stub zones is driven by a number of 
factors: size of zone, how frequently it changes, desired propagation 
rate of changes versus available bandwidth, TTLs of records in the zone, 
profile of how your clients access those records over time, etc. If you 
need the redundancy of having full, local copies of the zone on remote 
servers, then obviously your only choice is slaving, but since you 
presumably haven't had that redundancy up until now (since you've been 
using forwarding), your main focus may be performance and/or bandwidth 
consumption, in which case you should look at the other factors.

Forwarding may even have a place, in very specific situations, but as 
usual, my advice on that is "try it and see if it helps performance". 
There are too many variables to really be able to accurately model that 
ahead of time.

- Kevin