Windows Server 2008: The Definitive Guide

Using Primary and Secondary Nameservers

DNS has built-in redundancy by allowing for multiple primary and secondary nameservers for a particular domain or zone. Each server, whether identified as primary or secondary, holds a copy of the zone file and acts on its contents. Secondary nameservers can answer queries without any sort of architectural limitation, just as primary nameservers can. However, the secondary nameservers must retrieve updates to zones from the primary nameserver on a regular basis to ensure their records are up-to-date.

Each zone can have only one primary nameserver, but can have as many secondary nameservers as is practical. All changes, deletions, and other modifications to a zone are made on the primary nameserver. However, nameservers designated as secondary nameservers hold read-only copies of the zone contents from their associated primary nameservers—zones can't be directly modified on secondary nameservers. The secondary nameserver will automatically determine the primary nameserver for a zone by examining the SOA records for that zone, and will contact that machine on a regular basis to force a zone file refresh.

Tip

Secondary nameservers are not limited to zone transfers from only a primary nameserver; they can accept transfers from other secondary nameservers as well.

Several mechanisms exist to force a zone transfer. For one, all of the secondary nameservers will query the primary nameserver for updates: these refreshes are generally "pull"-style updates, whereby machines fetch zones from a particular computer, rather than "push"-style updates. In addition, when a nameserver identified as secondary for any zone is rebooted or its DNS service is restarted, it will automatically query the primary server on record for an update. You also can force a zone transfer by simply right-clicking the zone inside the DNS Management snap-in on the secondary server and selecting "Transfer from Master" or "Reload from Master," to either refresh changes or refresh the entire zone file, respectively.

Transfers also are triggered by the expiration date and refresh interval, and, indirectly, by the retry interval for a particular zone. The secondary nameserver will query the primary at the time indicated by the refresh interval—this is generally 15 minutes by default, but you might find a compelling reason to change this depending on your network traffic and needs. If the serial number on the SOA record for a zone is higher on the primary nameserver than on the secondary nameserver's zone record, the transfer will take place. However, if the secondary nameserver can't contact the primary nameserver at the time the refresh interval has elapsed, the secondary nameserver will wait for the amount of time specified in the retry interval and then try again. If further attempts fail, at the time listed in the expiration date section of the record, the secondary nameserver will simply stop answering DNS requests, lest it give inaccurate and obsolete information to clients.

Full and Incremental Zone Transfers

A relatively new DNS RFC, 1995, now allows for incremental zone transfers (known in shorthand as IXFRs), which remove one of the largest stumbling blocks of DNS administration. It used to be that when a zone refresh was needed, DNS couldn't discriminate the changes made on the primary server: even if only one line of a 6,000-line zone file had changed, the entire zone needed to be transferred to the secondary machines in a process commonly referred to as a full zone transfer (or AXFR). Although that process wasn't a big deal if you had only one secondary nameserver, it became a large headache for organizations with tens or hundreds of secondary nameservers spread across the country or world. With the advent of RFC 1995, nameservers now have the ability to detect the differences between two zone files and transfer only the changed information—saving bandwidth, transfer time, and CPU power.