Secondary Servers

Before a domain application is approved, at least one secondary server must be operative, as well as the master server. RFC 2182 describes how secondary DNS servers should be selected and operated. This RFC is even a BCP, Best Current Practice, so I recommend it. It discusses many diverse DNS server topics, from placement to firewalls to hidden nameservers to how many secondary servers you need.

It boils down to this: If you want your domain to operate reliably, and even in the face of failures wherever they occur, your DNS should operate reliably. To make it reliable, your DNS servers should be placed in diverse locations both geographically and network topologically. Separate your servers as widely as possible, measured overland and along the network, and they will be independent. If they share power lines, though, they are liable to all fail when the power fails. If they share a WAN or LAN, they also are liable to all fail if the WAN or LAN fails.

Adding a Slave Server

Now, when the good people at Herring AS set up secondaries for Penguin and Walrus AS, they insert something similar to the following into their named.conf files:

 zone "penguin.bv" {         type slave;         file "sz/penguin.bv";         masters {                 192.168.55.2;         }; }; zone "55.168.192.in-addr.arpa" {         type slave;         file "sz/192.168.55";         masters {                 192.168.55.2;         }; }; 

The zone lines are exactly as on the master; after all, they name the zone. The zone type is slave, which is correct. Additionally, the zone data is stored not in pz but in sz, for secondary zone. Inside the masters statement, you can list all the possible DNS servers from which to copy this zone. If you list all the other servers here, the secondary has a good chance of getting fresh copies of the zone from one of them. Recall that a zone will expire on the slave server if the slave has been unable to get updates for the zone's expire time.

If you want to list multiple servers, separate them with a semicolon (;).

You usually will want to list all your secondary servers in NS records for the zone in question.

Stealth Servers

Various reasons exist for setting nameservers for a zone that are not listed in the zone's NS records. These are sometimes called stealth servers.

Many unlisted servers are located on the inside of a company network, providing lookup and resolution service to all the hosts on the inside. If the server has the domain's zone files, it will be capable of answering queries for the zone directly from the zone file instead of having to resolve the names in the usual manner, which is more time consuming. This internal server often is unavailable from the Internet, and listing it in the NS records only causes DNS on the outside to spend time contacting a server that will never answer. The hosts on the inside do not need the listing; they will ask the servers anyway because their resolver was set up that way. Therefore, it is not listed.

Another reason for running an unlisted server is that the listed servers might be in some way impractical to log in to and work on, be it for security reasons or for any other reason. In that case, you can run an unlisted master server, on which it is convenient to work and from which the slaves will get updates.