BIND Zone Merging and Other Issues
Mark Andrews
Mark_Andrews at isc.org
Thu Jul 3 05:33:03 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 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
More information about the bind-users
mailing list