BIND Zone Merging and Other Issues

[Merton Campbell Crockett]

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.


Merton Campbell Crockett
m.c.crockett at roadrunner.com