NoteThe Domain Name System (DNS) allows a DNS namespace to be divided up into zones, which store name information about one or more DNS domains. For each DNS domain name included in a zone, the zone becomes the authoritative source for information about that domain.
A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain used to create the zone, these domains can either be part of the same zone or belong to another zone. Once a subdomain is added, it can then either be:
For example, the following graphic shows the microsoft.com domain, which contains domain names for Microsoft. When the microsoft.com domain is first created at a single server, it is configured as a single zone for all of the Microsoft DNS namespace. If, however, the microsoft.com domain needs to use subdomains, those subdomains must be included in the zone or delegated away to another zone.
In this example, the example.microsoft.com domain shows a new subdomain -- the example.microsoft.com domain -- delegated away from the microsoft.com zone and managed in its own zone. However, the microsoft.com zone needs to contain a few resource records to provide the delegation information that references the DNS servers that are authoritative for the delegated example.microsoft.com subdomain.
If the microsoft.com zone does not use delegation for a subdomain, any data for the subdomain remains part of the microsoft.com zone. For example, the subdomain dev.microsoft.com is not delegated away but is managed by the microsoft.com zone.
Because of the important role that zones play in DNS, it is intended that they be available from more than one DNS server on the network to provide availability and fault tolerance when resolving name queries. Otherwise, if a single server is used and that server is not responding, queries for names in the zone can fail. For additional servers to host a zone, zone transfers are required to replicate and synchronize all copies of the zone used at each server configured to host the zone.
When a new DNS server is added to the network and is configured as a new secondary server for an existing zone, it performs a full initial transfer of the zone to obtain and replicate a full copy of resource records for the zone. For most earlier DNS server implementations, this same method of full transfer for a zone is also used when the zone requires updating after changes are made to the zone. For Windows 2000 Server, the DNS service supports incremental zone transfer, a revised DNS zone transfer process for intermediate changes.
Incremental zone transfers are described in RFC 1995 as an additional DNS standard for replicating DNS zones. When incremental transfers are supported by both a DNS server acting as the source for a zone and any servers that copy the zone from it, it provides a more efficient method of propagating zone changes and updates.
In earlier DNS implementations, any request for an update of zone data required a full transfer of the entire zone database using an AXFR query. With incremental transfer, an alternate query type (IXFR) can be used instead. This allows the secondary server to pull only those zone changes it needs to synchronize its copy of the zone with its source, either a primary or secondary copy of the zone maintained by another DNS server.
With IXFR zone transfers, differences between the source and replicated versions of the zone are first determined. If the zones are identified to be the same version -- as indicated by the serial number field in the start of authority (SOA) resource record of each zone -- no transfer is made.
If the serial number for the zone at the source is greater than at the requesting secondary server, a transfer is made of only those changes to resource records (RRs) for each incremental version of the zone. For an IXFR query to succeed and changes to be sent, the source DNS server for the zone must keep a history of incremental zone changes to use when answering these queries. The incremental transfer process requires substantially less traffic on a network and zone transfers are completed much faster.
A zone transfer might occur during any of the following scenarios:
Zone transfers are always initiated at the secondary server for a zone and sent to their configured master servers which act as their source for the zone. Master servers can be any other DNS server that loads the zone, such as either the primary server for the zone or another secondary server. When the master server receives the request for the zone, it can reply with either a partial or full transfer of the zone to the secondary server.
As shown in the following graphic, zone transfers between servers follow an ordered process. This process varies depending on whether a zone has been previously replicated, or if initial replication of a new zone is being performed.
In this example, the following sequence is performed for a requesting secondary server -- the destination server -- for a zone and its source server, another DNS server that hosts the zone.
The zone is delivered to the destination server requesting the transfer with its version established by use of a Serial number field in the properties for the start of authority (SOA) resource record (RR). The SOA RR also contains a stated refresh interval in seconds (by default, 900 seconds or 15 minutes) to indicate when the destination server should next request to renew the zone with the source server.
This response contains the serial number for the zone in its current state at the source server.
If the value of the serial number in the SOA response is equal to its current local serial number, it concludes that the zone is the same at both servers and that a zone transfer is not needed. The destination server then renews the zone by resetting its refresh interval based on the value of this field in the SOA response from its source server.
If the value of the serial number in the SOA response is higher than its current local serial number, it concludes that the zone has been updated and that a transfer is needed.
If the source server supports incremental transfer by maintaining a history of recent incremental zone changes for modified resource records, it can answer with an incremental zone transfer (IXFR) of the zone.
If the source server does not support incremental transfer, or does not have a history of zone changes, it can answer with a full (AXFR) transfer of the zone instead.
Note
Windows DNS servers support DNS Notify, an update to the original DNS protocol specification that permits a means of initiating notification to secondary servers when zone changes occur (RFC 1996). DNS notification implements a push mechanism for notifying a select set of secondary servers for a zone when it is updated. Servers that are notified can then initiate a zone transfer as described above to pull zone changes from their master servers and update their local replicas of the zone.
For secondaries to be notified by the DNS server acting as their configured source for a zone, each secondary server must first have its IP address in the notify list of the source server. When using the DNS console to manage zones loaded at Windows 2000 DNS servers, this list is maintained in the Notify dialog box, which is accessible from the Zone Transfer tab located in zone Properties.
In addition to notifying the listed servers, the DNS console permits you to use the contents of the notify list as a means to restrict or limit zone transfer access to only those secondary servers specified in the list. This can help prevent an undesired attempt by an unknown or unapproved DNS server to pull, or request, zone updates. For more information, see To create and manage a notify list for a primary zone
The following is a brief summary of the typical DNS notification process for zone updates:
The normal zone transfer process can then continue as described in the previous section.
Important
This is because any DNS servers that load a zone from Active Directory automatically poll the directory (approximately once every 15 minutes) to update and refresh the zone.
In these cases, configuring a notify list can actually degrade system performance by causing unnecessary additional transfer requests for the updated zone.