UNIX System Administration Handbook - Evi Nemeth [250]
{ ! 1.2.3.13; 1.2.3/24; };
{ 128.138/16; 198.11.16/24; 204.228.69/24; 127.0.0.1; };
The first of these lists excludes the host 1.2.3.13 but allows the rest of the 1.2.3/24 network; the second defines the networks assigned to the University of Colorado. The braces and final semicolon are not really part of the address match list, but are part of the enclosing statement that uses it.
When an IP address or network is compared to a match list, the list is searched in order until a match is found. This “first match” algorithm makes the ordering of entries important. For example, the first address match list above would not have the desired effect if the two entries were reversed, because 1.2.3.13 would succeed in matching 1.2.3/24 and the negated entry would never be encountered.
Now, on to the statements! Some are short and sweet; others almost warrant a chapter unto themselves.
The include statement
To break up or better organize a large configuration, you can put different portions of the configuration in separate files. Subsidiary files are brought into named.conf with an include statement:
include "path";
If the path is relative, then it is interpreted relative to the directory specified in the directory option (next page). A common use of the include statement is to bring in cryptographic keys that should not be world-readable. Rather than closing read access to the whole named.conf file, keys are kept in files with restricted permissions that only named can read. Those files are then included into the named.conf file.
The options statement
The options statement specifies global options, some of which may later be overridden for particular zones or servers. The general format is:
options {
option;
option;
...
};
If no options statement is present in named.conf, then default values are used.
BIND 8 had about 30 options, and BIND 9 has over 50. For a complete list, refer to the BIND documentation or to O’Reilly’s DNS and BIND by Paul Albitz and Cricket Liu (the third edition covers BIND 8, and the fourth will include BIND 9). We have biased our coverage of these options and discuss only the ones whose use we recommend. (We also asked the BIND developers for their suggestions on which options to cover, and took their advice.) The default values are listed in square brackets beside each option.
version "string"; [real version number of the server]
There are two schools of thought on the issue of hiding the version number. Some sites believe that their servers will be more vulnerable to attack if hackers can tell what version they are running. Others think that hiding the version information is counterproductive because hackers will try their luck anyway and most newly discovered bugs are present in all versions of the software.
We recommend that you not reset the version string in spite of the fact that our site does (we lost the security-through-obscurity argument with the sysadmin group). It is very handy to be able to query your name servers and find out what version they are running (for example, if you want to know if your vendor is shipping a current release, or if you need to verify that you have in fact upgraded all your servers to the latest revision).
directory "path"; [directory where the server was started]
The directory statement causes named to cd to the specified directory. Wherever relative pathnames appear in named’s configuration files, they are interpreted relative to this directory. The path should be an absolute path. Any output files (debugging, statistics, etc.) are also written in this directory.
We recommend putting all BIND-related configuration files (other than named.conf and resolv.conf) in a subdirectory beneath /var (or wherever you keep your configuration files for other programs). We use /var/named.
notify yes | no; [yes]
also-notify servers_ipaddrs; [empty]
If notify is set to yes and this named is the master server for one or more zones, named automatically notifies those zones’ slave servers whenever the corresponding zone