BIND Zone Merging and Other Issues

[Mark Andrews]

> 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 9.
 
> 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?

	It hasn't yet.  It's still awaiting the draft to make its
	way out of dnsops.  To enable it remove the "#ifdef notyet"
	and matching "#endif" from bin/named/server.c.
 
> 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?

	The presence of 96.168.192.IN-ADDR.ARPA will hide te presence
	of 168.192.IN-ADDR.ARPA for queries ending in
	96.168.192.IN-ADDR.ARPA.  This allows 1.1.168.192.IN-ADDR.ARPA
	to still be caught locally.

	If you were to add 168.192.IN-ADDR.ARPA then the automatic empty
	zone would not be created.
 
> 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?

	Yes.  That or stub zones.  Don't forget the "masters" clauses
	which you missed above.
 
> Diatribes on the "evils" of forwarding are understood but not needed.   
> I am looking for information that will produce a more robust solution.

	The most robust solution is to remove forwarders all together.
	You then graft on the local namespaces using slave, stub or
	master zones.
 
> Merton Campbell Crockett
> m.c.crockett at roadrunner.com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org