Secondary zones cannot be stored in AD. Active Directory-integrated zones pro-
vide enhanced security for DNS updates and zone replication traffic in several
ways: all DNS servers hosting Active Directory-integrated zones must be registered
in AD, AD replication traffic is encrypted, and you can use access control lists
(ACLs) to restrict the hosts that are allowed to update RRs using DDNS (secure
dynamic updates).
■
Stealth servers When you register the name servers that are authoritative for your
Internet domain namespace, you must supply at least one or two name servers that are
authoritative for the zone, so that authority can be delegated from the parent domain
(.com, .net, and so on) to your servers. It is possible, however, for these servers to be sec-
ondary, or slave, servers to a primary master server that is not listed in the registered NS
records for the zone listed by the registrar as being authoritative for your domain. Usually,
the primary master server is located behind a firewall, and access to the primary server
itself and zone transfers to the secondary servers are tightly controlled by access rules on
the firewall.
■
Caching name servers A caching name server performs queries on behalf of DNS, but
the server itself is not authoritative for any zones. When you first set up a Windows DNS
server with the root hints file, it is a caching name server that can resolve queries for Internet
hosts using information it possesses about the name servers that are authoritative for the root
zone.After time, the caching name server builds up a list of commonly queried names in its
cache, which is subsequently used to answer queries on behalf of clients.
■
Forwarding servers A forwarding server is a kind of caching name server that sends
queries to a predetermined list of name servers, known as forwarders, which can perform
recursive queries on its behalf.The forwarding server will send its query to each forwarder
in its list until it receives a positive or negative response. After it exhausts the name servers
in its list, it can be configured to send requests to servers on the Internet using its root
hints file. Alternatively, a forwarder can be configured to stop at this point, by disabling
recursion, and send a negative response back to the original DNS requester if the for-

warder cannot resolve the query. If recursion is disabled on the forwarding server, it is
referred to as a forward-only server.There are a number of uses for forwarding servers and
forwarders. They are often used when you want to tightly control which DNS servers
(the forwarders) are able to send and receive DNS traffic through your firewall. Another
common use of forwarders is to handle DNS queries performed across relatively slow
WAN links on a corporate network. In the remote network, a name server is configured
to forward queries to a more powerful caching name server that has a larger cache and is
better able to resolve DNS queries as result of having access to more bandwidth, rather
than send its queries directly to the Internet. A new feature of Windows Server 2003 DNS
allows the configuration of conditional forwarding. Conditional forwarding allows the DNS
administrator to configure the forwarding server to contact specific name servers based on
the domain name specified in the query.To configure a conditional forwarder, you specify
the domain name and the IP addresses of the servers that are responsible for resolving host
676 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 676
names in these domains. Conditional forwarders provide intelligent name resolution and
are typically used to reduce the amount of traffic related to recursion on your network.
■
Nonrecursive servers A nonrecursive server is one on which you have disabled recur-
sion so that it is not able to perform recursive queries on behalf of DNS requesters.
Disabling recursion on a name server also prevents it from using forwarders to resolve
queries. Usually, recursion is disabled on authoritative name servers that provide name res-
olution for DNS requesters on the Internet, performing queries to locate your Internet
hosts, such as your Web and mail servers. By disabling recursion on these name servers, you
ensure that the servers will respond positively only to queries for RRs in zones for which
they are authoritative, and hence tighten the security of these servers. DNS clients on the
Internet will not be able to configure their TCP/IP settings to point to your DNS servers
for name resolution.
These name server roles are only logically separate from one another. It is possible to combine
roles on a single name server. For example, a DNS server can be configured to be a primary master for

one domain zone file and as a secondary for other domain zone files. However, it is often advanta-
geous to separate these roles and place them on separate servers. By doing so, you are better able to
design your DNS infrastructure to take into account the contingencies of your network infrastructure,
such as the speed of your WAN links, the presence of firewalls, the need for security, and so on.
Domain Controller versus Member Server
In an AD environment, you have the choice to install and configure DNS on your domain con-
trollers or on member servers. If you install DNS on your domain controllers, you can configure
Active Directory-integrated zones.
Active Directory-integrated zones provide the following advantages over standard DNS zones:
■
There is not a single point of failure for the primary zone. In a standard DNS environ-
ment, if the primary master DNS server fails and is not brought online within a particular
amount of time (specified in the SOA record), the secondary servers will remove the RRs
from their zone, and name resolution will fail for the entire domain.
■
In large environments where DHCP servers and clients are updating RRs, this load can be
distributed among domain controllers that store zone information in AD.
■
Active Directory-integrated zones provide enhanced security for zone replication in that
DNS servers must be registered in AD and AD replication traffic is encrypted.
■
You can use secure dynamic updates with Active Directory-integrated zones to tighten
security further.
■
Synchronization of zone information occurs automatically through AD replication. No
further configuration is necessary to facilitate transfer of zone information among partici-
pating servers.
■
AD replication is more efficient than the standard zone transfer mechanisms. For example,
AD replication propagates only the last changes. Even though an incremental zone transfer

Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 677
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 677
copies only the changes to the RRs, it propagates all the incremental changes to the RRs
that have occurred since the last update. If you are not using IXFR, the entire zone file is
copied whenever an update is made.
■
AD replication will compress replication traffic in certain circumstances, further reducing
the bandwidth needed for DNS-related traffic.
Active Directory-integrated zones can be used in combination with secondary servers. For
example, you can use secondary zones on servers that are not configured as domain controllers.This
is advantageous in situations where you do not want AD traffic replicated across a WAN link, but
you do want to have an authoritative DNS server available at a remote location.You cannot simulta-
neously load a standard text-based primary zone file and an Active Directory-integrated zone for
the same domain on the same domain controller. However, you can combine primary, secondary,
and Active Directory-integrated zones on the same domain controller. On a stand-alone or member
server, primary and secondary zones can be combined on the same server. Furthermore, if you have
multiple IP addresses bound to the server, you can emulate a secondary server on the same com-
puter where the primary is located.This configuration is useful in very small environments where
you have only one server.
Planning for Zone Replication
In planning your DNS infrastructure, you need to decide on the number and placement of your
DNS servers. In particular, you must decide which servers will host zone files for your domains.
Distributing zone files across your network has a number of advantages. For example, distributed
zone files reduce the network traffic caused by DNS queries, increase availability and fault tolerance,
provide load balancing, and result in shorter query response times. However, distributing zone files
requires that you replicate zone information among your DNS servers, increasing traffic associated
with zone transfers or AD replication (if you have enabled Active Directory-integrated zones). Zone
files also increase the storage space requirements on DNS servers. Furthermore, replicating zone
information increases the administrative effort required to maintain the DNS infrastructure.
In planning for zone replication, you must decide which mechanism you will use for zone repli-

cation: either standard DNS zone transfers or AD replication.This decision will depend on a
number of factors, including the storage location (file-based or AD), the type of zone information
(primary, secondary, or stub), and whether you need enhanced security.
If you are using stand-alone, member servers, or other implementations of DNS, such as BIND,
you must use standard DNS mechanisms for zone transfers. Depending on the version of DNS or
BIND you are using, you can use either full (AXFR) or incremental (IXFR) zone transfers to prop-
agate zone information. Incremental zone transfers reduce traffic by propagating only the incre-
mental changes since the last update.
Microsoft and other DNS servers optimize traffic associated with standard zone transfers by
compressing the zone transfer information and including multiple RRs in individual TCP packets.
This mechanism is referred to as fast zone transfers (it should not be confused with IXFR). Versions
of BIND earlier than 4.9.4 do not support fast zone transfers. Support for fast zone transfers to
BIND secondaries is enabled by default on Microsoft DNS servers, but it can be disabled.
678 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 678
A zone transfer is initiated when the secondary servers determine that the version number in
their SOA RR is lower than the version number in the primary’s SOA RR, indicating an update to
the primary zone.The secondary servers will compare the SOA version number in the following
situations:
■
When they are notified of a change by the primary server.
■
When the refresh interval specified in the SOA has elapsed.
■
When the DNS service on the secondary server is started.
■
When a zone transfer is manually initiated by the administrator.
When the secondary server determines it needs to update its zone file, it will make a request for
an incremental zone transfer (IXFR) or a full zone transfer (AXFR).
The notify list should contain only the IP addresses of secondary servers. It is not necessary to

use this list to notify other domain controllers that have a copy of the Active Directory-integrated
zone. Active Directory-integrated zones poll approximately every 15 minutes for updates. In fact,
adding domain controllers to the notify list can actually degrade performance. Figure 20.3 shows the
property pages for configuring a secondary zone transfer notify list.
Active Directory-integrated Zone Replication Scope
In a Windows Server 2003 environment, you must specify an Active Directory-integrated scope.The
choices for the replication scope are described in Table 20.1.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 679
Figure 20.3 Configuring a Notify List for Zone Transfers
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 679
Table 20.1 Active Directory-integrated Zone Replication Scope Options
DNS Zone Replication Scope Description and Usage
All DNS servers in the AD forest This is the broadest scope for DNS zone repli-
cation and produces the most replication
traffic. Zone data is replicated to all Windows
Server 2003 domain controllers on which the
DNS service is installed in the entire forest.
You can use this option only when all your
domain controllers are running Windows
Server 2003.
All DNS servers in a specified AD domain This is the default zone replication setting for
DNS installed on Windows Server 2003
domain controllers. Zone information is repli-
cated to all the Windows Server 2003 domain
controllers on which the DNS service is
installed in the domain. This option is desir-
able when you want to limit or restrict replica-
tion of zone information to only the domain
controllers in your AD domain. Zone informa-
tion is not replicated to Windows 2000

domain controllers.
All domain controllers in the AD domain This option replicates DNS zone information
to all domain controllers in the AD domain,
regardless of whether or not the DNS service
is installed on them. This option is desirable in
mixed environment where Windows 2000
domain controllers are used.
All domain controllers specified in the This option allows the customization of your
replication scope of a DNS application zone replication environment. To use this
directory partition option, your Windows Server 2003 domain
controllers running DNS must be enlisted in
the application directory partition. You can
use the Dnscmd command-line utility to enlist
DNS servers. The syntax for the command is
dnscmd [DNS_server_name]
/EnlistDirectoryPartition [FQDN of partition].
All
fields are required.
A significant advantage of using the application directory partition to store zone data is that the
data is not replicated throughout the AD forest in the Global Catalog.This would be the case if AD
zone data were stored in the domain partition, as it is in Windows 2000. When using intersite repli-
cation (replication between different sites), the application directory partition is replicated according
to the same schedule as the domain partition.
To change the replication scope, you can use the DNS console, which presents the choices indi-
cated in Figure 20.4.There are four choices, corresponding to the descriptions in Table 20.1.The
680 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 680
choices are to replicate zone data to all DNS server in the AD forest, to all DNS servers in the AD
domain, to all domain controllers in the AD domain, and to all domain controllers specified in the
scope of [a specified] application directory partition.The last choice to customize the zone replica-

tion environment is grayed out and unavailable because the server has not been enlisted in other
partitions.
By default, when you first create an Active Directory-integrated zone and an application direc-
tory partition has not been created, you have the option of creating the partition using the DNS
console utility.You can also use the Ntds utility to create or delete application directory partitions
and the Dnscmd utility to create the default application directory partitions. If the default partitions
have already been created, you will get an error message indicating that the partition already exists.
When you use the DNS console utility to create the application directory partition, you are pre-
sented with two exclusive choices:
■
To create a single application directory partition that stores DNS zone data and replicates
that data to all DNS servers in the domain. If you respond No to this choice, you will be
presented with the second choice.
■
To create a single application directory partition that stores DNS zone data and replicates
that data to all DNS servers in the forest.This creates the broadest scope for replication of
DNS zone data.
Figure 20.5 shows the choices for creating an application directory partition using the DNS
console.The two dialog boxes below the DNS console window appear when you use the DNS
console to create the default application directory partitions.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 681
Figure 20.4 Changing Replication Scope for Windows Server 2003 Active Directory-
integrated Zones
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 681
Security for Zone Replication
To secure zone replication, you can configure Microsoft DNS to transfer zone information to only
those servers that are found in the zone’s name server list. However, you can further tighten security
by specifying individual IP addresses that are allowed to receive zone transfers.
In situations where you are transferring zone transfer information over the Internet or you are
concerned that this traffic can be intercepted, you should also consider using virtual private network

(VPN) tunnels or Internet Protocol Security (IPSec) to encrypt this traffic.
Using Active Directory-integrated zones also increases the security of your replication data by
ensuring that all DNS servers are registered in AD and by using the security mechanisms inherent in
AD replication.The security for zone transfers arises from the security of AD when you use Active
Directory-integrated zones. Where possible, you should use Active Directory-integrated zones
exclusively to improve performance and security of zone replication traffic.
General Guidelines for Planning for Zone Replication
You should keep the following guidelines in mind when planning for the distribution of zone files
in your infrastructure:
■
Limiting the number of zones of authority in your DNS infrastructure simplifies adminis-
tration. For each subdomain that has a separate zone of authority, you must ensure that the
delegation of authority is correct for the subdomain and plan for the appropriate zone
replication for each of these subdomains.
■
Distributing zone files increases the traffic associated with zone transfers or AD replication.
682 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.5 Creating the application directory partition using the DNS console
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 682
■
Distributing zone files reduces the amount of traffic associated with name resolution
queries.
■
Distributing zone files provides a means for supporting a disjointed namespace.
■
Distributing zone files increases availability and fault tolerance. It also reduces query
response times.
■
If you are using Active Directory-integrated zones and all your DNS servers are installed
on Windows Server 2003 domain controllers, you can use an application directory parti-

tion to reduce the replication traffic associated with the transfer of zone information.
■
You can minimize the bandwidth consumed by standard zone transfers by modifying the
schedule for transfers to secondary zones.
■
You should configure a primary server to notify only secondary servers. However, you
should note that configuring the notify list to transfer zone information with the IP
addresses of servers hosting the Active Directory-integrated zone can actually degrade per-
formance.
■
If you are using standard DNS zone transfers, you should try to implement incremental
zone transfers and fast zone transfers where possible.
■
A DNS server that is hosting an Active Directory-integrated zone or a standard primary
zone can also host a standard secondary zone for another domain.
■
A stub zone is a synchronized copy of a subset of an authoritative zone’s RRs: the SOA,
NS, and glue address records that identify authoritative name servers for a particular
domain.
■
A stub zone can reduce cross-domain referral and other DNS traffic.
■
Security of zone data should be a consideration in your design and implementation.
Active Directory-integrated zones provide more security than standard zone types. If you
are using standard zone types, security can be enhanced by restricting the hosts that are
allowed to receive zone transfers and by encrypting zone transfer traffic using VPN tunnels
or IPSec, using the strongest level of encryption possible.
Planning for Forwarding
Distributing zone files throughout your infrastructure provides one means of ensuring efficient DNS
name resolution. However, it is not always desirable or possible to distribute zone files to facilitate

efficient DNS name resolution.
A forwarder is simply a DNS server that receives queries that are forwarded to it by other DNS
servers that are not capable of resolving the DNS query. Whenever a DNS server receives a query, it
will try to answer the query from the data stored in its zone files or cache. Unless it has been con-
figured otherwise (that is, as a nonrecursive server or a root-level server), if the DNS server cannot
answer the query from its data, it will either contact authoritative root servers or forward the query
to a forwarder.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 683
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 683
Servers that are configured to not use recursion are called forward-only servers.You configure a
forward-only server by checking the box labeled Do not use recursion for this domain in the
Forwarders property page (see Figure 20.7 in the next section).
Using forwarders can help reduce the amount of DNS traffic related to recursion, in addition to
reducing the traffic related to zone replication.Their use can also help to enhance security by mini-
mizing the number of DNS servers that need to communicate with one another across firewalls.
Other advantages can be realized by using conditional forwarding, a new feature of Windows Server
2003 DNS.
Conditional Forwarding
Conditional forwarding adds intelligence to the forwarding of DNS queries. In previous versions of
Microsoft DNS, you could configure a forwarding server to forward queries for all domains it could
not resolve to only a single set of forwarders. In this setup, the list of forwarders was responsible for
resolving names for the entire domain namespace on behalf of the forwarding server. With condi-
tional forwarding, it is possible for the DNS administrator to configure a forwarding server to con-
tact different sets of forwarders based on the domain name in the query. Figure 20.6 shows a
possible design configuration for conditional forwarding.
In Figure 20.6, dns1.syngress.net has been configured to send any query requests for hosts in the
corp.tacteam.net domain directly to a dns1.corp.tacteam.net, which is authoritative for the zone. If
conditional forwarding had not been configured, dns1.syngress.net would need to send a set of iter-
ative queries to the root servers and dns1.tacteam.net in order to find the server that is authoritative
for corp.tacteam.net.This configuration helps to eliminate network traffic related to DNS name res-

684 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.6 Conditional Forwarding Configured to Send Queries Directly to an
Authoritative Server
dns1.tacteam.net
authoritative for tacteam.net
dns1.corp.tacteam.net
authoritative for corp.tacteam.net
dns1.shinder.net
DNS conditional forwarding
configured to send queries for
corp.tacteam.net directly to
dns1.corp.tacteam.net
DNS client
Query for host on corp.tacteam.net
Root DNS servers
delegation of authority
delegation of authority
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 684
olution and reduces DNS query response time. Also, since dns1.syngress.net is a direct point of con-
tact with dns1.corp.tacteam.net, over time, it would acquire a significant number of cached RRs for
hosts in the corp.tacteam.net domain.
Figure 20.7 shows conditional forwarding configured for the corp.tacteam.net domain. Note
that you can disable recursion on a per-domain basis.
General Guidelines for Using Forwarders
The following guidelines might assist you in planning to use forwarders as part of a DNS
infrastructure:
■
Forwarders can eliminate the need to host secondary zone files across slow WAN links
that might otherwise saturate bandwidth during zone replication.
■

Conditional forwarders can directly query authoritative name servers based on the domain
name in the query.
■
Conditional forwarders can assist in providing support for a disjointed namespace and are a
preferred solution over using stub zones for the same purpose.
■
Fault tolerance can be enhanced by specifying multiple forwarders and by enabling recur-
sion if queries to forwarders fail.
■
Using forwarders can enhance security by minimizing the number of DNS servers that
need to communicate with each other across firewalls.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 685
Figure 20.7 Conditional Forwarding for the corp.tacteam.net Domain
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 685