BIND Zone Merging and Other Issues
Merton Campbell Crockett
m.c.crockett at roadrunner.com
Thu Jul 3 05:01:59 UTC 2008
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
More information about the bind-users
mailing list