In an organization, you need not only to configure DNS on an individual server but also to
design DNS for the entire network. DNS queries are common, and you want to place DNS servers
in a way that keeps the processing workload for these servers at a manageable level, that
reduces unnecessary network traffic between servers and clients, and that minimizes the
latency time for DNS servers to respond to clients. For all but the smallest organizations,
achieving these goals requires you to deploy more than one DNS server.
When you deploy more than one DNS server in an organization, achieving data consistency
among these servers becomes an essential aspect of configuring and managing DNS on your
network. And in order for multiple DNS servers in an organization to provide synchronized
and current information to clients, you need to configure zone replication and transfers.
Zone replication refers to the synchronization of zone data for Active Directory–integrated
zones. Zone transfers refer to the synchronization of zone data between any master and a secondary
standard zone. These two mechanisms are based on completely different technologies
and produce a separate set of considerations for configuration.
After this lesson, you will be able to:
■ Configure a zone replication scope appropriate to your network.
■ Create a new directory partition and enlist a server in that partition.
■ Understand the benefits of a secondary zone.
■ Implement a secondary zone.
■ Understand the benefits of stub zones.
■ Implement a stub zone.
■ Enable zone transfers to secondary and stub zones.
Estimated lesson time: 90 minutes
Configuring Zone Replication for Active Directory–Integrated Zones
You can install Active Directory–integrated zones only on domain controllers on which the
DNS Server role is installed. Active Directory–integrated zones are generally preferable to standard
zones because they offer multimaster data replication, simpler configuration, and
improved security and efficiency. With Active Directory–integrated storage, DNS clients can
send updates to any Active Directory–integrated DNS server. These updates are then copied to
other Active Directory–integrated DNS servers by means of Active Directory replication.
Lesson 2: Configuring Zone Replication and Transfers 193
Replication and Application Directory Partitions
DNS data for any particular zone can be replicated among domain controllers in a number of
ways, depending on the application directory partition on which the DNS zone data is stored.
A partition is a data structure in Active Directory that distinguishes data for different replication
purposes. By default, domain controllers include two application directory partitions
reserved for DNS data: DomainDnsZones and ForestDnsZones. The DomainDnsZones partition
is replicated among all domain controllers that are also DNS servers in a particular
domain, and the ForestDnsZones partition is replicated among all domain controllers that are
also DNS servers in every domain in an Active Directory forest.
Each of these application directory partitions is designated by a DNS subdomain and an
FQDN. For example, in an Active Directory domain named east.nwtraders.msft and whose
root domain in the Active Directory forest is nwtraders.msft, the built-in DNS application partition
directories are specified by these FQDNs: DomainDnsZones.east.nwtraders.msft and
You can see evidence of these partitions when you browse DNS Manager, as shown in Figure
3-23. Note that the ForestDnsZones name is located in the nwtraders.msft zone. Note also that
each zone includes a DomainDnsZones name that points to the partition that is replicated
only within each local domain.
Figure 3-23 You can see evidence of the built-in directory partitions for DNS within an Active
194 Chapter 3 Configuring a DNS Zone Infrastructure
Aside from these two application directory partition types, you can also create a custom or
user-defined application directory partition with a name of your own choosing. You can then
configure a zone to be stored in this new structure that you have created. By default, the new
application directory partition exists only on the server on which you created the partition, but
you can enlist other servers in the partition so that replication of its data contents are copied
to those particular servers you choose.
The replication pattern displayed by these three application data partition types—Domain-
DnsZones, ForestDnsZones, and a custom partition—is illustrated in Figure 3-24.
Figure 3-24 Replication patterns among application directory partitions
Storing DNS Data in the Domain Partition The final storage option for an Active Directory–
integrated zone is to store the zone in the domain partition along with all remaining data for
a domain. In this configuration the DNS data does not replicate merely to domain controllers
that are also DNS servers; it replicates to all domain controllers in general in the local domain.
This option is not ideal because it generates unnecessary replication traffic. However, you need
to use it if you want your DNS data to be replicated to computers running Windows 2000
Choosing Zone Replication Scope
The partition in which a zone is stored effectively determines the replication scope for that
zone. Replication scope is set when an Active Directory–integrated zone is first created.
When you use Dcpromo to promote a server to a domain controller in a new domain, the
new Active Directory–integrated zone created for the domain is stored automatically in the
Nwtraders.msft domain East.nwtraders.msft domain
Lesson 2: Configuring Zone Replication and Transfers 195
DomainDnsZones partition. However, when you create a new zone by using the New Zone
Wizard instead, you are given an opportunity on the Active Directory Zone Replication
Scope page to choose the partition in which to store the zone, as shown in Figure 3-25.
Figure 3-25 Choosing zone replication scope for a new zone
The four options presented on the Active Directory Zone Replication Scope page are
■ To All DNS Servers In This Forest This option stores the new zone in the ForestDns-
Zones partition. Every domain controller in the entire forest and on which the DNS
Server role is installed will receive a copy of the zone.
■ To All DNS Servers In This Domain This option stores the new zone in the DomainDns-
Zones partition. Every domain controller in the local domain and on which the DNS
Server role is installed will receive a copy of the zone.
■ To All Domain Controllers In This Domain This option stores the zone in the domain
partition. Every domain controller in the local domain will receive a copy of the zone,
regardless of whether the DNS Server role is installed on that domain controller.
■ To All Domain Controllers ,In The Scope Of This Directory Partition This option
stores the zone in the user-created application directory partition specified in the associated
drop-down list box. For a domain controller to fall within the scope of such a
directory partition, you must manually enlist that domain controller in the partition.
196 Chapter 3 Configuring a DNS Zone Infrastructure
After a new zone is created, you can choose to change the replication scope for the zone at any
time. To do so, in the General tab of the properties of the zone, click the Change button associated
with replication, as shown in Figure 3-26.
Figure 3-26 Changing the replication scope of an existing zone
This step opens the Change Zone Replication Scope dialog box, which, as shown in Figure 3-27,
provides the same zone replication scope options that the New Zone Wizard does.
Figure 3-27 Modifying the replication scope for an existing zone
Lesson 2: Configuring Zone Replication and Transfers 197
When deciding which replication scope to choose, consider that the broader the replication
scope, the greater the network traffic caused by replication. For example, if you choose to have
Active Directory–integrated DNS zone data replicated to all DNS servers in the forest, this setting
produces greater network traffic than does replicating the DNS zone data to all DNS servers
in the local domain only. On the other hand, replicating zone data to all DNS servers in a
forest can improve forest-wide name resolution performance and increase fault tolerance.
NOTE Re-creating DomainDnsZones and ForestDnsZones
If either of the default application directory partitions is deleted or damaged, you can re-create
them in DNS Manager by right-clicking the server node and choosing Create Default Application
Creating Custom Application Directory Partitions
You can create your own custom application directory partitions for use with DNS and then
enlist selected domain controllers in your network to host replicas of this partition.
To accomplish this task, first create the partition by typing the following command:
dnscmd servername /createdirectorypartition FQDN
Then enlist other DNS servers in the partition by typing the following command:
dnscmd servername /enlistdirectorypartition FQDN
For example, to create an application directory partition named DNSpartitionA on a computer
named Server1 in the Active Directory domain contoso.com, type the following command:
dnscmd server1 /createdirectorypartition DNSpartitionA.contoso.com
NOTE Use a dot (“.”) for the local server name
You can substitute a “.” for the server name if you are executing the command on the same server
on which you want to create the partition.
To enlist a computer named Server2 in the application directory partition, type the following
dnscmd server2 /enlistdirectorypartition DNSpartitionA.contoso.com
198 Chapter 3 Configuring a DNS Zone Infrastructure
NOTE Who can create a custom application directory partition?
You must be a member of the Enterprise Admins group to create an application directory partition.
After you create a new application directory partition, that partition will appear as an option in
the drop-down list box both on the Active Directory Zone Replication Scope page of the New
Zone Wizard and in the Change Zone Replication Scope dialog box. To store a zone in the new
partition, choose To All Domain Controllers Specified In The Scope Of This Directory Partition
and then select the partition in the drop-down list box.
Exam Tip Expect to be tested on application directory partition concepts, as well as on the
options in the Change Zone Replication Scope dialog box.
Using Zone Transfers
When all of your DNS servers are located on domain controllers, you will normally want to use
Active Directory replication to keep zone data consistent among all DNS servers. However, this
option is not available when you install a DNS server on a computer that is not a domain controller.
In such cases you cannot store the zone in Active Directory and instead must use a standard
zone that stores data in a local text file on each DNS server. If your organization requires
multiple DNS servers, then the source data can be copied to read-only secondary zones hosted
on other servers. In order to keep data consistent and up-to-date between a primary and any
secondary zones, you need to configure zone transfers.
Zone transfers are essentially pull operations initiated on secondary zones that copy zone data
from a master zone, which itself can be a primary or another secondary. In fact, the master
zone for a secondary zone need not even be another standard zone—you can configure a secondary
zone for an Active Directory–integrated primary zone. This arrangement might be suitable,
for example, if you have two sites, one in New York and one in Los Angeles, each with its
own Active Directory domain. In each domain you might want to provide name resolution for
the opposite domain without installing a new domain controller and managing replication
traffic between the two sites.
Such an infrastructure is illustrated in Figure 3-28.
Lesson 2: Configuring Zone Replication and Transfers 199
Figure 3-28 A DNS infrastructure with zone transfers between sites
Zone Transfer Initiation
Any of three events can trigger zone transfers on secondary zones:
■ They can be triggered when the refresh interval of the primary zone’s SOA resource
■ They can be triggered when a server hosting a secondary zone boots up.
In these first two cases the secondary server initiates a query to find out whether any
updates in the zone have occurred. This information is determined by comparing the
serial number (specified in the SOA record) of the secondary zone to the serial number
of the master zone. If the master zone has a higher serial number, the secondary zone initiates
a transfer from the master.
■ They are triggered when a change occurs in the configuration of the primary zone and
this primary zone is configured to notify a secondary zone of zone updates.
New York Site
Los Angeles Site
200 Chapter 3 Configuring a DNS Zone Infrastructure
Enabling Zone Transfers
By default, zone transfers are disabled from any zone, and you must enable them in the
Zone Transfers tab of the zone properties dialog box, as shown in Figure 3-29. After you
have selected the option to allow zone transfers from the zone, you have a choice of three
■ To Any Server This option is the least secure. Because a zone transfer is essentially a
copy of zone data, this setting allows anyone with network access to the DNS server to
discover the complete contents of the zone, including all server and computer names
along with their IP addresses. This option should therefore be used only in private networks
with a high degree of security.
■ Only To Servers Listed On The Name Servers Tab This option restricts zone transfers
only to secondary DNS servers that have an NS record in the zone and are therefore
already authoritative for zone data.
■ Only To The Following Servers This option allows you to specify a list of secondary
servers to which you will allow zone transfers. The secondary servers do not need to be
identified by an NS record in the zone.
Figure 3-29 A zone on which transfers have been enabled
The Zone Transfers tab also allows you to configure notification to secondary servers whenever
a change occurs at the primary zone. Because zone transfers are pull operations, they cannot
be configured to push new data to secondary zones. Instead, when a modification occurs
Lesson 2: Configuring Zone Replication and Transfers 201
in zone data, the primary zone sends a notification to any specified servers hosting secondary
zones. When the secondary zone receives this notification, it initiates a zone transfer.
To configure notifications, click Notify in the Zone Transfers tab when zone transfers are
enabled. This action opens the Notify dialog box, shown in Figure 3-30, in which you can specify
secondary servers that should be notified whenever a zone update occurs at the local master
server. By default, when zone transfers are enabled, all servers listed in the Name Servers
tab are automatically notified of zone changes.
Figure 3-30 Notify dialog box
Manaully Updating a Secondary Zone
By right-clicking a secondary zone in the DNS Manager console tree, you can use the shortcut
menu to perform the following secondary zone update operations:
■ Reload This operation reloads the secondary zone from the local storage.
■ Transfer From Master The server hosting the local secondary zone determines whether
the serial number in the secondary zone’s SOA resource record has expired and then
pulls a zone transfer from the master server.
■ Reload From Master This operation performs a zone transfer from the secondary
zone’s master server regardless of the serial number in the secondary zone’s SOA
202 Chapter 3 Configuring a DNS Zone Infrastructure
Implementing Stub Zones
A stub zone is a copy of a zone that contains only the most basic records in the master zone.
The purpose of a stub zone is to enable the local DNS server to forward queries to the name
servers authoritative for the master zone. In this way a stub zone is functionally identical to a
zone delegation. However, because stub zones can initiate and receive zone transfers from the
master (delegated) zone, stub zones provide the added benefit of informing parent zones of
updates in the NS records of child zones.
An example of a stub zone is shown in Figure 3-31.
Figure 3-31 East.nwtraders.msft is a stub zone of a child zone hosted on remote server
NOTE What is a delegated zone?
A delegated zone is a child zone (such as east.nwtraders.msft) of a parent zone (such as nwtraders.
msft) that is typically hosted on its own DNS server. With delegations, the parent zone includes
an NS record for the server hosting the child zone, so when the parent receives queries for names
in the child zone, those queries get redirected to the server specified in that NS record. It is unlikely
that you will see any questions about delegations on the 70-642 exam.
Lesson 2: Configuring Zone Replication and Transfers 203
You can use stub zones to:
■ Keep delegated zone information current By updating a stub zone for one of its child
zones regularly, the DNS server that hosts both the parent zone and the stub zone will
maintain a current list of authoritative DNS servers for the child zone.
■ Improve name resolution Stub zones enable a DNS server to perform recursion using
the stub zone’s list of name servers without having to query the Internet or an internal
server within the local DNS namespace. When stub zones are deployed for this reason,
they are deployed not between parent and child zones but across domains in a large
Active Directory forest or DNS namespace.
Stub Zone Example
Suppose that you are an administrator for the DNS server named Dns1.contoso.com, which is
authoritative for the zone Contoso.com. Your company includes a child Active Directory
domain, India.contoso.com, for which a delegation has been performed. When the delegation
is originally performed, the child zone (which is Active Directory–integrated) contains only
two authoritative DNS servers: 192.168.2.1 and 192.168.2.2. Later, administrators of the
India.contoso.com domain deploy additional domain controllers and install the DNS Server
role on these new domain controllers. However, these same administrators do not notify you
of the addition of more authoritative DNS servers in their domain. As a result, Dns1.contoso.
com is not configured with the records of the new DNS servers authoritative for
India.contoso.com and continues to query only the two DNS servers that were defined in the
You can remedy this problem by configuring Dns1.contoso.com to host a stub zone for
India.contoso.com. As a result of this new stub zone, Dns1 learns through zone transfers
about the new name servers authoritative for the India.contoso.com child zone. Dns1 is thus
able to direct queries for names within the India.contoso.com namespace to all of that child
zone’s authoritative DNS servers.
This example is illustrated in Figure 3-32.