Bagikan melalui

Understanding zones and zone transfer

  • Artikel

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Understanding zones and zone transfer

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.

Understanding the difference between zones and domains

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:

  • Managed and included as part of the original zone records, or

  • Delegated away to another zone created to support the subdomain

For example, the following figure 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.

Difference between a zone and a domain

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.

Why zone replication and zone transfers are needed

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 DNS servers running Windows Server 2003, the DNS service supports incremental zone transfer, a revised DNS zone transfer process for intermediate changes.

Incremental zone transfers

Incremental zone transfers are described in Request for Comments (RFC) 1995 as an additional DNS standard for replicating DNS zones. For more information about RFCs, see the RFC Editor Web site. 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.

Example: Zone transfer

A zone transfer might occur during any of the following scenarios:

  • When the refresh interval expires for the zone

  • When a secondary server is notified of zone changes by its master server

  • When the DNS Server service is started at a secondary server for the zone

  • When the DNS console is used at a secondary server for the zone to manually initiate a transfer from its master server

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 figure, 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.

Example: zone transfer

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.

  1. During new configuration, the destination server sends an initial "all zone" transfer (AXFR) request to the master DNS server configured as its source for the zone.

  2. The master (source) server responds and fully transfers the zone to the secondary (destination) server.

    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.

  3. When the refresh interval expires, an SOA query is used by the destination server to request renewal of the zone from the source server.

  4. The source server answers the query for its SOA record.

    This response contains the serial number for the zone in its current state at the source server.

  5. The destination server checks the serial number of the SOA record in the response and determines how to renew the zone.

    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.

  6. If the destination server concludes that the zone has changed, it sends an IXFR query to the source server, containing its current local value for the serial number in the SOA record for the zone.

  7. The source server responds with either an incremental or full transfer of the zone.

    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

  • For servers running Windows 2000 and Windows Server 2003, incremental zone transfer through IXFR query is supported. For earlier versions of the DNS service and for many other DNS server implementations, incremental zone transfer is not available and only full-zone (AXFR) queries and transfers are used to replicate zones.

DNS Notify

Windows-based 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, this list is maintained in the Notify dialog box, which is accessible from the Zone Transfer tab located in zoneProperties.

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 Create and manage a notify list for a zone.

The following is a brief summary of the typical DNS notification process for zone updates:

  1. The local zone at a DNS server acting as a master server, a source for the zone to other servers, is updated. When the zone is updated at the master or source server, the serial number field in the SOA RR is also updated, indicating a new local version of the zone.

  2. The master server sends a DNS notify message to other servers that are part of its configured notify list.

  3. All secondary servers that receive the notify message can then respond by initiating a zone transfer request back to the notifying master server.

The normal zone transfer process can then continue as described in the previous section.

You cannot configure a notify list for a stub zone.

Important

  • Use DNS notification only to notify servers operating as secondary servers for a zone. For replication of directory-integrated zones, DNS notification is not needed.

    This is because any DNS servers that load a zone from Active Directory automatically poll the directory (as specified by the SOA resource record's Refresh Interval) 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.

Notes