Master (Primary) Name Servers
A Master DNS defines one or more zone files for which this DNS is Authoritative ('type master'). The zone has been delegated (via an NS Resource Record) to this DNS.
The term 'master' was introduced in BIND 8.x and replaced the term 'primary'.
Master status is defined in BIND by including 'type master' in the zone declaration section of the named.conf file) as shown by the following fragment.
If a DNS server receives a query for a zone for which it is neither a Master nor a Slave then it will act as configured (in BIND this behaviour is defined in the named.conf file):
A zone master can be 'hidden' (only one or more of the slaves know of its existence). There is no requirement in such a configuration for the master server to appear in an NS RR for the domain. The only requirement is that two (or more) name servers support the zone. Both servers could be any combination of master-slave, slave-slave or even master-master.
If you are running Stealth Servers and wish them to be notified you will have to add an also-notify parameter as shown in the BIND named.conf file fragment below:
Example configuration files for a master DNS are provided.
The term 'master' was introduced in BIND 8.x and replaced the term 'primary'.
Master status is defined in BIND by including 'type master' 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 master
zone "example.com" in{
type master;
file "pri.example.com";
};
Notes:- The terms Primary and Secondary DNS entries in Windows TCP/IP network properties mean nothing, they may reflect the 'master' and 'slave' name-server or they may not - you decide this based on operational need, not BIND configuration.
- It is important to understand that a zone 'master' is a server which gets its zone data from a local source as opposed to a 'slave' which gets its zone data from an external (networked) source (typically the 'master' but not always). This apparently trivial point means that you can have any number of 'master' servers for any zone if it makes operational sense. You have to ensure (by a manual or other process) that the zone files are synchronised but apart from this there is nothing to prevent it.
- Just to confuse things still further you may run across the term 'Primary Master' this has a special meaning in the context of dynamic DNS updates and is defined to be the name server that appears in the SOA RR record.
If a DNS server receives a query for a zone for which it is neither a Master nor a Slave then it will act as configured (in BIND this behaviour is defined in the named.conf file):
- If caching behaviour is permitted and recursive queries are allowed the server will completely answer the request or return an error.
- If caching behaviour is permitted and Iterative (non-recursive) queries are allowed the server can respond with the complete answer (if it is already in the cache because of another request), a referral or return an error.
- If caching behaviour is NOT permitted (an 'Authoritative Only' DNS server) the server will return a referral or an error.
A zone master can be 'hidden' (only one or more of the slaves know of its existence). There is no requirement in such a configuration for the master server to appear in an NS RR for the domain. The only requirement is that two (or more) name servers support the zone. Both servers could be any combination of master-slave, slave-slave or even master-master.
If you are running Stealth Servers and wish them to be notified you will have to add an also-notify parameter as shown in the BIND named.conf file fragment below:
// example.com fragment from named.conf
// defines this server as a zone master
// 192.168.0.2 is a stealth server NOT listed in a NS record
zone "example.com" in{
type master;
also-notify {192.168.0.2;};
file "pri/pri.example.com";
};
You can turn off all NOTIFY operations by specifying 'notify no' in the zone declaration.Example configuration files for a master DNS are provided.
Slave (Secondary) Name Servers
A Slave DNS gets its zone data using a zone transfer operation (typically 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. It is impossible to determine from a query result that it came from a zone master or slave.
The term 'slave' was introduced in BIND 8.x and replaced the term 'secondary'.
There can be any number of slave DNS's for any given zone.
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 configuration files for a slave DNS are provided.
The term 'slave' was introduced in BIND 8.x and replaced the term 'secondary'.
There can be any number of slave DNS's for any given zone.
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:- The master DNS for each zone is defined in the 'masters' statement of the zone clause 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.
- 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.
Example configuration files for a slave DNS are provided.
