As mentioned in the DNS Overview, authoritative DNS servers are the DNS servers that know store the information about zones in the DNS. There are usually multiple DNS servers that are authoritative for the same zone. There are different types of authoritative DNS servers, as described below.

Because it isn’t very practical to have multiple copies of the same zone floating around the different servers unsynchronized, there is acually only one DNS server for every zone that has a physical copy of the zone: the primary DNS server. Other DNS servers, called secondary DNS servers, get their copy of the zone over the internet by means of a zone transfer.

There is no reason that a secondary couldn’t get its copy of the zone from another secondary rather than directly from the primary, for example if that secondary is closer. Because of this, servers are also often described in a master-slave-relationship. When one authoritative DNS server gets a copy of the zone from another, the recipient is called the slave, and the sender is called the master.

When a master server has has refreshed its zone, either from the local disk or from another DNS server, its sends out notifications to its slaves to encourage them to re-transfer the zone. Not surprisingly, this technology is called DNS Notify. An example can be seen in the following figure:

In this case, is the primary DNS server for the acdam.net. domain, and happens to be the only secondary server. Because the latter gets the zone from the server, is a slave of , and is the master of .

A more advanced example would be the following figure:

We added as a new secondary DNS server, which is configured to get the zone from both other DNS servers, that is, it will just randomly try one of the two server. Now, , apart from being a slave of , has also become a master of . is a slave of both other DNS servers, and is a master for both secondary DNS servers.

As noted, zone transfers are described by a master-slave-relationship: every slave has a preconfigured list of masters it will try to retrieve the zone from, and every master has a preconfigured list of slaves it will notify when the zone changes.

The re-transfer strategy of secondary DNS servers is controlled by three fields in the SOA Resource record of the zone: the refresh, retry and expire values.

Slave DNS servers will re-load their zone copy whenever they get a notification from their masters, but because not all DNS server support DNS Notify, and sometimes DNS Notify messages might be undeliverable, there is also the refresh interval of the zone. After the refresh interval since the last zone reload has passed, the slave will re-load the zone.

If a zone transfer fails for some reason (e.g., the slave or the master temporily lost their internet connection), the slave will wait for the time interval indicated by the retry SOA value to re-try the zone transfer. If it fails again, it will retry after waiting for that amount of time again, until, finally, the expire interval since the last zone reload has passed, and the secondary will see the zone as expired, i.e., it will no longer answer queries for the zone (the idea being that returning an error message is better than returning the wrong data). Manual intervention is now required to get the slave running again (well, that or a new notification message).

Though a DNS server can decide for itself how it stores its data, there are two standard ways of editing zones that are supported by multiple DNS servers.

Traditionally, the data for a zone is stored in a Master file on the primary DNS server. This is a plain text file that contains all Resource Records of the zone. Virtually all DNS servers provide some level of master file support.

However, the fact that many IP numbers are getting dynamically assigned through DHCP has raised the need to be able to remotely edit zones, which is why DNS Update was invented. With DNS update, clients can send special DNS messages to edit zones. DNS Update is supported at least by Posadis, ISC’s BIND and MS-DNS.