UNIX System Administration Handbook - Evi Nemeth [251]
named normally figures out which machines are slave servers of a zone by looking at that zone’s NS records. If also-notify is specified, a set of additional servers that are not advertised with NS records can also be notified. This tweak is sometimes necessary when your site has internal servers. Don’t also-notify stub servers; they are only interested in the zone’s NS records and can wait for the regular update cycle.
See page 456 for more information about stub zones.
BIND 4 servers do not understand notification messages. They log an error and wait for the refresh interval prescribed in the zone data (see page 438) to expire before updating themselves. The localhost reverse zone is also a good place to turn notification off.
recursion yes | no; [yes]
allow-recursion { address_match_list }; [all hosts]
The recursion option specifies whether named queries other name servers on behalf of clients, as described on page 406. It’s fairly unusual to configure a name server with recursion off. However, you might want to allow recursion for your own clients but not for outside queries.
Recursion can be controlled at a finer granularity with the allow-recursion option and an address list that includes the hosts and networks on whose behalf you are willing to perform recursive queries.
use-id-pool yes | no; [no (V8 only)]
In BIND V8, this option causes named to keep track of outstanding query IDs so that it doesn’t issue duplicates and so that the sequence of IDs it issues can be more random. It helps prevent DNS spoofing. If you turn it on, expect named to use a bit more memory. The feature is worth the extra memory cost, however; we recommend that you use this option. In BIND 9, the use-id-pool option is gone and named always manages its query IDs this way.
maintain-ixfr-base yes | no; [no, V8 only]
Incremental zone transfers (see RFC1995) allow servers to send out “patches” to a zone when it changes instead of resending the entire zone. For a zone like com, this incrementality is very important. The current release of BIND 8 allows incremental zone transfers for any zone that does dynamic updates; it keeps a transaction log file if maintain-ixfr-base is set to yes. BIND 9 always maintains a log. Zone transfers on page 458 covers incremental zone transfers in more detail.
check-names { master|slave|response action } [see text]
BIND has included code to check the validity of hostnames since version 8—not in the sense of “Does this host exist?” but in the sense of “Does this hostname actually follow the rules specified in the RFCs for hostnames?” A surprising number of them don’t. A name is valid if it contains only letters, numbers, and dashes and is no longer than 64 characters per component (including the dot) and 256 characters overall. The rules for names and the distinction between the host portion and the domain portion are subjects of current debate. Internationalization of the DNS system and support for non-ASCII character sets might change all the naming rules.
You can specify the check-names behavior globally and also individually for each zone; a zone specification overrides the global values. You can apply the option to master servers, to slave servers, or to the answers returned in response to queries. Each type has three possible action values:
• ignore – do no checking
• warn – log bad names, but continue processing
• fail – log and reject bad names
The default for the master is to fail, since errors on the master are likely to be typos or noncompliant names that the sysadmin should fix. A site should not knowingly propagate noncompliant names. The default for slave servers is to warn, and the default for responses is to ignore. The default values are just right; you should not need to change them.
check-names