BIND Zone Merging and Other Issues

[Merton Campbell Crockett]

On 03 Jul 2008, at 13:38:45, Kevin Darcy wrote:

> 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 infrastructure does need to resolve Internet queries.

My bad!  I should have put the masters statements in the example.


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


In the existing DNS architecture, each name server only has the IN- 
ADDR.ARPA zone(s) and the CORPORATION.COM zone(s) used at the site.   
Running on the same system as the name server is the site's DHCP server.

	zone 200.9.10.IN-ADDR.ARPA {
		type		master;
		file		"arpa.in-addr.010.009.200";
	};

	zone SITE.CORPORATION.COM {
		type		master;
		file		"com.corporation.site";
	};

All queries that can't be resolved locally are forwarded to the  
"master" name servers for resolution.  The "master" name servers are  
defined as secondary name servers for all zones that are in use.

The "master" name servers are located at key sites that, also, support  
Exchange servers, Oracle databases, etc., i.e. the circuits will,  
inherently, be congested.

The corporate network is implemented using dynamic multi-point VPN  
tunnels.  Due to a given Internet Service Provider's trunk topology  
and network exchange points, a site in the Western Region might be  
closer to the Eastern Region based on RTT.

The "top level" zones only contain the NS records for the subdomains  
in use.  The reason for allowing a site to transfer these zones is two- 
fold.  First, it allows the site's local name server to use BIND's RTT  
logic to select the "best" name server to use for an internal zone and  
eliminate some problems with circuit outages.  Second, it allows the  
local name server to return NXDOMAIN instead of forwarding queries for  
non-existent internal zones.


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




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