Guruhowtos

A Slave DNS gets its zone file information from a zone master and it will respond as authoritative for those zones for which it is defined to be a ’slave’ and for which it has a currently valid zone configuration.

The term ’slave’ was introduced in BIND 8.x and replaced the term ’secondary’.

Slave status is defined in BIND by including ‘type slave’ in the zone declaration section of the named.conf file) as shown by the following fragment.

// example.com fragment from named.conf
// defines this server as a zone slave
zone "example.com" in{
	type slave;
	file "sec/sec.example.com";
	masters {192.168.23.17;};
};

Notes:

1. The master DNS for each zone is defined in the ‘masters’ zone section and allows slaves to refresh their zone record when the ‘expiry’ parameter of the SOA Record is reached. If a slave cannot reach the master DNS when the ‘expiry’ time has been reached it will stop responding to requests for the zone. It will NOT use time-expired data.
2. The file parameter is optional and allows the slave to write the transferred zone to disc and hence if BIND is restarted before the ‘expiry’ time the server will use the saved data. In large DNS systems this can save a considerable amount of network traffic.

Assuming NOTIFY is allowed in the master DNS for the zone (the default behaviour) then zone changes are propagated to all the slave servers defined with NS Records in the master zone file. There can be any number of slave DNS’s for any given ‘master’ zone. The NOTIFY process is open to abuse. BIND’s default behaviour is to only allow NOTIFY from the ‘master’ DNS. Other acceptable NOTIFY sources can be defined using the allow-notify parameter in named.conf.