UNIX System Administration Handbook - Evi Nemeth [274]
Earlier versions of BIND used signals and the UNIX kill command to control named, but just as the developers started running out of signal numbers, ndc came along and fixed it all. Most of the historical signal stuff in BIND (except for the HUP signal to reread the configuration file and the TERM signal to die) is likely to go away in future releases, so we recommend sticking with ndc.
The updated zone data is propagated to slave servers right away because the notify option is on by default. If you have inadvertently turned this option off, your slave servers do not pick up the changes until after refresh seconds, as set in the zone’s SOA record (typically one to six hours later). If you want a more timely update when the notify option is turned off, ndc reload on a slave causes it to check with the master, see that the data has changed, and request a zone transfer.
Don’t forget to modify both the forward and reverse zones when you change a hostname or IP address. Forgetting the reverse files leaves sneaky errors: some commands work and some won’t.
Changing the data files but forgetting to change the serial number makes the changes take effect on the master server (after a reload) but not on the slaves.
It is improper to edit data files belonging to slave servers. These files are maintained by named; sysadmins should not meddle with them. It’s fine to look at the data files as long as you don’t make changes. They can often reveal hidden errors in the zone files. For example, a pesky missing dot that’s easy to overlook in the master’s config files can result in obviously bogus entries such as
foo.cs.colorado.edu.cs.colorado.edu
appearing in the data file of a slave.
BIND allows zone changes to be made through a programmatic API, as specified in RFC2136. This feature, called dynamic update, is necessary for autoconfiguration protocols like DHCP. The dynamic update mechanism is described on page 459.
Zone transfers
DNS servers are synchronized through a mechanism called a zone transfer. The original DNS specification (and BIND 4) required all zone data to be transferred at once. Incremental updates were eventually defined in RFC1995 and implemented in BIND 8.2. Original and incremental-style zone transfers are sometimes referred to as AXFR and IXFR, respectively. Once configured, they’re supposed to be equivalent.
A slave that wants to refresh its data requests a zone transfer from the master server and makes a backup copy of the zone data on disk. If the data on the master has not changed, as determined by a comparison of the serial numbers (not the actual data), no update occurs and the backup files are just touched (that is, their modification time is set to the current time).
Zone transfers use the TCP protocol on port 53 and log information through syslog with the tag “named-xfer.” IXFR as specified by the IETF can use either TCP or UDP, but BIND has only implemented it over TCP.
Both the sending and receiving server remain available to answer queries during a zone transfer. Only after the transfer is complete does the slave begin to use the new data. BIND 8 actually calls a separate named-xfer program to perform the transfer, but BIND 9’s named handles the transfers directly. Therefore, the named-xfer option that specified the path to the named-xfer program is no longer part of the configuration language for BIND 9.
When zones are huge (like com) or dynamically updated (see the next section), changes are typically small relative to the size of the entire zone. With IXFR, only the changes are sent (unless they are larger than the complete zone, in which case a regular AXFR transfer is done). The IXFR mechanism is like the patch program in that it applies differences to an old database to bring it into sync with a new database.
In BIND 8, you enable IXFR by telling named to keep a transaction log in the global options section and then turning it on in the server statements for any servers that use it.