Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  Name Systems and TCP/IP Name Registration and Name Resolution            9  TCP/IP Name Systems: Host Tables and Domain Name System (DNS)                 9  TCP/IP Domain Name System (DNS)                      9  DNS Name Servers and Name Resolution                           9  DNS Name Server Concepts and Operation

DNS Name Server Types and Roles: Primary/Master, Secondary/Slave and Caching-Only Servers 1 2 3 DNS Root Name Servers

Zone Transfers

The ultimate purpose of zone management is to ensure that information about the zone is kept current on the zone's master and slave name servers, so it can be efficiently provided to name resolvers. Thus, the management of a zone begins with decision-making and administrative actions that result in changes to the resource records for the zone. These are reflected in changes made to the DNS master files on the master (primary) DNS server for the zone.

In contrast, each zone's secondary DNS server(s) act as “slaves” to the “master” primary server. They carry information about the zone, but do not load it from local master files that are locally edited. Instead, they obtain their information from the master name server on a regular basis. The procedure responsible for this is called a zone transfer.

The resource records on the master name server can be updated at any time; as soon as the master name server's records have been changed, the information at the slave name servers becomes partially out of date. This is not generally a big deal, because most of the data will still be accurate, and the secondary server will continue to respond to resolution requests using the most current information it has. However, it is obviously important that we update the slave servers on a regular basis; if this is not done, eventually their data will become “stale” and unreliable.

To this end, it is necessary that zone transfers be performed on a regular basis. This requires implementation of a communication process between the servers that consists of two basic parts. First, we need a mechanism to allow slave servers to regularly check for changes to the data on the master. Second, we must have a mechanism for copying the resource records for the zone from the primary name server to the secondary when needed.

Both mechanisms make use of standard DNS query/response facilities, and special fields in the resource records for the zone. Of particular importance is the Start Of Authority (SOA) record for the zone, which contains several parameters that control zone status checking and zone transfers. The formal description of these parameters can be found in the topic on resource record formats, I'll discuss how they are used here.

When a slave name server starts up, it either has no information about the zone at all, or it may have a copy of the zone's resource records stored on its local storage, from the last time it was running. In the former case, it must immediately perform a full zone transfer, since it has no information. In the latter case, it will read its “last known” copy of the zone from local storage; it may immediately perform a poll on the master server to see if the data has changed, depending on configuration. A poll is done by requesting the Start Of Authority resource record for the zone.

The Serial field in the SOA record contains a serial number (which may be arbitrary or may be encoded so it has a particular meaning) that acts as the “version number” of the master server's zone database. Each time the master file for the zone is modified (either manually by editing or automatically through another means) this serial number is increased. Therefore, a slave server can detect when changes have been made on the master by seeing if the Serial field in the most recent SOA record is greater than the one the slave stored the last time it polled the master. If the serial number has changed, the slave begins a zone transfer.

Three other fields in the SOA record control the timing that slave name servers use for polling and updating their information:

• Refresh: This field specifies how many seconds a slave server waits between attempts to check for an update on the master. Assuming the slave can make contact, this is the longest period of time that data on a slave will become “stale” when the master changes.
  
  
• Retry: This field controls how long the slave must wait before trying again to check in with the master if its last attempt failed. This is used to prevent “rapid fire” attempts to contact a master that may clog the network.
  
  
• Expire: If, for whatever reason, the slave name server is not able to make contact with the master for a number of seconds given by this field value, it must assume that the information it has is stale and stop using it. This means that it will stop acting as an authoritative name server for the zone until it receives an update.

The fact that these parameters are part of the SOA record for the zone gives the administrator of the zone complete control over how often master name servers are updated. In a small zone where changes are rare, the interval between checks made by the slave servers can be increased; for larger zones or ones that are changed often, the Refresh interval can be decreased.

DNS Name Server Types and Roles: Primary/Master, Secondary/Slave and Caching-Only Servers 1 2 3 DNS Root Name Servers