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/";
> };
> 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 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.

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.

- Kevin