UNIX System Administration Handbook - Evi Nemeth [255]
Configuring the master server for a zone
Here is the format you need for a zone of which this named is the master server:
zone "domain_name" {
type master;
file "path";
allow-query { address_match_list }; [all]
allow-transfer { address_match_list }; [all]
allow-update { address_match_list }; [none]
ixfr-base "path"; [domain_name.ixfr (V8 only)]
};
The domain_name in a zone specification must always be in double quotes.
The zone’s data is kept on disk in a human-readable (and human-editable) file. Since there is no default for the filename, you must provide a file statement when declaring a master zone. A zone file is just a collection of DNS resource records; the format is described beginning on page 436.
The access control options are not required, but it’s a good idea to use them. If dynamic updates are used for this zone, the allow-update clause must be present with an address match list that limits the hosts from which updates can occur. Dynamic updates apply only to master zones; the allow-update clause cannot be used for a slave zone (in BIND 9). Be sure that this clause includes just your local DHCP servers and not the whole Internet.8
If incremental zone transfers are to be used with this zone, BIND 8 keeps a transaction log in a file called domain_name.ixfr in named’s home directory. If you want to change the name, use the ixfr-base clause to specify a new filename. This file is maintained by named and needs no attention from you.
In BIND 9, the transaction log is used for both dynamic updates and IXFR. Its name ends with .jnl and is not configurable. Both dynamic updates and incremental zone transfers are relatively new features of BIND. They are discussed in more detail starting on page 458.
With all these zone-specific options (and several more we have not covered), the configuration is starting to sound complicated. However, a master zone declaration consisting of nothing but a pathname to the zone file is perfectly reasonable. In BIND 4, that’s all you could specify. Here is an example from the BIND documentation that we have modified slightly:
zone "example.com" {
type master;
file "forward/example.com";
allow-query { any; };
allow-transfer { my-slaves; };
}
my-slaves is an access control list that was previously defined.
Configuring a slave server for a zone
The zone statement for a slave is very similar to that of a master:
zone "domain_name" {
type slave | stub;
file "path";
ixfr-base "path"; [V8 only]
masters { ip_addr; ip_addr; ... }; [no default]
allow-query { address_match_list }; [all]
allow-transfer { address_match_list }; [all]
};
Slave servers normally maintain a complete copy of their zone’s database. However, if the type is set to stub instead of slave, only NS (name server) records are transferred. Stub zones allow the nameds for the parent zone to automatically discover which machines provide DNS service for their delegated child zones, just in case the administrator of the child zone is not conscientious about informing the parent of changes. The parent needs this information to make appropriate referrals or recursive queries. We revisit this topic in greater detail on page 455.
The file statement specifies a local file in which the replicated database can be stored. Each time the server fetches a new copy of the zone, it saves the data in this file. If the server crashes and reboots, the file can then be reloaded from the local disk without being transferred across the network.
You shouldn’t edit this cache file, since it’s maintained by named. However, it can be interesting to look at if you suspect you have made an error in the master server’s data file. The slave’s disk file shows you how named has interpreted the original zone data; relative names and origin directives have all been expanded. If you see a name in the data file that looks like one of these
128.138.243.151.cs.colorado.edu.