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 Book is Here... and Now On Sale!

Enjoy The TCP/IP Guide? Get the complete PDF!
The TCP/IP Guide

Custom Search







Table Of Contents  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

Previous Topic/Section
DNS Name Server Types and Roles: Primary/Master, Secondary/Slave and Caching-Only Servers
Previous Page
Pages in Current Topic/Section
1
2
3
Next Page
DNS Root Name Servers
Next Topic/Section

DNS Zone Management, Contacts and Zone Transfers
(Page 2 of 3)

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.

Controlling When Zone Transfers Occur Using DNS Start of Authority Fields

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.


Previous Topic/Section
DNS Name Server Types and Roles: Primary/Master, Secondary/Slave and Caching-Only Servers
Previous Page
Pages in Current Topic/Section
1
2
3
Next Page
DNS Root Name Servers
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.