UNIX System Administration Handbook - Evi Nemeth [273]
It is a common error to include glue records for hostnames that don’t need them. For example, ns.xor.com in the example above can be resolved with a normal DNS query. An A record would initially just be unnecessary, but it could later become downright misleading if ns.xor.com’s address were to change. The rule of thumb is to include A records only for hosts that are within the current domain or any of its subdomains. Current versions of BIND ignore unnecessary glue records and log their presence as an error.
The scheme just described is the standard way of connecting zones, but it requires the child to keep in touch with the parent and tell the parent about any changes or additions to its name server fleet. Since parent and child zones are often run by different sites, updates are often a tedious manual task that requires coordination across administrative boundaries. A corollary is that in the real world, this type of configuration is often out of date.
The second way to maintain links is to use stub zones. Stub zones are fully supported in BIND 8, but were also available in BIND 4 (though documented as being experimental). A stub zone is essentially the same thing as a slave zone, but it includes only the zone’s NS records.
Stub zones work fine in BIND 8, which mixes different zones’ data in memory, but they don’t work as well with BIND 9. In BIND 9, the stub zones must be configured identically on both the master and slave servers of the parent, something that is in itself hard to keep consistent. Your best bet is to just keep in touch with your parent domain and to verify its configuration at least a couple of times a year.
You can use the dig command to see which of your servers your parent domain is currently advertising. First run
dig parent-domain ns
to determine the name servers for your parent domain. Pick one and run
dig @name-server.parent-domain child-domain ns
to see your list of public name servers.
One situation in which stub zones are very useful is when your internal addressing uses the RFC1918 private address space and you need to keep the RFC1918 delegations in sync. The BIND 8 distribution contains an example in src/conf/recursive.
A couple of stub zone subtleties are worth mentioning:
• Stub zones are not authoritative copies of the zone’s data, and stub servers should not be listed among the zone’s NS records.
• Since stub servers are not listed in NS records, they are not notified automatically when the zone’s data changes. To update stub servers, you can either add an also-notify clause to the configuration of the master servers, or you can simply wait for the zone to be updated at the end of the refresh interval specified in the zone’s SOA record. The timeout option should work just fine in most cases, though it can potentially result in transitory lame delegations (see page 478).
• Theoretically, it’s no use for named to have copies of a zone’s NS records if it cannot also obtain the matching A records. However, named can bootstrap itself by using the master’s IP address, which is given in named.conf.
• Why limit yourself to NS records? Why not just be a secondary server for the subdomains? This works, too. However, if every server of the parent domain is also a server of a child domain, then no referrals will ever be made to downstream servers. The parent domain’s servers will be providing all the DNS service for the subdomain. Perhaps this is what you want, and perhaps not.
16.12 UPDATING ZONE FILES
When you make a change to a domain (such as adding or deleting a host), the data files on the master server must be updated. You must also increment the serial number in the SOA record for the zone and then run ndc reload to signal named to pick up the changes. You can also kill and restart