A slave server maintains a copy of the data for the zone. The master server sends its data and delegates authority to the slave server. Clients can query a slave server for DNS information. By using slave servers, you can improve response time by spreading the load over multiple machines. Slave servers also provide backup when the master server crashes.
When in.named starts, the daemon requests all the data for the given zone from the master. The slave server then periodically checks with the master to see if the master needs to update its database. The process of sending the most recent zone database from the master to the slave is called a zone transfer. Therefore, you do not modify data files on a slave server. You modify the data files on the zone's master server. The slave servers then update their files from the master.
To specify that a server is to be the slave server for a given zone, you create slave records in that server's named.boot file. Separate records can designate the server as a slave server for the zone, the zone's reverse address domain, and the loopback host.
A slave record has three required fields:
The first field designates the server as slave.
The second field identifies the zone being served.
The third field identifies the IP address of the master server for the zone from which the slave server obtains its authoritative data.
A “slave” record can have one or more optional fields after the required fields. The optional fields are the following:
slave servers
After the IP address of the master server, you can add IP addresses of other slave servers. The slave server addresses provide additional sources from which the slave server can obtain data. Adding IP addresses of slave servers might, under some circumstances, reduce performance unless those IP addresses are additional network addresses of a multihome master server.
Backup file
After the IP address of the master and optional slave servers, add the name of a backup hosts file. If a backup file name is present, the slave server loads its data from that file. The slave server then checks with the master and optional slave servers to make sure that the data in the backup file is up to date. If the backup file is not up to date, the file is updated based on the information received from the master server.
For example, the following lines in a boot file specify that the server is the slave server for the doc.com zone and its reverse address domain. The lines also specify that the slave server obtains its authoritative data from the master server at 172.16.0.1, that the slave server uses the server 172.16.0.2 as a slave source of zone data, and initially loads its data from the file doc.com.backup:
slave doc.com 129.146.168.119 192.146.168.38 doc.com.bakup slave 4.0.32.128.in-addr.arpa 129.146.168.119 |
The sample boot file lines above correspond to the boot file of the dnsslave server, which is an alias for the sirius machine whose IP address is 192.146.168.38.
A server can act as the master server for one or more zones, and as the slave server for one or more zones. The mixture of entries in the boot file determines whether a server is a master or slave server for a given zone.