Deploying DNS

C H A P T E R 3
Deploying DNS
Microsoft® Windows® Server 2003 Domain Name System (DNS) provides efficient name resolution and
interoperability with standards-based technologies. Deploying DNS in your client/server infrastructure
enables resources on a TCP/IP network to locate other resources on the network by using host name-to-IP
address resolution and IP address-to-host name resolution. The Active Directory® directory service requires
DNS for locating network resources.
In This Chapter
Overview of DNS Deployment............................................................. ................114
Examining Your Current Environment........................................................... .......120
Designing a DNS Namespace................................................................. .............122
Designing a DNS Server Infrastructure.......................................................... ......141
Designing DNS Zones...................................................................................... ....147
Configuring and Managing DNS Clients.................................................... ...........154
Securing Your DNS Infrastructure...................................................... ..................155
Integrating DNS with Other Windows Server 2003 Services................................164
Implementing Windows Server 2003 DNS............................................. ..............168
Additional Resources.............................................................................. .............174
Related Information
• For more information about DNS, the Windows Server 2003 DNS Server service, and
Windows Server 2003 DNS Client service, see the Networking Guide of the Microsoft®
Windows® Server 2003 Resource Kit (or see the Networking Guide on the Web at
http://www.microsoft.com/reskit).
114 Chapter 3 Deploying DNS
Overview of DNS Deployment

DNS is the primary method for name resolution in the Microsoft® Windows® Server 2003, Standard Edition;
Windows® Server 2003, Enterprise Edition; and Windows® Server 2003, Datacenter Edition operating
systems (collectively referred to as “Windows Server 2003” in this chapter). DNS is also a requirement for
deploying Active Directory, but Active Directory is not a requirement for deploying DNS. However,
integrating DNS with Active Directory enables DNS servers to take advantage of the security, performance,
and fault tolerance capabilities of Active Directory.
If you are planning to deploy DNS to support Active Directory, plan your DNS namespace in conjunction
with planning your Active Directory logical structure. For more information about designing the Active
Directory logical structure, see “Designing the Logical Structure” in Designing and Deploying Directory and
Security Services of this kit.
Implementing Windows Server 2003 DNS 115
Process for Deploying DNS

Deploying DNS involves planning and designing your DNS infrastructure, including the DNS namespace,
DNS server placement, DNS zones, and DNS client configuration. In addition, if you are integrating DNS
with Active Directory, you must plan the level of integration and identify your security, scalability, and
performance requirements. Figure 3.1 shows the DNS deployment process.
Figure 3.1 Deploying DNS
DNS Concepts
Windows Server 2003 DNS is based on Requests For Comments (RFCs) standards developed by the Internet
Engineering Task Force (IETF) and is therefore interoperable with other standards-compliant DNS
implementations. DNS uses a distributed database that implements a hierarchical naming system. This
naming system enables an organization to expand its presence on the Internet and enables the creation of
names that are unique both on the Internet and on private TCP/IP-based intranets.
By using DNS, any computer on the Internet can look up the name of any other computer in the Internet
namespace. Computers running Windows Server 2003 and Microsoft® Windows® 2000 also use DNS to
locate domain controllers and other servers running Active Directory.
DNS Roles
Deploying a DNS infrastructure involves design, implementation, and maintenance tasks. The individuals
who are responsible for these tasks include DNS designers and the DNS administrators. Before you begin
designing your DNS deployment, it is helpful to identify the individuals in your organization who are
responsible for these roles. Table 3.1 lists the responsibilities of the DNS designer and DNS administrator
roles.
Table 3.1 DNS Roles
Role Responsibility
DNS designer • Designing the DNS namespace
• Placing DNS servers and zones within the DNS
namespace
• Creating a secure DNS infrastructure
• Designing DNS integration with Active Directory
DNS administrator • Deploying, configuring, and managing the DNS
infrastructure
• Managing Active Directory integration
DNS designer role

If you are deploying DNS to support Active Directory in an environment that does not already have a DNS
infrastructure, the DNS designer is responsible for the DNS integration with the entire Active Directory
forest. The DNS designer works closely with the DNS administrator for Active Directory.
If you are deploying DNS to support Active Directory in an environment that has an existing DNS
infrastructure, the DNS designer works with the DNS administrator for Active Directory to delegate the
forest root DNS name to Active Directory. The Active Directory forest administrator delegates management
of DNS to a DNS administrator.
DNS administrator role
DNS administrators manage and maintain the DNS namespace, DNS servers, DNS clients, DNS zones, and
zone propagation. DNS administrators are also responsible for maintaining network security by anticipating
and mitigating new security threats. In addition, DNS administrators are responsible for DNS integration
with other Windows Server 2003 services.
New in Windows Server 2003

Windows Server 2003 DNS includes several new features, including:
• Conditional forwarding. Conditional forwarding enables a DNS server to forward DNS
queries based on the DNS domain name in the query. For more information about
conditional forwarding, see Help and Support Center for Windows Server 2003.
• DNS application directory partitions. DNS application directory partitions enable you to
set the replication scope for Active Directory–integrated DNS data. By limiting the scope of
replication traffic to a subset of the servers running Active Directory in your forest, you can
reduce replication traffic.
• DNSSEC. DNS provides basic support for the DNS Security Extensions (DNSSEC)
protocol as defined in RFC 2535: Domain Name System Security Extensions. For more
information about DNSSEC, see Help and Support Center for Windows Server 2003.
• EDNS0. Extension Mechanisms for DNS (EDNS0) enable DNS requestors to advertise the
size of their UDP packets and facilitate the transfer of packets larger than 512 octets, the
original DNS limit for UDP packet size. For more information about EDNS0, see Help and
Support Center for Windows Server 2003.
Tools for Deploying DNS

Windows Server 2003 includes a number of tools to assist you in deploying a DNS infrastructure.
Netdiag.exe
The Netdiag.exe tool assists you in isolating networking and connectivity problems. Netdiag.exe performs a
series of tests that you can use to determine the state of your network client. For more information about
Netdiag.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows
Support Tools
Nslookup.exe
You can use the Nslookup.exe command-line tool to perform query testing of the DNS domain namespace
and to diagnose problems with DNS servers.
Dnscmd.exe
You can use the Dnscmd.exe command-line tool to perform administrative tasks on the DNS server the same
as you can by using the DNS Microsoft Management Console (MMC) snap-in.
DNSLint
DNSLint is a command-line tool that you can use to address some common DNS name resolution issues,
such as lame delegation and DNS record verification. DNSLint is in the Support.cab file in the
\Support\Tools folder on the Windows Server 2003 operating system CD. You can install DNSLint by
running Suptools.msi.
Terms and Definitions

The following are some important DNS-related terms.
Authoritative DNS server A DNS server that hosts a primary or secondary copy of zone data. Each
zone has at least one authoritative DNS server.
Conditional forwarding
A DNS query setting that enables a DNS server to route a request for a
particular name to another DNS server by specifying a name and IP address. For example, a DNS server in
contoso.com can be configured to forward queries for names in treyresearch.com to a DNS server hosting the
treyresearch.com zone.
Delegation
The process of using resource records to provide pointers from parent zones to child
zones in a namespace hierarchy. This enable DNS servers in a parent zone to route queries to DNS servers in
a child zone for names within their branch of the DNS namespace. Each delegation corresponds to at least
one zone.
DNS client resolverA service that runs on client computers and sends DNS queries to a DNS
server. Some resolvers use a cache to improve name resolution performance.
DNS namespace The hierarchical naming structure of the domain tree. Each domain label that is
used in a fully qualified domain name (FQDN) indicates a node or branch in the domain tree. For example,
host1.contoso.com is an FQDN that represents the node host1, under the node Contoso, under the node com,
under the DNS root.
DNS server
A computer that hosts DNS zone data, resolves DNS queries, and caches the query
responses.
Domain In tree
DNS, the inverted hierarchical tree structure that is used to index domain names
within a namespace. Domain trees are similar in purpose and concept to the directory trees used by computer
filing systems for disk storage.
Public namespace A namespace on the Internet, such as www.microsoft.com, that can be accessed
by any connected device. Beneath the top-level domains, the Internet Corporation for Assigned Names and
Numbers (ICANN), the Internet Assigned Numbers Authority (IANA), and other Internet naming authorities
delegate domains to organizations such as Internet Service Providers (ISPs), which in turn delegate
subdomains to their customers or host zones for their customers. For more information about public
namespaces, see the Internet Assigned Numbers Authority (IANA) link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
Forward lookup zone
An authoritative DNS zone that is primarily used to resolve network resource
names to IP addresses.
Fully qualified domain name (FQDN) A DNS name that uniquely identifies a node in a DNS
namespace. The FQDN of a computer is a concatenation of the computer name (for example, client1) and the
primary DNS suffix of the computer (for example, contoso.com), and a terminating dot (for example,
contoso.com.).
Internal namespace A namespace internal to an organization to which it can control access.

Organizations can use the internal namespace to shield the names and IP addresses of its internal computers
from the Internet. A single organization might have multiple internal namespaces. Organizations can create
their own root servers and any subdomains as needed. The internal namespace can coexist with an external
namespace.
Iterative query
A query made by a client to a DNS server for an authoritative answer that can be
provided by the server without generating additional server-side queries to other DNS servers.
Primary DNS server A DNS server that hosts read-write copies of zone data, has a DNS database of
resource records, and resolves DNS queries.
Secondary DNS server A DNS server that hosts a read-only copy of zone data. A secondary DNS
server periodically checks for changes made to the zone on its configured primary DNS server, and performs
full or incremental zone transfers, as needed.
Recursive queryA query made by either a client or a DNS server on behalf of a client, the response
to which can be an authoritative answer or a referral to another server. Recursive queries continue until the
DNS server receives an authoritative answer for the queried name. By default, recursion is enabled for
Windows Server 2003 DNS.
Resource record (RR)A DNS database structure containing name information for a particular
zone. For example, an address (A) resource record can map the IP address 172.16.10.10 to the name
DNSserverone.contoso.com or a namespace (NS) resource record can map the name contoso.com to the
server name DNS1.contoso.com. Most of the basic RR types are defined in RFC 1035: Domain Names —
Implementation and Specification, but additional RR types are defined in other RFCs.
Reverse lookup zone
An authoritative DNS zone that is primarily used to resolve IP addresses to
network resource names.
Stub zone
A partial copy of a zone that can be hosted by a DNS server and used to resolve recursive
or iterative queries. Stub zones contain the Start of Authority (SOA) resource records of the zone, the DNS
resource records that list the zone’s authoritative servers, and the glue address (A) resource records that are
required for contacting the zone’s authoritative servers. Stub zones are used to reduce the number of DNS
queries on a network, and to decrease the network load on the primary DNS servers hosting a particular
name.
Zone In a DNS database, a contiguous portion of the domain tree that is administered as a
single separate entity by a DNS server. The zone contains resource records for all of the names within the
zone.
ZoneAfile
file that consists of the DNS database resource records that define the zone. DNS data
that is Active Directory–integrated is not stored in zone files because the data is stored in Active Directory.
However, DNS data that is not Active Directory–integrated is stored in zone files.
Zone transfer
The process of copying the contents of the zone file located on a primary DNS server
to a secondary DNS server. Using zone transfer provides fault tolerance by synchronizing the zone file in a
primary DNS server with the zone file in a secondary DNS server. The secondary DNS server can continue
performing name resolution if the primary DNS server fails.
Examining Your Current

Environment
Before you deploy Windows Server 2003 DNS, you must assess your current environment to determine the
DNS needs and constraints of your organization. After that, create a Windows Server 2003 DNS deployment
plan to match those needs and constraints. Figure 3.2 shows the process for examining your current
environment.
Figure 3.2 Examining Your Current Environment
Determining Internet Status

If you want devices outside your private network to be able to resolve names belonging to your internal
namespace, your IP addresses and DNS domain names must be registered with an Internet registration
authority (Internet registrar). Internet registrars are organizations that are responsible for:
• Assigning IP addresses.
• Registering DNS domain names.
• Keeping public records of registered IP addresses and domain names.
If your network is currently or will be connected to the Internet, you must ensure that the domain name of
your organization is valid and registered to you.
Identifying the DNS Data Host

Determine who will host your DNS data. You can either host your DNS data on your own DNS servers or
you can have an external ISP host your DNS data. By hosting your own DNS data, you have complete
control of network resource allocation and security. Use an ISP if you have a small network that will not be
expanding rapidly in the near future.
If you decide to use an ISP to host your DNS data, ensure that the DNS infrastructure of the ISP can support
your DNS deployment.
Even if you decide to host your own DNS data, you might consider using an ISP to resolve names outside
your private network. For example, the company contoso.com might decide to host all names belonging to
the internal namespace corp.contoso.com on its own DNS servers while using an ISP to enable its employees
to resolve external Web addresses such as www.microsoft.com.
Analyzing Your Network Topology

Analyze your existing network topology and plan your DNS namespace while accounting for the service and
administrative goals of your organization.
Allow for anticipated expansion of the number of nodes in your DNS hierarchy by including domain name
placeholders between the domain names that you are initially deploying. Adding domain name placeholders
enables you to avoid having to redesign your DNS infrastructure to accommodate additional domain names.
Anticipate the possibility of changes to your business model by assigning domain names that can be used in a
modified context. For example, instead of using the domain name accounting.contoso.com, you might use
finance.contoso.com, in anticipation of the possibility of expanding into additional financial services beyond
accounting.
Diagram Your Existing DNS Infrastructure

If you are upgrading to Windows Server 2003, rolling out a new DNS deployment, or integrating Windows
Server 2003 DNS with Active Directory, you might not need to make any changes to your existing DNS
infrastructure. However, if you are migrating from a third-party DNS infrastructure or integrating Windows
Server 2003 DNS with an existing third-party DNS infrastructure, create a diagram of your existing DNS
infrastructure, including domains, servers, and clients. Use this diagram to assist you in deciding whether to
make changes to your current DNS infrastructure when you deploy Windows Server 2003 DNS.
Identify Your Security Policies

Identify and document your organization’s security policies before you begin to design and deploy your DNS
infrastructure. In this way, you can ensure that your DNS servers, zones, and resource records support these
policies. For more information about security policies, see “Deploying Security Policy” in Designing a
Managed Environment of this kit.
Designing a DNS Namespace

Before you deploy a DNS infrastructure, the DNS designer in your organization must design a DNS
namespace. You can design an external namespace that is visible to Internet users and computers, or you can
design an internal namespace that is accessible only to users and computers that are within the internal
network. After your DNS namespace has been deployed, DNS administrators are responsible for managing
and maintaining the DNS namespace. Figure 3.3 shows the process for designing a DNS namespace.
Figure 3.3 Designing a DNS Namespace

Identifying Your DNS Namespace

Requirements
The first step in designing a DNS namespace is to determine whether you need a new namespace for your
organization, or whether you can retain an existing Windows or third-party DNS namespace.
Important
You must plan your DNS namespace in conjunction with planning your
Active Directory logical structure. For more information about designing
the Active Directory logical structure, see “Designing the Active
Directory Logical Structure” in Designing and Deploying Directory and
Security Services of this kit.
Table 3.2 summarizes the DNS namespace design requirements for each possible scenario.
Table 3.2 DNS Namespace Design Requirements
Scenario Design Requirements
You are upgrading an existing DNS DNS namespace design can remain the
infrastructure from a version of Windows same.
earlier than Windows Server 2003.
You are upgrading from a third-party DNS DNS namespace design can remain the
infrastructure that uses DNS software that same.
adheres to standard DNS domain naming
guidelines.
Your existing DNS software does not Bring your existing DNS namespace
conform to standard DNS domain naming design into compliance with DNS domain
guidelines. naming guidelines before deploying a
Windows Server 2003 DNS namespace.
You are integrating Windows Server 2003 Integrate Windows Server 2003 DNS
DNS into an existing third-party DNS with your current DNS infrastructure.
software that adheres to standard DNS You do not need to change the
domain naming guidelines. namespace design of the third-party
DNS infrastructure or your existing
namespace.
You are deploying a new Windows Design a logical naming convention for
Server 2003 DNS infrastructure. your DNS namespace based on DNS
domain naming guidelines.
You are deploying Windows Create a DNS namespace design that is
Server 2003 DNS to support Active based on your Active Directory naming
Directory. convention.
You are modifying your existing DNS Ensure that Active Directory domain
namespace to support Active Directory, names match your existing DNS

but you do not want to redesign your DNS names. This enables you to deploy the
namespace. highest level of security by using the
simplest management techniques.
Creating Internal and External Domains

Organizations that require an Internet presence as well as an internal namespace must deploy both an internal
and an external DNS namespace and manage each namespace separately. You can create a mixed internal and
external DNS namespace in one of two ways:
• By making the internal domain a subdomain of the external domain.
• By using different names for the internal and external domains.
Note
You can also use the same name for the internal domain and the
external domain. However, this method is not recommended. It creates
name resolution problems because it introduces DNS names that are
not unique. This method requires additional configuration to enable
optimized performance.
Select the configuration design option that best meets the needs of your organization. Table 3.3 lists the
design options for deploying a mixed internal and external namespace and the level of management
complexity for each option, along with an example to illustrate each option.
Table 3.3 Mixed Internal and External DNS Namespace Design Options
Management
Design Option Example
Complexity
The internal domain Easy to deploy and An organization with an
is a subdomain of administer. external namespace
the external domain. contoso.com uses the internal
namespace corp.contoso.com.
The internal and More complicated than An organization uses
external domain previous option. contoso.com for its external
names are different namespace, and corp.internal
from each other. for its internal namespace.
Using an Internal Subdomain

The recommended configuration option for a mixed internal and external DNS namespace is to make your
internal domain a subdomain of your external domain. For example, an organization that has an external
namespace domain name of contoso.com might use the internal namespace domain name corp.contoso.com.
Using an internal domain that is a subdomain of an external domain:
• Requires you to register only one name with an Internet name authority even if you later
decide to make part of your internal namespace publicly accessible.
• Ensures that all of your internal domain names are globally unique.
• Simplifies administration by enabling you to administer internal and external domains
separately.
You can use your internal subdomain as a parent for additional child domains that you create to manage
divisions within your company. Child domain names are immediately subordinate to the DNS domain name
of the parent. For example, a child domain for the human resources department that is added to the
us.corp.contoso.com namespace might have the domain name hr.us.corp.constoso.com.
Using Different Internal and External Domain Names

If it is not possible for you to configure your internal domain as a subdomain of your external domain, use a
stand-alone internal domain. This way, your internal and external domain names are unrelated. For example,
an organization that uses the domain name contoso.com for their external namespace uses the name
corp.internal for their internal namespace.
The advantage to this approach is that it provides you with a unique internal domain name. The disadvantage
is that this configuration requires you to manage two separate namespaces. Also, using a stand-alone internal
domain that is unrelated to your external domain might create confusion for users because the namespaces do
not reflect a relationship between resources within and outside of your network. In addition, you might have
to register two DNS names with an Internet name authority if you want to make the internal domain publicly
accessible.
Deciding Whether to Deploy an Internal

DNS Root
If you have a large distributed network and a complex DNS namespace, it is best to use an internal DNS root
that is isolated from public networks. Using an internal DNS root streamlines the administration of your DNS
namespace by enabling you to administer your DNS infrastructure as if the entire namespace consists of the
DNS data within your network.
If you use an internal DNS root, a private DNS root zone is hosted on a DNS server on your internal
network. This private DNS root zone is not exposed to the Internet. Just as the DNS root zone contains
delegations to all of the top-level domain names on the Internet, such as .com, .net, and .org, a private root
zone contains delegations to all of the top-level domain names on your network. The DNS server that hosts
the private root zone in your namespace is considered to be authoritative for all of the names in the internal
DNS namespace.
Using an internal DNS root provides the following benefits:
• Simplicity. If your network spans multiple locations, an internal DNS root might be the best
method for administering DNS data in a network.
• Secure name resolution. With an internal DNS root, DNS clients and servers on your
network never contact the Internet to resolve internal names. In this way, the DNS data for
your network is not broadcast over the Internet. You can enable name resolution for any
name in another namespace by adding a delegation from your root zone. For example, if
your computers need access to resources in a partner organization, you can add a delegation
from your root zone to the top level of the DNS namespace of the partner organization.
Important
Do not reuse names that exist on the Internet in your internal
namespace. If you repeat Internet DNS names on your intranet, it can
result in name resolution errors.
If name resolution is required by computers that do not support software proxy, or by computers that support
only LATs, then you cannot use an internal root for your DNS namespace. In this case, you must configure
one or more internal DNS servers to forward queries that cannot be resolved locally to the Internet.
Table 3.4 lists the types of client proxy capabilities and whether you can use an internal DNS root for each
type.
Table 3.4 Client Proxy Capabilities
Microsoft Software with Can You Use
Forwards
Proxy Capability Corresponding Proxy an Internal
Queries
Capabilities Root?
No Proxy Generic Telnet
Local Address Winsock Proxy (WSP) 1.x
Table (LAT) and later
Microsoft® Internet Security
and Acceleration (ISA)
Server 2000 and later
Name Exclusion WSP 1.x and later
List Internet Security and
Acceleration (ISA) Server
2000 and later, and all
versions of Microsoft®
Internet Explorer
Proxy Auto- WSP 2.x, Internet Security
configuration and Acceleration Server
(PAC) File (ISA) Server 2000 and later,
Internet Explorer 3.01 and
later
Configuring Name Resolution for

Disjointed Namespaces
If you need to create or merge two DNS namespaces when you deploy Windows Server 2003 DNS, this can
result in disjointed namespaces — a DNS infrastructure that includes two or more top-level DNS domain
names. To configure internal name resolution for multiple DNS top-level domains, you must do one of the
following:
• If you have an internal DNS root, add delegations for each top-level DNS zone to the
internal DNS root zone.
• If you want to reduce cross-domain DNS query traffic, configure the DNS servers that host
the DNS zones in the first and second namespaces to host secondary zones for the DNS
zones in each other’s namespaces. In this configuration, the DNS servers that host the DNS
zones in each namespace are aware of the DNS servers in the other namespace. This solution
requires increased storage space for hosting secondary copies of zones in different
namespaces, and generates increased zone transfer traffic.
• If storage capacity on DNS servers is a consideration, configure the DNS servers that host
the DNS zones in one namespace to forward name resolution queries in a second namespace
to the DNS servers that are hosting the DNS zones for the second namespace. Then
configure the DNS servers that host the DNS zones in the second namespace to forward
name resolution queries in the first namespace to the DNS servers that are hosting the DNS
zones for the first namespace. You can use Windows Server 2003 DNS conditional
forwarders for this configuration.
You can also use Windows Server 2003 DNS stub zones to facilitate DNS data distribution between separate
namespaces. For more information about conditional forwarders and stub zones, see Help and Support Center
for Windows Server 2003 and the Networking Guide of the Windows Server 2003 Resource Kit (or see the
Networking Guide on the Web at http://www.microsoft.com/reskit).
Integrating a Windows Server 2003 DNS

Infrastructure Into an Existing DNS
Namespace
Windows Server 2003 DNS is standards-compliant and interoperates with other implementations of DNS,
including Microsoft® Windows NT® version 4.0, BIND 9.1.0, BIND 8.2, BIND 8.1.2, and BIND 4.9.7. The
complexity of your integration process depends, in part, on the DNS features that you need to support. If the
computers in your DNS infrastructure are running versions of DNS that support the same features, then
integrating the Windows Server 2003 DNS infrastructure is a simple process. If the computers in your DNS
infrastructure are running versions of DNS that do not support the same DNS features, then the integration
process is more complex.
Table 3.5 compares feature support in Windows Server 2003 DNS and other implementations of DNS.
Table 3.5 Feature Support in Different Implementations of DNS
Windows Windo Windo B
BIND BIND BIND
Feature Server 200 ws 200 ws NT IND
8.2 8.1.2 4.9.7
3 0 4.0 9
Supports
RFC 2782: A DNS
RR for specifying
the location of
services (DNS
SRV)
Dynamic update
Secure dynamic
update based on
the GSS-
Transaction
signature (TSIG)
algorithm
WINS and
WINS-R records
Incremental zone
transfer
UTF-8 character
encoding
DNS MMC snap-
in
Dnscmd.exe
Active Directory–
integrated zones
Storage of zones
in the DNS
application
directory
partition
Aging and
scavenging of
obsolete records
Stub zones
Conditional
forwarding
Creating DNS Domain Names and

Computer Names
Before you deploy your Windows Server 2003 DNS infrastructure, you must create a naming convention for
your DNS Internet and internal domains and the DNS computers on your network. To create a DNS naming
convention, you must establish the following:
• An Internet DNS domain name, if your organization is connected to the Internet.
• An internal DNS domain name for your organization.
• A DNS resource naming convention.
In addition, you must determine whether you need to support NetBIOS names in your organization.
Creating an Internet DNS Domain Name

If you are deploying a new Windows Server 2003 DNS infrastructure that is connected to the Internet, you
must create an Internet DNS domain name for your organization. Because all of the nodes in your network
that require name resolution are assigned a DNS name that includes the Internet DNS domain name for your
organization, it is important to select an Internet DNS domain name that is short and easy to remember.
Because DNS is hierarchical, DNS domain names grow when you add subdomains to your organization.
Short domain names result in computer names that are easy to remember, facilitating resource access.
A DNS namespace that is connected to the Internet must be a subdomain of a top-level or second-level
domain of the Internet DNS namespace. If you are deploying a new Windows Server 2003 DNS namespace,
you must select a top-level Internet DNS domain in which to register your Internet DNS domain name. For
example, you can register your domain as a subdomain of .com, .org, or .net, or as a subdomain of the
domain name that is assigned to your country/region, such as .au (Australia), .fr (France) or .ca (Canada).
When you have selected your Internet DNS domain name and identified the top-level domain for which your
DNS domain is a subdomain, complete the following steps to register your DNS domain name:
1. Search the Internet to confirm that the DNS domain name that you selected for your
organization is not registered to another organization. If the DNS domain name that you
selected is owned by another organization, you can attempt to buy it from that organization,
or select a different DNS domain name.
2. Configure at least one authoritative DNS server to host the DNS zone for your domain name.
This DNS server might be located on your network or on the network of your ISP.
3. Register your DNS domain name with an Internet registrar, and supply the registrar with the
DNS name and IP address of at least one DNS server that is authoritative for your DNS
domain name. For a list of Internet registrars, see the ICANN link on the Web Resources
page at http://www.microsoft.com/windows/reskits/webresources.
The Internet domain name registration process varies according to the design of your DNS namespace.
Table 3.6 lists the domain names that you need to register for each type of DNS namespace design.
Table 3.6 Internet DNS Domain Name Registration
Domain Name
Namespace Design Example
Registration
The internal domain Register only the external The domain name
name is a subdomain domain name. contoso.com is used for
of the external domain. the external namespace.
The domain name
corp.contoso.com is used
for the internal
namespace.
The internal and Register the external The domain name
external domain names domain name, and then, contoso.com is used for
are different from each if you want the internal the external namespace.
other. domain to be publicly The domain name
accessible, also register corp.contoso.com is used
the internal domain for the internal
name. namespace.
When you register your DNS domain name, the Internet registrar creates a delegation in the DNS zone that is
authoritative for the top-level domain that you selected. This is the top-level domain for the DNS servers that
are authoritative for your organization’s Internet DNS domain name.
Note
If a domain name that you want to register is not available in one top-
level domain, such as .com, and you register the same domain name in
another top-level domain, such as .net, then people who are searching
for your domain name on the Internet might assume that computers
and services in the wrong top-level domain belong to your company.
Creating Internal DNS Domain Names

When creating names for your internal domains, use the following guidelines:
• If your organization has an Internet presence, use names relative to your registered Internet
DNS domain name. For example, if you have registered the Internet DNS domain name
contoso.com for your organization, use a DNS domain name such as corp.contoso.com for
your intranet domain name.
• Do not use the name of an existing corporation or product as your domain name.
• Do not use top-level Internet domain names, such as .com, .net, .org, .us, .fr, .gr, on your
intranet. Using top-level Internet domain names on your intranet can result in name
resolution errors for computers on your network that are connected to the Internet.
• Do not use acronyms or abbreviations for domain names. The business units that these
acronyms represent can be difficult for users to recognize.
• Do not use business unit or division names for domain names. Business units and other
divisions change periodically and the domain names can become obsolete or misleading.
• Do not use geographic names that are difficult to spell and remember.
• Avoid extending your DNS domain name hierarchy more than five levels from the internal
or DNS root domain. Limiting the extent of the domain name hierarchy reduces
administrative costs.
If you are deploying DNS in a private network and do not plan to create an external namespace, it is
recommended that you register the DNS domain name that you create for your internal domain. If you do not
register the name and later attempt to use it on the Internet, or connect to a network that is connected to the
Internet, you might find that the name is unavailable.
Creating DNS Computer Names

It is important to develop a practical DNS computer naming convention for your network. This enables users
to remember the names of computers on public and private networks easily, and therefore facilitates access to
resources on your network.
The DNS computer name creation process varies according to whether you are creating a new DNS
infrastructure, integrating your DNS infrastructure with an existing third-party infrastructure, or upgrading an
existing DNS infrastructure.
Creating Computer Names in a New Windows Server 2003 DNS

Infrastructure
Use the following guidelines when creating names for the DNS computers in your new Windows
Server 2003 DNS infrastructure:
• Select computer names that are easy for users to remember.
• Identify the owner of a computer in the computer name. For example, john-doe-1 indicates
that John Doe uses the computer.
• Select names that describe the purpose of the computer. For example, a file server named
past-accounts-1 indicates that the file server stores information related to past accounts.
• Do not use character case to convey the owner or purpose of a computer. DNS is not
case-sensitive.
• If you are deploying DNS to support Active Directory, match the Active Directory domain
name to the primary DNS suffix of the computer name. For more information about
designing the Active Directory logical structure, see “Designing the Active Directory
Logical Structure” in Designing and Deploying Directory and Security Services of this kit.
• Use unique names for all computers in your organization. Do not assign the same computer
name to different computers in different DNS domains.
• Use ASCII characters to ensure interoperability with computers running versions of
Windows earlier than Windows 2000. For DNS computer names, use only the characters
listed in RFC 1123:Requirements for Internet Hosts — Application and Support, which
include A–Z, a–z, 0–9, and the hyphen (-). Windows Server 2003 DNS supports almost any
UTF-8 character in a name; however, do not use extended ASCII or UTF-8 characters unless
all of the DNS servers in your environment support them.
Note
Windows Server 2003 DNS is configured to use UTF-8 name checking
by default.
Creating Computer Names in an Integrated DNS Infrastructure

If you are integrating Windows Server 2003 DNS with an existing third-party DNS infrastructure, you do not
need to make any changes to your third-party DNS host names. If you are migrating to Windows
Server 2003 DNS from a third-party DNS infrastructure, you must ensure that the host names that are used in
the third-party DNS infrastructure conform to the DNS Internet naming standards.
If you are integrating or migrating an existing public DNS infrastructure that is connected to the Internet into
your existing DNS infrastructure, you do not need to make any changes to the DNS domain names of your
infrastructure.
Creating Computer Names When Upgrading a DNS Infrastructure

If you are upgrading to Windows Server 2003 DNS from Windows NT 4.0, you do not need to change your
DNS host names; however, you might need to convert any NetBIOS names to DNS names. DNS names must
conform to the DNS standard defined by RFC 1123.
Table 3.7 lists the different character sets that are supported by standard DNS, Windows Server 2003 DNS,
and NetBIOS.
Table 3.7 Character Set Restrictions
Character Standard DNS
DNS in Windows 2000 and
Set (Including NetBIOS
Windows Server 2003
Restriction Windows NT 4.0)
Characters Supports RFC 1123, Supports RFC 1123 and Not allowed:
permitted which permits A–Z, UTF-8. On a per-server Unicode
a–z, 0–9, and the basis, You can configure the characters,
hyphen (-). Windows 2000 DNS Server numbers,
service to allow or disallow white space,
the use of UTF-8 characters symbols: / \
on your DNS server. []:|<>+=
; , ? and *)
Maximum 63 octets per label. The same as standard DNS 16 bytes in
host name 255 bytes per FQDN with the addition of UTF-8 length.
and FQDN (254 bytes for the support. Character count is
length. FQDN plus one byte insufficient to determine
for the terminating size because some UTF-8
dot). characters exceed one octet
in length. Domain
controllers are limited to
155 bytes for an FQDN.
Important
Names encoded in UTF-8 format must not exceed the limits defined in
RFC 2181: Clarifications to the DNS Specification, which specifies a
maximum of 63 octets per label and 255 octets per name.
Determining if You Need to Support NetBIOS Names

During a domain upgrade to Windows Server 2003, you might need to support NetBIOS on your network if
your domain includes clients that are running versions of Windows earlier than Windows 2000. For example,
if your network is multi-segmented, WINS is required to create the NetBIOS browse list. Without WINS, the
network must rely on Active Directory for browsing resources. This can have a significant impact on clients
that are running applications that require NetBIOS support, even if the client operating system does not
require NetBIOS support. When WINS is installed, performance monitor counters for WINS are also
installed. Use these WINS performance monitor counters to determine how many queries WINS is receiving,
and how many names WINS is resolving. This information will help you to determine whether it is necessary
to support NetBIOS names on the network.
Windows Server 2003 DNS is compatible with WINS; therefore, in a mixed networking environment, you
can use a combination of DNS and WINS. Windows NT 4.0–based clients can register in both
Windows 2000 WINS and Windows Server 2003 WINS. Also, computers running either the Microsoft®
Windows® 2000 Professional or Windows® XP Professional operating systems can register in
Windows NT 4.0 WINS. To maintain backward compatibility, each computer is given a NetBIOS name that
must be unique in the domain to which the computer belongs.
Preserving existing NetBIOS names can be difficult because NetBIOS names have a broader character set
than DNS names. One solution is to replace NetBIOS names with DNS names to ensure that the names
adhere to existing DNS naming standards. This is not possible for organizations that support computers
running versions of Windows earlier than Windows 2000.
RFC 2181: Clarifications to the DNS Specification expands the character set that is allowed in DNS names to
include any binary string. The binary strings do not have to be interpreted as ASCII. Windows 2000 and
Windows Server 2003 support UTF-8 character encoding (RFC 2044). UTF-8 is a superset of ASCII and a
translation of the UCS-2 (or Unicode) character encoding. The UTF-8 character set enables you to transition
from Windows NT 4.0 NetBIOS names to Windows 2000 and Windows Server 2003 DNS names
By default, multibyte UTF-8 name checking is used. This provides the greatest tolerance when the DNS
service processes characters. This is the preferred name-checking method for most DNS servers that are not
providing name resolution services for Internet hosts.
Important
Windows Server 2003 and Windows 2000 DNS support NetBIOS and
UTF-8 characters for computer names. Other versions of DNS only
support the characters permitted in RFC 1123. Therefore, only use
NetBIOS and UTF-8 character sets when you are certain that Windows
Server 2003 or Windows 2000 DNS is the method used for name
resolution. Names that are intended to be visible on the Internet must
contain ASCII-only characters, as recommended in RFC 1123.
Creating Subdomains
If you are deploying DNS on a large enterprise network, or if you expect your network to expand to include
additional subnets and sites, consider distributing the management of portions of your DNS namespace to the
administrators for the different subnets and sites in your network. To distribute the management of your DNS
namespace, create subdomains of your initial DNS domain and delegate the authority for these subdomains
to DNS servers located on different subnets or sites. In this way, you can create any number of separate and
autonomous entities within a DNS namespace, each of which is authoritative for a portion of the overall
namespace.
Example: Merging DNS Namespaces

Contoso Corporation merged with Trey Research Corporation. Before the merger, each corporation used
internal domains that were subdomains of their external domains. The Contoso Corporation used a private
root to simplify their DNS server administration. The Trey Research Corporation forwarded queries to the
Internet, rather than using a private root.
The external namespace of the newly merged corporation contains the zones contoso.com and
treyresearch.com. Each zone in the external namespace contains the DNS resource records that the
companies want to expose to the Internet. The internal namespace contains the internal zones,
corp.contoso.com and corp.treyresearch.com.
The Contoso division and the Trey Research division each use a different method to support name resolution
for names in their namespace. The Contoso division uses the name contoso.com externally and
corp.contoso.com internally. The internal root servers host the root zone. Internal servers also host the zone,
corp.contoso.com. The name contoso.com is registered with an Internet name authority.
To ensure that every client within the organization can resolve every name in the newly merged organization,
the private root zone contains a delegation to the zone for the top level of the merged organization’s internal
namespace, corp.treyresearch.com.
To resolve internal and external names, every DNS client must submit all queries to either the internal DNS
servers or to a proxy server. Figure 3.4 shows this configuration.
Figure 3.4 Name Resolution in the Contoso Division
Based on this configuration, internal clients can query for names in the following ways:
• Query internal DNS servers for internal names. The internal DNS servers resolve the
query. If a DNS server that receives a query does not contain the requested data in its zones
or cache, it uses root hints to contact the internal root DNS servers.
• Query a proxy server for names on the Internet. The proxy server forwards the query to
DNS servers on the Internet. The DNS servers on the Internet resolve the query.
• Query internal DNS servers for names in the Trey Research division. Because the root
servers contain a delegation to the top level of the DNS namespace of the Trey Research
division, the internal DNS servers recursively resolve the query by contacting the DNS
servers in the Trey Research division.
External clients:
• Cannot query for internal names. This limitation helps secure the internal network.
• Query DNS servers on the Internet for names in the contoso.com external namespace.
The DNS servers on the Internet resolve the query.
The Trey Research division uses the name treyresearch.com externally and the name corp.treyresearch.com
internally. The server InternalDNS.treyresearch.com hosts the corp.treyresearch.com zone. The Trey
Research division does not have a private root.
To simplify management of clients and DNS servers, Trey Research division administrators decided to use
conditional forwarding. Administrators configured the DNS server InternalDNS.treyresearch.com to forward
queries in the following manner:
• The server forwards all queries destined for the Contoso division to a DNS server for the
Contoso division. For example, the server forwards queries destined for corp.contoso.com to
InternalDNS.contoso.com.
• At the same time, the server forwards all other queries destined for contoso.com to a DNS
server on the Internet.
Figure 3.5 shows this configuration.

Figure 3.5 Conditional Forwarding in the Trey Research Division
Designing a DNS Server

Infrastructure
DNS servers store information about the DNS namespace and use the information to answer queries from
DNS clients. The size of the DNS zone data, how many DNS clients you have, and where these clients are
physically located all impact your DNS server topology.
The DNS designer in your organization designs DNS servers that enable you to create an effective DNS data
distribution and update topology while minimizing query and zone transfer network traffic. The DNS
administrators in your organization manage and maintain your DNS servers. Figure 3.6 shows the process for
designing DNS servers.
Figure 3.6 Designing a DNS Server Infrastructure
Allocating Hardware Resources

A typical recommendation for DNS server hardware includes the following:
• Single-processor computers with 400 megahertz (MHz) Pentium II CPUs.
• 256 megabytes (MB) of RAM for each processor.
• At least 4 gigabytes (GB) of available hard disk space.
• A network adapter.
Using faster CPUs, more RAM, and larger hard drives improves the scalability and performance of your
DNS servers. DNS servers use approximately 100 bytes of RAM for each resource record. Using this figure,
you can calculate how much memory you need.
Determining the Number of Required DNS

Servers
To reduce administrative overhead, use the minimum number of DNS servers required. Be sure to make at
least two DNS servers authoritative for each zone to enable fault tolerance and load sharing.
Add additional DNS servers in order to:
• Provide redundancy when your namespace design requires greater DNS availability.
• Improve query response time when better DNS performance is required.
• Reduce WAN traffic for remote locations.
Use the following guidelines to determine the number of DNS servers that you need to deploy:
• If the ratio of DNS servers to clients is very low and you are experiencing significant name
resolution delays, add additional DNS servers to host secondary or Active Directory–
integrated zones. Use your anticipated number of queries and dynamic updates per second to
determine the number of DNS servers that you need. The Windows Server 2003 DNS Server
service is capable of responding to more than 10,000 queries per second on a Pentium III
microprocessor running at 700 MHz.
For information about capacity planning, see “Allocating Hardware Resources” earlier in
this chapter.
• If you delegate zones, add additional DNS servers to handle the delegated zones. Note that
you do not need to delegate zones when you have multiple zones. You can host all zones on
the same server or servers. One DNS server running Windows Server 2003 can host 20,000
small zones.
• If you plan to host Active Directory–integrated zones, you must place these zones on
Windows 2000–based or Windows Server 2003–based domain controller.
• If high-volume traffic is a consideration in your environment, add additional DNS servers to

balance the workload. Although DNS helps reduce broadcast traffic between local subnets, it
does create some traffic between servers and clients, particularly in complex routed
environments. In addition, although the DNS service supports incremental zone transfers
(IXFRs) and clients and servers can cache recently used names, traffic considerations can
still remain an issue, depending on available bandwidth. This is especially true when using
short Dynamic Host Configuration Protocol (DHCP) leases, which require more frequent
dynamic updates.
• If you have a high number of client nodes on a single subnet, placing more than one DNS
server on the subnet allows for backup and failover in the event that the primary DNS server
stops responding.
If your DNS design includes primary and secondary zones and you run a large number of secondary servers
for a zone, the primary DNS server can become overloaded when the secondary servers poll to ensure that
their zone data is current. You can solve this problem in one of three ways:
• Use some of the secondary DNS servers as primary servers for the zone. Other secondary
servers can poll and request zone updates from these primary servers.
• Increase the refresh interval so that the secondary servers poll less frequently. Note,
however, that a longer refresh interval might cause your secondary zones to be outdated
more often.
Determining DNS Server Placement

The placement of your DNS servers and the number of DNS servers that you deploy affects the availability
of DNS. It is important to ensure that you plan the placement of your DNS servers to allow for DNS
availability and Active Directory availability.
Placing DNS Servers for Availability

To ensure that DNS is always available, make sure that your DNS infrastructure does not include any single
points of failure. To improve fault tolerance and load sharing have clients point to a primary and alternate
DNS server. In a LAN configuration, place the pair of authoritative DNS servers on separate subnets. In a
WAN configuration, place the pair of authoritative DNS servers on different networks, and then ensure that at
least one DNS server is available for each network. This configuration removes routers as potential points of
failure. Whenever possible, distribute your DNS servers across different geographic locations to enable
communications to continue in the event of a natural disaster.
If you identify single points of failure in your network, determine whether they affect only DNS or all
network services. If a router goes down and your clients cannot access any network services, then DNS
failure is not an issue. If a router goes down and local DNS servers are unavailable but other network
services are available, then your clients cannot access required network resources because they cannot look
up DNS names.
If you have an Internet presence, DNS must be working properly for Internet clients to access your Web
servers, send mail, and locate other services; therefore, it is recommended that you run a secondary DNS
server offsite. If you have a business relationship with an organization on the Internet, either business
partners or ISPs, they might agree to run a secondary server for you; however, ensure that the data on the
organization’s server is secured against Internet attackers.
To ensure that DNS is available if your offsite primary DNS servers are down, consider deploying a
secondary DNS server offsite.
For more information about how to place DNS servers to maximize Active Directory availability, see
“Designing the Active Directory Logical Structure” in Designing and Deploying Directory and Security
Services of this kit.
Using Forwarding
If a DNS server does not have the data to resolve a query in its cache or in its zone data, it forwards the query
to another DNS server, known as a forwarder. Forwarders are ordinary DNS servers and require no special
configuration; a DNS server is called a forwarder because it is the recipient of a query forwarded by another
DNS server.
Use forwarding for off-site or Internet traffic. For example, a branch office DNS server can forward all off-
site traffic to a forwarder at the company headquarters, and an internal DNS server can forward all Internet
traffic to a forwarder on the external network. To ensure fault tolerance, forward queries to more than one
forwarder.
Forwarders can increase network security by minimizing the list of DNS servers that communicate across a
firewall.
You can use conditional forwarding to more precisely control the name resolution process. Conditional
forwarding enables you to designate specific forwarders for specific DNS names. You can use conditional
forwarding to resolve the following:
• Queries for names in off-site internal domains
• Queries for names in other namespaces
Using Conditional Forwarding to Query for Names in Off-Site

Internal Domains
In Windows Server 2003 DNS, non-root servers resolve names for which they are not authoritative, do not
have a delegation, and do not have in their cache by doing one of the following:
• Querying a root server.
• Forwarding queries to a forwarder.
Both of these methods generate additional network traffic. For example, a non-root server in Site A is
configured to forward queries to a forwarder in Site B, and it must resolve a name in a zone hosted by a
server in Site C. Because the non-root server can forward queries only to Site B, it cannot directly query the
server in Site C. Instead, it forwards the query to the forwarder in Site B, and the forwarder queries the server
in Site C.
When you use conditional forwarding, you can configure your DNS servers to forward queries to different
servers based on the domain name specified in the query. This eliminates steps in the forwarding chain and
reduces network traffic. When conditional forwarding is applied, the server in Site A can forward queries to
forwarders in Site B or Site C, as appropriate.
For example, the computers in the Seville site need to query computers in the Hong Kong site. Both sites use
a common DNS root server, DNS3.corp.fabrikam.com, located in Seville.
Before the Contoso Corporation upgraded to Windows Server 2003, the server in Seville forwarded all
queries that it could not resolve to its parent server, DNS1.corp.contoso.com, in Seattle. When the server in
Seville queried for names in the Hong Kong site, the server in Seville first forwarded those queries to Seattle.
After upgrading to Windows Server 2003, administrators configured the DNS server in Seville to forward
queries destined for the Hong Kong site directly to a server in that site, instead of first detouring to Seattle, as
shown in Figure 3.7.
Figure 3.7 Conditional Forwarding to an Off-Site Server
Administrators configured DNS3.corp.fabrikam.com to forward any queries for corp.treyresearch.com to

DNS5.corp.treyresearch.com or DNS6.corp.treyresearch.com. DNS3.corp.fabrikam.com forwards all other
queries to DNS1.corp.contoso.com or DNS2.corp.contoso.com.
For more information about conditional forwarding in Windows Server 2003 DNS, see the Networking
Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
Using Conditional Forwarding to Query for Names in Other

Namespaces
If your internal network does not have a private root and your users need access to other namespaces, such as
a network belonging to a partner company, use conditional forwarding to enable servers to query for names
in other namespaces. Conditional forwarding in Windows Server 2003 DNS eliminates the need for
secondary zones by configuring DNS servers to forward queries to different servers based on the domain
name.
For example, the Contoso Corporation includes two namespaces: Contoso and Trey Research. Computers in
each division need access to the other namespace. In addition, computers in both divisions need access to
computers in the Supplier private namespace.
Before upgrading to Windows Server 2003, the Trey Research division created secondary zones to ensure
that computers in both the Contoso and Trey Research namespace can resolve names in the Contoso, Trey
Research, and Supplier namespaces. After upgrading to Windows Server 2003, the Trey Research division
deleted its secondary zones and configured conditional forwarding instead.
Upgrading DNS Servers to Windows

Server 2003 DNS
The procedure you need to follow to upgrade DNS servers to Windows Server 2003 depends on whether you
want to support Active Directory or not. If you are upgrading to Windows Server 2003 DNS and might not
support Active Directory, for information about upgrading your existing DNS servers or migrating third-party
DNS servers, see “Migrating servers” in Help and Support Center for Windows Server 2003. Migration
involves the following:
• Plan your migration schedule to ensure that your DNS clients have access to a DNS server at
all times.
• Back up your existing configuration.
• Migrate data from existing DNS servers to Windows Server 2003 DNS.
If you are upgrading your DNS servers to support Active Directory, see “Designing the Active Directory
Logical Structure” in Designing and Deploying Directory and Security Services of this kit.
After you have upgraded or migrated your servers, test them to ensure that they are resolving correctly. For
more information about DNS troubleshooting and testing DNS server performance, see “Monitor servers” in
Help and Support Center for Windows Server 2003, and the Networking Guide of the Windows Server 2003
Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
Designing DNS Zones

Each zone type that is available in Windows Server 2003 DNS has a specific purpose. The DNS designer in
your organization selects the type of zones to deploy based on the practical purpose of each zone. The DNS
administrators in your organization manage and maintain your DNS zones. Figure 3.8 shows the process for
designing DNS zones.
Figure 3.8 Designing DNS Zones
Choosing a Zone Type

Design zones to correspond to your network administration infrastructure. If a site in your network is
administered locally, deploy a zone for the subdomain. If a department has a subdomain, but no
administrator, keep the subdomain in the parent zone. Decide whether or not to store your zones in Active
Directory. Active Directory distributes data using a multimaster replication model that provides more security
than standard DNS. With the exception of secondary zones, you can store all zone types in Active Directory
because all other zones are considered primary zones. When designing DNS zones, host each zone on more
than one DNS server.
Decide which type of zone to use, based on your domain structure. For each zone type, with the exception of
secondary zones, decide whether to deploy file-based zones or Active Directory–integrated zones.
Primary Zones
Deploy primary zones that correspond to your planned DNS domain names. You cannot store both an Active
Directory–integrated and a file-based primary copy of the same zone on the same DNS server.
Secondary Zones
Add secondary zones if you do not have an Active Directory infrastructure. If you do have an Active
Directory infrastructure, use secondary zones on DNS servers that are not serving as domain controllers. A
secondary zone contains a complete copy of a zone. Therefore, use secondary zones to improve zone
availability at remote sites if you do not want zone data propagated across a WAN link by means of Active
Directory replication.
Stub Zones
A stub zone is a copy of a zone that contains only the original zone’s start of authority (SOA) resource
record, the name server (NS) resource records listing the authoritative servers for the zone, and the glue
address (A) resource records that are needed to identify these authoritative servers.
A DNS server that is hosting a stub zone is configured with the IP address of the authoritative server from
which it loads. DNS servers can use stub zones for both iterative and recursive queries. When a DNS server
hosting a stub zone receives a recursive query for a computer name in the zone to which the stub zone refers,
the DNS server uses the IP address to query the authoritative server, or, if the query is iterative, returns a
referral to the DNS servers listed in the stub zone.
Stub zones are updated at regular intervals, determined by the refresh interval of the SOA resource record for
the stub zone. When a DNS server loads a stub zone, it queries the zone’s primary servers for SOA resource
records, NS resource records at the zone’s root, and glue address (A) resource records. The DNS server
attempts to update its resource records at the end of the SOA resource record’s refresh interval. To update its
records, the DNS server queries the primary servers for the resource records listed earlier.
You can use stub zones to ensure that the DNS server that is authoritative for a parent zone automatically
receives updates about the DNS servers that are authoritative for a child zone. To do this, add the stub zone to
the server that is hosting the parent zone. Stub zones can be either file-based or Active Directory–integrated.
If you use Active Directory–integrated stub zones, you can configure them on one computer and let Active
Directory replication propagate them to other DNS servers running on domain controllers.
Although conditional forwarding is the recommended method for making your servers aware of other
namespaces, you can also use stub zones for this. For more information about using stub zones, see Help and
Support Center for Windows Server 2003.
Note
Only DNS servers running Windows Server 2003 and BIND 9 support
stub zones.
Stub Zones and Conditional Forwarding

Stub zones and conditional forwarding are Windows Server 2003 DNS features that enable you to control the
routing of DNS traffic over a network. These features enable a DNS server to respond to a query by doing
one of the following:
• Providing a referral to another DNS server.
• Forwarding the query to another DNS server.
A stub zone enables a DNS server that is hosting a parent zone to be aware of the names and IP addresses of
DNS servers that are authoritative for a child zone, even if the DNS server does not have a complete copy of
the child zone. In addition, when a stub zone is used, the DNS server does not have to send queries to the
DNS root servers. If the stub zone for a child zone is hosted on the same DNS server as the parent zone, the
DNS server that is hosting the stub zone receives a list of all new authoritative DNS servers for the child
zone when it requests an update from the stub zone’s primary server. In this way, the DNS server that is
hosting the parent zone maintains a current list of the authoritative DNS servers for the child zone as the
authoritative DNS servers are added and removed.
Use conditional forwarding if you want DNS servers in one network to perform name resolution for DNS
clients in another network. You can configure DNS servers in separate networks to forward queries to each
other without querying DNS servers on the Internet. If DNS servers in separate networks forward DNS client
names to each other, the DNS servers cache this information. This enables you to create a direct point of
contact between DNS servers in each network and reduces the need for recursion.
If you are using a stub zone and you have a firewall between DNS servers in the networks, then DNS servers
on the query/resolution path must have port 53 open. However, if you are using conditional forwarding and
you have a firewall between DNS servers in each of the networks, the requirement to have port 53 open only
applies to the two DNS servers on either side of the firewall.
Active Directory–Integrated Zones

If your DNS topology includes Active Directory, use Active Directory–integrated zones. Active Directory–
integrated zones enable you to store zone data in the Active Directory database. Zone information on any
primary DNS server within an Active Directory–integrated zone is always replicated.
Because DNS replication is single-master, a primary DNS server in a standard primary DNS zone can be a
single point of failure. In an Active Directory–integrated zone, a primary DNS server cannot be a single point
of failure because Active Directory uses multimaster replication. Updates that are made to any domain
controller are replicated to all domain controllers and the zone information on any primary DNS server
within an Active Directory–integrated zone is always replicated. Active Directory–integrated zones:
• Enable you to secure zones by using secure dynamic update.
• Provide increased fault tolerance. Every Active Directory–integrated zone can be replicated
to all domain controllers within the Active Directory domain or forest. All DNS servers
running on these domain controllers can act as primary servers for the zone and accept
dynamic updates.
• Enable replication that propagates changed data only, compresses replicated data, and
reduces network traffic.
If you have an Active Directory infrastructure, you can only use Active Directory–integrated zones on Active
Directory domain controllers. If you are using Active Directory–integrated zones, you must decide whether
or not to store Active Directory–integrated zones in the application directory partition.
You can combine Active Directory–integrated zones and file-based zones in the same design. For example, if
the DNS server that is authoritative for the private root zone is running on an operating system other than
Windows Server 2003 or Windows 2000, it cannot act as an Active Directory domain controller. Therefore,
you must use file-based zones on that server. However, you can delegate this zone to any domain controller
running either Windows Server 2003 or Windows 2000.
Storing Active Directory–Integrated Zones in Application Directory

Partitions
Windows Server 2003 Active Directory enables you to configure an application directory partition that limits
the scope of replication. Data stored in an application directory partition is replicated to a subset of domain
controllers. This subset is determined by the replication scope of the data. In the default configuration of
Windows Server 2003 Active Directory, DNS application directory partitions are present only on the domain
controllers that run the DNS Server service. By storing Active Directory–integrated zones in an application
directory partition, you can reduce the number of objects that are stored in the global catalog, and you can
reduce the amount of replication traffic within a domain.
In contrast, Active Directory–integrated zones that are stored in domain directory partitions are replicated to
all domain controllers in the domain. Storing Active Directory–integrated zones in an application directory
partition allows replication of DNS data to domain controllers anywhere in the same Active Directory forest.
When you are setting up your Active Directory environment and installing the first Windows Server 2003
domain controller in the forest, if you install DNS, two Windows Server 2003 DNS application directory
partitions are created by default. A forest-wide DNS application directory partition called ForestDNSZones
will be created, and for each domain in the forest, a domain-wide DNS application directory partition called
DomainDNS Zones will be created.
Choosing a Propagation Method

After you decide which zone each DNS server hosts, decide how to propagate the zones among the servers.
Propagated zones provide higher availability, improve query response time, and reduce network traffic
produced by name queries. However, propagated zones require storage space and increase network traffic. If
your network is distributed and managed at different sites, use subdomains for these sites. If you do not have
a distributed network, avoid using subdomains when possible.
In Windows Server 2003, zones are propagated by means of file-based zone transfer or Active Directory
replication. If you use file-based zones, file-based zone transfer is the method of propagation. If you have
Windows Server 2003 and Windows 2000 Active Directory–integrated zones, use Active Directory
replication.
File-Based Zone Transfer

Windows Server 2003 and Windows 2000 DNS support both incremental and full zone transfer of file-based
zones. Incremental zone transfer is the default method, but if this method is not supported by a third-party
DNS server that is involved in the transfer, DNS servers running Windows Server 2003 and Windows 2000
transfer the full zone.
Incremental zone transfer, described in RFC 1995:Incremental Zone Transfer in DNS, provides better use of
available network bandwidth. Rather than sending the entire contents of the zone file, the primary server only
transfers the incremental changes in the zone. This reduces the impact of DNS zone transfers on network
traffic. Without incremental zone transfers, the primary server transfers the entire zone file to the secondary
server every time a DNS zone is updated.
Windows Server 2003 DNS uses full zone transfer when zones must be transferred to DNS servers that do
not support incremental zone transfer, such as DNS servers running on Windows NT 4.0 or earlier versions
of BIND 8.
Active Directory Replication

Active Directory replication propagates zone changes between domain controllers. Replication processing
differs from DNS full zone transfers, in which the DNS server transfers the entire zone. Replication
processing also differs from incremental zone transfers, in which the server transfers all changes made since
the last change.
Active Directory zone replication provides the following additional benefits:

• Network traffic is reduced because the domain controllers only send the final result of all
changes.
• When a zone is stored in Active Directory, replication occurs automatically. No additional
configuration is required.
• When Active Directory zone replication occurs between sites, zone data that is greater than
the default transfer size is automatically compressed before it is transferred. This
compression decreases the network traffic load.
After careful analysis, you can partition and delegate your DNS zones based on what is required for
providing efficient and fault-tolerant name service to each location or site.
If you are using Active Directory–integrated zones in a Windows Server 2003 domain, you must select an
Active Directory–integrated zone replication scope. When selecting a replication scope, note that network
traffic increases as you broaden the replication scope. For example, if you choose to replicate Active
Directory–integrated DNS zone data to all DNS servers in the forest, this produces greater network traffic
than replicating the DNS zone data to all DNS servers in a single Active Directory domain in that forest.
Balance your need to minimize replication traffic against your need to minimize zone query traffic. The DNS
administrators in your organization are responsible for managing zone replication.
Table 3.8 lists the replication options for Active Directory–integrated zone data.
Table 3.8 Replication Options for Active Directory–Integrated Zone Data
Option Description When to Use
All DNS The zone data replicates to You want the broadest scope of
servers in the all the DNS servers running replication. This option generally
Active on Windows Server 2003– produces the most zone
Directory based domain controllers in replication traffic. Note that you
forest all domains of the Active can choose this option only if all
Directory forest. DNS servers hosting an Active
Directory–integrated copy of this
zone run Windows Server 2003.
All DNS The zone data replicates to You do not need the zone to be
servers in a all DNS servers running on replicated throughout the forest
specified Windows Server 2003– and you want to limit zone
Active based domain controllers in replication traffic. This option
Directory the specified Active produces less zone replication
domain Directory domain. This traffic than replicating the zone
option is the default setting to all DNS servers in the forest
for Active Directory– or to all domain controllers in
integrated DNS zone the domain. If you choose this
replication. option, the zone data does not
(The specified Active replicate to DNS servers running
Directory domain is the on Windows 2000–based domain
domain hosted by the controllers.
domain controller on which
the DNS server hosting the
zone is running.)
(continued)
Table 3.8 Replication Options for Active Directory–Integrated Zone Data (continued)
Option Description When to Use
All domain The zone data replicates to You host an Active Directory–
controllers in all domain controllers in the integrated copy of this zone on a
the Active specified Active Directory DNS server running on a
Directory domain, whether or not the Windows 2000–based domain
domain DNS Server service runs on controller.
the domain controllers in the
domain.
All domain The zone data replicates to You want to customize zone
controllers all the domain controllers replication scope for your
specified in specified in the replication organization. With this option,
the scope of the DNS application you can minimize zone
replication directory partition. replication traffic while
scope of a maximizing functionality.
DNS However, this option requires
application more administrative overhead.
directory You can choose this option only
partition if all DNS servers hosting an
Active Directory–integrated copy
of this zone run Windows
Server 2003.
Migrating Zones to Windows

Server 2003 DNS Servers
You can migrate zones to DNS servers running Windows Server 2003 in one of two ways:
• By using zone transfer.
• By copying the zone files.
If you copy the zone files, you must manually verify the integrity of the zones. Regardless of the method that
you use to migrate zones, you must decide whether to take the original DNS server offline, or to use it as a
secondary server. If you determine that the original third-party DNS server causes interoperability problems
on your network, or if you need to use that server hardware for another purpose, take the server offline.
Otherwise, keep the server on you network to provide backup for your primary DNS server running
Windows Server 2003.
For more information about using zone transfer, see “Initiate a zone transfer at a secondary server” in Help
and Support Center for Windows Server 2003.
Configuring and Managing

DNS Clients
When you configure DNS clients, you must specify a list of DNS servers for clients to use when resolving
DNS names. You can also specify a DNS suffix search list to be used by the clients when performing DNS
query searches for short, unqualified domain names.
Figure 3.9 shows the process for configuring and managing DNS clients.
Figure 3.9 Configuring and Managing DNS Clients
Configuring Client DNS Server Lists and

Suffix Search Lists
Configure your clients’ DNS server lists and suffix search list by including at least two DNS server IP
addresses on the clients and domain controllers: the IP address for a preferred server and the IP address for an
alternate server. Use a server running in the local site for the preferred server. The alternate server can be
running in either a local or a remote site.
The DNS suffix search list is populated based on the primary DNS suffix of the client and any connection-
specific DNS suffixes. The client uses these suffixes to try to resolve unqualified names. You can modify the
DNS suffix search list manually, or by using Group Policy. Limit the size of your suffix search list if you can,
because a large suffix search list increases network traffic.
Using Group Policy to Simplify Client

Configuration
Windows Server 2003 includes a new set of Group Policy settings to simplify the rollout of Windows
Server 2003 DNS clients. You can use them to set your suffix search lists, dynamic update configuration, and
many other settings. As with all Group Policy settings, you can specify different settings based on site,
domain, or OU.
For more information about these Group Policy settings, see the Networking Guide of the Windows
Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
Securing Your DNS Infrastructure

Because DNS was designed to be an open protocol, DNS data can be vulnerable to security attacks. Windows
Server 2003 DNS provides improved security features to decrease this vulnerability. The DNS designer in
your organization is responsible for creating a secure DNS infrastructure. The DNS administrators in your
organization are responsible for maintaining network security by anticipating and mitigating new security
threats.
Figure 3.10 shows the process for securing your DNS infrastructure.
Figure 3.10 Securing Your DNS Infrastructure
Identifying DNS Security Threats

A DNS infrastructure is vulnerable to a number of types of security threats.
Footprinting
The process of building a diagram, or footprint, of a DNS infrastructure by capturing
DNS zone data such as domain names, computer names, and IP addresses for sensitive network resources.
DNS domain and computer names often indicate the function or location of domains and computers.
Denial-of-service attackAn attack in which the attacker attempts to deny the availability of
network services by flooding one or more DNS servers in the network with recursive queries. When a DNS
server is flooded with queries, its CPU usage eventually reaches its maximum and the DNS Server service
becomes unavailable. Without a fully operating DNS server on the network, network services that use DNS
are unavailable to network users.
Data modificationThe use of valid IP addresses in IP packets that an attacker has created to destroy
data or conduct other attacks. Data modification is typically attempted on a DNS infrastructure that has
already been foot printed. If the attack is successful, the packets appear to be coming from a valid IP address
on the network. This is commonly called IP spoofing. With a valid IP address (an IP address within the IP
address range of a subnet), an attacker can gain access to the network.
Redirection
An attack in which an attacker is able to redirect queries for DNS names to servers that
are under the control of the attacker. One method of redirection involves the attempt to pollute the DNS
cache of a DNS server with erroneous DNS data that might direct future queries to servers that are under the
control of an attacker. For example, if a query is made to example.contoso.com and a referral answer
provides a record for a name that is outside of the contoso.com domain, the DNS server uses the cached data
to resolve a query for the external name. Redirection can be accomplished when an attacker has writable
access to DNS data, such as with non-secure dynamic updates.
For more information about common types of attacks, developing a security policy, and evaluating your level
of risk, see “Designing an Authentication Strategy” and “Designing a Resource Authorization Strategy” in
Designing and Deploying Directory and Security Services of this kit.
Developing a DNS Security Policy

If your DNS data is compromised, attackers can gain information about your network that can be used to
compromise other services. For example, attackers can harm your organization in the following ways:
• By using zone transfer, attackers can retrieve a list of all the hosts and their IP addresses in
your network.
• By using denial-of-service attacks, attackers can prevent e-mail from being delivered to and
from your network, and they can prevent your Web server from being visible.
• If attackers can change your zone data, they can set up fake Web servers, or cause e-mail to
be redirected to their servers.
Your risk of attack varies depending on your exposure to the Internet. For a DNS server in a private network
that uses a private namespace, a private addressing scheme, and an effective firewall, the risk of attack is
lower and the possibility of discovering the intruder is greater. For a DNS server that is exposed to the
Internet, the risk is higher.
Developing a DNS security policy involves:
• Deciding what access your clients need, what tradeoffs you want to make between security
and performance, and what data you most want to protect.
• Familiarizing yourself with the security issues common to internal and external DNS
servers.
• Studying your name resolution traffic to see which clients can query which servers.
You can choose to adopt a low-level, mid-level, or high-level DNS security policy.
Low-Level DNS Security Policy

Low-level security does not require any additional configuration of your DNS deployment. Use this level of
DNS security in a network environment in which you are not concerned about the integrity of your DNS
data, or in a private network in which no external connectivity is possible. A low-level security policy
includes the following characteristics:
• All DNS servers in your network perform standard DNS resolution.
• All DNS servers are configured with root hints that point to the root servers for the Internet.
• All DNS servers permit zone transfers to any server.
• All DNS servers are configured to listen on all of their IP addresses.
• Secure cache against pollution is disabled on all DNS servers.
• Dynamic update is allowed for all DNS zones.
• User Datagram Protocol (UDP) and TCP/IP port 53 is open on the firewall for your network
for both source and destination addresses.
Mid-Level DNS Security Policy

Mid-level DNS security consists of the DNS security features that are available without running DNS servers
on domain controllers and storing DNS zones in Active Directory. A mid-level security policy includes the
following characteristics:
• The DNS infrastructure of your organization has limited exposure to the Internet.
• All DNS servers are configured to use forwarders to point to a specific list of internal DNS
servers when they cannot resolve names locally.
• All DNS servers limit zone transfers to servers listed in the NS records in their zones.
• DNS servers are configured to listen on specified IP addresses.
• Secure cache against pollution is enabled on all DNS servers.
• Secure dynamic update is allowed for all DNS zones.
• Internal DNS servers communicate with external DNS servers through the firewall with a
limited list of allowed source and destination addresses.
• External DNS servers in front of your firewall are configured with root hints pointing to the
root servers for the Internet.
• All Internet name resolution is performed by using proxy servers and gateways.
High-Level DNS Security Policy

High-level DNS security uses the same configuration as mid-level security and also uses the security features
available when the DNS Server service is running on a domain controller and DNS zones are stored in Active
Directory. Also, high-level security completely eliminates DNS communication with the Internet. This is not
a typical configuration, but it is recommended whenever Internet connectivity is not required. High-level
security policy includes the following characteristics:
• The DNS infrastructure of your organization has no Internet communication by means of
internal DNS servers.
• Your network uses an internal DNS root and namespace, where all authority for DNS zones
is internal.
• DNS servers that are configured with forwarders use internal DNS server IP addresses only.
• All DNS servers limit zone transfers to specified IP addresses.
• DNS servers are configured to listen on specified IP addresses.
• Secure cache against pollution is enabled on all DNS servers.
• Internal DNS servers are configured with root hints that point to the internal DNS servers
hosting the root zone for your internal namespace.
• Secure dynamic update is configured for all DNS zones except for the top-level and root
zones, which do not allow dynamic updates at all.
• All DNS servers are running on domain controllers. An access control list (ACL) is
configured on the DNS Server service to allow only specific individuals to perform
administrative tasks on DNS servers.
• All DNS zones are stored in Active Directory. An ACL is configured to allow only specific
individuals to create, delete, or modify DNS zones.
• ACLs are configured on DNS resource records to allow only specific individuals to create,
delete, or modify DNS data.
Note
Windows Server 2003 DNS does not support the use of DACLs on
zones to control which clients or users can send queries to the DNS
server.
Cache Pollution Protection

When cache pollution protection is enabled, the DNS server disregards DNS resource records that originate
from DNS servers that are not authoritative for the resource records. Cache pollution protection is a
significant security enhancement; however, when cache pollution protection is enabled, the number of DNS
queries can increase.
In Windows Server 2003 DNS, cache pollution protection is enabled by default. You can disable cache
pollution protection to reduce the number of DNS queries; however, to ensure the security of your system, it
is strongly recommended that you leave cache pollution protection enabled on your DNS servers.
For information about cache pollution protection, see the Networking Guide of the Windows Server 2003
Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
Securing DNS Servers That Are Exposed to

the Internet
DNS servers that are exposed to the Internet are especially vulnerable to attack. You can secure your DNS
servers that are exposed to the Internet by doing the following:
• Place the DNS server on a perimeter network instead of your internal network.
For more information about perimeter networks, see “Deploying ISA Server” in this book.
Use one DNS server for publicly accessed services inside your perimeter network and a
separate DNS server for your private internal network. This reduces the risk of exposing
your private namespace, which can expose sensitive names and IP addresses to Internet-
based users. It also increases performance because it decreases the number of resource
records on the DNS server.
• Add a secondary server on another subnet or network, or on an ISP. This protects you against
denial-of-service attacks.
• Eliminate single points of failure by securing your routers and DNS servers, and distributing
your DNS servers geographically. Add secondary copies of your zones to at least one offsite
DNS server.
• Encrypt zone replication traffic by using Internet Protocol security (IPSec) or virtual private
network (VPN) tunnels to hide the names and IP addresses from Internet-based users.
• Configure firewalls to enforce packet filtering for UDP and TCP port 53.
• Restrict the list of DNS servers that are allowed to initiate a zone transfer on the DNS server.
Do this for each zone in your network.
• Monitor the DNS logs and monitor your external DNS servers by using Event Viewer.
Securing Internal DNS Servers

Internal DNS servers are less vulnerable to attack than external DNS servers, but you still need to protect
them. To secure your internal DNS servers:
• Eliminate any single point of failure. Note, however, that DNS redundancy cannot help you
if your clients cannot access any network services. Think about where the clients of each
DNS zone are located, and how they resolve names if the DNS server is compromised and
unable to answer queries.
• Prevent unauthorized access to your servers. Allow only secure dynamic update for your
zones and limit the list of DNS servers that are allowed to obtain a zone transfer.
• Monitor the DNS logs and monitor your internal DNS servers by using Event Viewer.
Monitoring your logs and your server can help you detect unauthorized modifications to
your DNS server or zone files.
• Implement Active Directory–integrated zones with secure dynamic update.
Securing Dynamically Updated DNS Zones

Use Active Directory–integrated zones and configure them for secure dynamic update. Secure dynamic
update resolves the security risks associated with using dynamic update. Because dynamic update allows any
computer to modify any record, an attacker can modify zone data, then impersonate existing servers.
For example, if you install the Web server, web.contoso.com, and it registers its IP address in DNS by using
dynamic update, an attacker can install a second Web server, also name it web.contoso.com, and use dynamic
update to modify the corresponding IP address in the DNS record. In this way, the attacker can impersonate
the original Web server and capture secure information.
To prevent server impersonation, implement secure dynamic update. By using secure dynamic update, only
the computers and users specified in an access control list (ACL) can modify objects within a zone.
If your security policy demands stricter security, modify these settings to further restrict access. Restrict
access by computer, group, or user account, and assign permissions for the entire DNS zone and for the
individual DNS names within the zone.
For more information about securing dynamically updated DNS zones, see the Networking Guide of the
Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
Securing DNS Zone Replication

Zone replication can occur either by means of zone transfer or as part of Active Directory replication. If you
do not secure zone replication, you run the risk of exposing the names and IP addresses of your computers to
attackers. You can secure DNS zone replication by doing the following:
• Using Active Directory replication.
• Encrypting zone replication sent over public networks such as the Internet.
• Restricting zone transfer to authorized servers.
Using Active Directory Replication

Replicating zones as part of Active Directory replication provides the following security benefits:
• Active Directory replication traffic is encrypted; therefore zone replication traffic is
encrypted automatically.
• The Active Directory domain controllers that perform replication are mutually authenticated,
and impersonation is not possible.
Note
Use Active Directory–integrated zones whenever possible, because
they are replicated as part of Active Directory replication, which is more
secure than file-based zone transfer.
Encrypting Replication Traffic Sent Over Public Networks

Encrypt all replication traffic sent over public networks by using IPSec or VPN tunnels. When encrypting
replication traffic sent over public networks:
• Use the strongest level of encryption or VPN tunnel authentication that your servers can
support.
• Use the Windows Server 2003 Routing and Remote Access service to create the IPSec or
VPN tunnel.
Restricting Zone Transfer to Authorized Servers

If you have secondary servers and you replicate your zone data by using zone transfer, configure your DNS
servers to specify the secondary servers that are authorized to receive zone transfers. This prevents an
attacker from using zone transfer to download zone data. If you are using Active Directory–integrated zones
instead, configure your servers to disallow zone transfer.
Integrating DNS with Other

Windows Server 2003 Services
When you deploy Windows Server 2003 DNS, it is important to integrate the DNS service with other
Windows Server 2003 services, such as DHCP and WINS. DNS administrators are responsible for
integrating DNS with WINS and DHCP. Figure 3.11 shows the process for integrating Windows
Server 2003 DNS with other Windows Server 2003 services.
Figure 3.11 Integrating DNS with Other Windows Server 2003 Services
Integrating DNS with DHCP

Windows Server 2003 DNS supports DHCP by means of the dynamic update of DNS zones. By integrating
DHCP and DNS in a DNS deployment, you can provide your network resources with dynamic addressing
information stored in DNS. To enable this integration, you can use the Windows Server 2003 DHCP service.
The dynamic update standard, specified in RFC 2136: Dynamic Updates in the Domain Name System (DNS
UPDATE), automatically updates DNS records. Both Windows Server 2003 and Windows 2000 support
dynamic update, and both clients and DHCP servers can send dynamic updates when their IP addresses
change.
Dynamic update enables a DHCP server to register address (A) and pointer (PTR) resource records on behalf
of a DHCP client by using DHCP Client FQDN option 81. Option 81 enables the DHCP client to provide its
FQDN to the DHCP server. The DHCP client also provides instructions to the DHCP server describing how
to process DNS dynamic updates on behalf of the DHCP client.
The DHCP server can dynamically update DNS A and PTR records on behalf of DHCP clients that are not
capable of sending option 81 to the DHCP server. You can also configure the DHCP server to discard client A
and PTR records when the DHCP client lease is deleted. This reduces the time needed to manage these
records manually and provides support for DHCP clients that cannot perform dynamic updates. In addition,
dynamic update simplifies the setup of Active Directory by enabling domain controllers to dynamically
register SRV resource records.
If the DHCP server is configured to perform DNS dynamic updates, it performs one of the following actions:
• The DHCP server updates resource records at the request of the client. The client requests
the DHCP server to update the DNS PTR record on behalf of the client, and the client
registers A.
• The DHCP server updates DNS A and PTR records regardless of whether the client requests
this action or not.
By itself, dynamic update is not secure because any client can modify DNS records. To secure dynamic
updates, you can use the secure dynamic update feature provided in Windows Server 2003. To delete
outdated records, you can use the DNS server aging and scavenging feature.
Integrating DNS with WINS

When you upgrade to Windows Server 2003 DNS from an earlier version of Windows, you might need to
continue support an existing WINS infrastructure. Windows Server 2003 DNS enables you to support an
existing WINS deployment by allowing you to configure a DNS server to query a WINS server as a DNS
zone setting.
WINS provides dynamic NetBIOS name resolution. If your organization supports clients and applications
that use WINS for NetBIOS name resolution, you need to continue to support WINS. If some of your clients
are registered in WINS and other clients need to resolve their names but are not capable of NetBIOS name
resolution, you can use WINS lookup to enable your DNS server to look up names in the WINS namespace.
This feature is particularly useful if some of your clients that require NetBIOS name resolution cannot use
WINS or if some of your clients cannot register with DNS (for example, clients that run the Microsoft®
Windows® 95 or Windows® 98 operating system). Use WINS referral if some of your DNS servers do not
support the resource records used for WINS lookup and WINS reverse lookup.
WINS Lookup and WINS Reverse Lookup

By configuring your DNS server for WINS lookup, you can direct DNS to query WINS for name resolution,
so that DNS clients can look up the names and IP addresses of WINS clients. To direct DNS to query WINS
for name resolution, add a WINS lookup record to the authoritative zone. An authoritative DNS server
checks that zone when it receives a query for a name. If the DNS server does not find the name in the
authoritative zone, but the zone contains a WINS lookup record, the DNS server queries the WINS server. If
the name is registered with WINS, the WINS server returns the associated record to the DNS server.
The DNS server then compiles and returns the corresponding DNS record in response to the original DNS
request. DNS clients do not need to know whether a client is registered with WINS or DNS, and they do not
need to query the WINS server.
You can also configure your DNS server for WINS reverse lookups. Reverse lookups work slightly
differently. When an authoritative DNS server is queried for a nonexistent PTR record, and the authoritative
zone contains the WINS-R record, the DNS server uses a NetBIOS node adapter status lookup.
Note
For fault tolerance, you can specify multiple WINS servers in the WINS
lookup record. The server that is running the Windows 2000 or
Windows Server 2003 DNS Server service tries to locate the name by
searching the WINS servers in the order specified by the list.
Configuring WINS Referral

Computers that are running third-party implementations of DNS do not support the records used for WINS
lookup and WINS reverse lookup. If you attempt to use a combination of Microsoft and third-party DNS
servers to host a zone containing these records, the mixture can cause data errors or failed zone transfers at
the third-party DNS servers.
If you have such a combination, you can use WINS referral to create and delegate a special WINS zone that
refers DNS lookups to WINS. This zone does not perform any registrations or updates. Next, you configure
all DNS clients to append the WINS referral zone name to unqualified queries. That way, the client can query
both DNS and WINS at the same time, using a DNS query. To simplify administration, you can use DHCP or
Group Policy to configure the clients to perform the configuration. Deploying this configuration overrides
the default DNS client resolver behavior, requiring you to finish populating the suffix search order with
combinations of suffixes, such as the primary DNS suffix, the primary DNS suffix devolved, and connection
specific suffixes.
For more information about DHCP, see “Deploying DHCP” in this book. For more information about Group
Policy, see “Designing a Group Policy Infrastructure” in Designing a Managed Environment of this kit.
Note
The WINS zone must be hosted on a DNS server that is running
Windows Server 2003 or Windows 2000 and must not be propagated
to third-party DNS servers. Third-party DNS servers do not support
WINS resource records and might not be able to host the zone.
Implementing Windows
Server 2003 DNS
After you have tested your configuration in a pilot lab, you can implement your changes in your production
environment. Figure 3.12 shows the process for implementing Windows Server 2003 DNS.
Figure 3.12 Implementing Windows Server 2003 DNS
Preparing to Deploy Windows Server 2003

DNS
Prepare your environment for Windows Server 2003 DNS deployment by ensuring that you have reliable
backups of anything that you plan to change, including servers and zones. Test your backups before you
proceed with your deployment. In addition, create a recovery plan for contingencies such as data loss, server
failure, and failure of network connections.
Before implementing your DNS deployment, ensure that routing links between the servers that you plan to
deploy are in place and are working correctly. Depending on how your DNS infrastructure is configured,
your DNS servers might need to query the following:
• Root servers.
• Forwarders.
• Servers hosting parent zones.
• Servers hosting child zones.
• Servers on an external network or the Internet.
If you expect clients to query for names on the Internet and you plan to use a proxy server, ensure that the
proxy server is in place and that a proxy-client/firewall-client is installed on the client. In addition, ensure
that the Web client configuration is set in a Conseil Européen pour la Recherche Nucléaire (CERN)–
compliant Internet browser. Microsoft Internet Explorer is an example of a CERN–compliant Internet
browser.
Setting up the DNS Server

Before you install DNS, ensure that your computer is named correctly and that you can ping other computers
in the network that your DNS servers might need to query. Because clients locate DNS servers by IP address,
assign a static IP address to each DNS server.
You can set up your DNS server in one of four ways:
• Install DNS on a server by using the Active Directory Installation Wizard to install Active
Directory.
The Active Directory Installation Wizard automatically creates an Active Directory–
integrated copy of the forward lookup zone that corresponds to the name of the Active
Directory domain, and configures the zone for secure dynamic update. In addition, the
wizard creates the standard reverse lookup zones recommended by the DNS RFCs.
You can start the Active Directory Installation Wizard by running dcpromo.exe at a
command prompt. For more information about Active Directory installation and removal,
see the Directory Services Guide of the Windows Server 2003 Resource Kit (or see the
Directory Services Guideon the Web at http://www.microsoft.com/reskit).
• Before or after you install Active Directory on the server, you can use the Add or Remove
Programs tool to install the DNS Server service and then run the Configure DNS Server
Wizard to configure your zones. As with the Active Directory Installation Wizard, the
Configure DNS Server Wizard creates the standard reverse lookup zones recommended by
the DNS RFCs, and either configures the server as a root server or initializes the root hints.
• You can use the command-line tool Dnscmd.exe to configure the DNS server.
• You can use Microsoft® Visual Basic® Scripting Edition (VBScript) or other scripting
languages through the Windows Management Instrumentation (WMI) provider packaged
with Windows Server 2003.
For more information about these setup options and for information about Windows Server 2003 DNS,
including how the Active Directory Installation Wizard and the Configure DNS Server Wizard determine
whether or not to initialize the root hints, see the Networking Guide of the Windows Server 2003 Resource
Kit (or see the Networking Guide on the Web at www.microsoft.com/reskit).
Setting up Zones
If you install DNS by using the Active Directory Installation Wizard, the wizard creates DNS zones that
correspond to the Active Directory domains that you specify. If the zones that you specified during the zone
planning phase of your deployment do not already exist, create them now. Note that the default DNS
installation by the Active Directory Installation Wizard includes secure dynamic update and an Active
Directory–integrated zone. If this is not the configuration you want to deploy, change the default settings.
If the zone that the wizard creates is not the type of zone that you want, change it now.
Note
Converting any zone to an Active Directory–integrated zone can
increase the use of DNS server resources and network resources. This
is because converting a zone can trigger Active Directory replication.
If you want to push updates to secondary DNS servers for a zone, configure DNS notify at the primary DNS
server.
For more information about how to add and remove zones, see Help and Support Center for Windows
Server 2003.
Configuring Forwarding
If any of your servers need to forward queries to any other server, configure forwarding on the servers that
must forward queries. If you want your server to forward queries to different servers depending on the DNS
suffix specified in the query, configure conditional forwarding appropriately.
For more information about conditional forwarding, see “Using Forwarding” earlier in this chapter, and see
the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
Configuring the DNS Server for Dynamic Update

Depending on how you deploy your server and zones, your zones might already be configured for dynamic
update or secure dynamic update. If the zones are not configured as you intend, make any necessary changes.
You can configure your zones to perform dynamic updates, secure dynamic updates, or no updates. However,
configuring your zones to perform unsecured dynamic updates is a security risk and is not recommended.
For information about how to configure dynamic updates, see “Dynamic update” in Help and Support Center
for Windows Server 2003. For information about how to allow only secure dynamic updates, see “Allow
only secure dynamic updates” in Help and Support Center for Windows Server 2003.
Configuring Aging and Scavenging

With dynamic update, whenever a computer joins the network and registers with DHCP, the DNS server
automatically adds resource records to the zone. However, in some cases, the DNS server does not
automatically delete them, and they can become outdated. Outdated resource records use disk space on the
server, and a server might use an outdated resource record to answer a query. As a result, DNS server
performance suffers. To solve these problems, the Windows Server 2003 DNS Server service can scavenge
outdated records by searching the database for records that are obsolete and deleting them.
You can configure aging and scavenging from DNS Manager or by using Dnscmd.exe.
For more information about configuring aging and scavenging in Windows Server 2003 DNS, see the
Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
Configuring Zone Transfer and Replication Scope

If you use file-based primary or secondary zones, configure each primary server for a zone to allow zone
transfers to each secondary server for a zone. Next, configure each secondary server for a zone with a list of
primary servers for that zone.
If you use Active Directory replication in a Windows Server 2003 domain, configure the zone replication
scope as described in Table 3.8.
If the DNS server is a domain controller, you can change the zone type to Active Directory–integrated.
However, if the DNS server is not a domain controller, this option is not available. Active Directory–
integrated zone data is stored and replicated as part of the Active Directory database.
For more information about DNS zone storage and replication in Active Directory, enlisting a DNS server in
a DNS application directory partition, removing a DNS server from a DNS application directory partition, or
changing zone replication scope, click the Index button in Help and Support for Windows Server 2003, and
then in the keyword box, type DNS zones.
Verifying that the DNS Server is Operating Correctly

After you install and configure the DNS server, verify that it is operating correctly. Use the monitoring
features of the DNS MMC snap-in, such as simple or recursive query testing. You can also examine the event
log or use the DNSLint Windows Server 2003 command-line support tool to test DNS servers for problems
with delegations and missing Active Directory replication records. In addition, you can use the Nslookup.exe
command-line tool to attempt queries. To access the monitoring features of the DNS MMC snap-in, click
Properties on the Action menu, and then click the Monitoring tab.
For more information about DNS troubleshooting and verifying DNS server operation, see the Networking
Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
Setting Up DNS Clients

Set up each DNS client with the following:
• Host name and DNS suffix.
• Preferred and alternate DNS servers.
• Optionally, Proxy Auto-Configuration file or name exclusion list (if a proxy client).
You can use any of the following methods to set up your DNS clients:
• Use the TCP/IP settings of the client.
• Use Group Policy to configure groups of clients.
• Use the DHCP Server service to configure some client settings automatically.
For more information about how to install and configure DNS clients, see “Configuring DNS client settings”
in Help and Support Center for Windows Server 2003.
Using Command-Line Tools to Deploy DNS

You can use the command-line tool Dnscmd.exe to perform most of the tasks that you can perform from the
DNS MMC snap-in. By using Dnscmd.exe, you can create, delete, and view zones and records and reset
server and zone properties. You can also perform routine administration operations, such as creating or
updating a zone, reloading the zone, refreshing the zone, writing the zone back to a file or Active Directory,
pausing and resuming the zone, clearing the cache, adding records to root hints, stopping and starting the
DNS service, and viewing statistics.
You can also use Dnscmd.exe to write batch file scripts and for remote administration. For more information
about Dnscmd.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click
Windows Support Tools. For information about installing and using the Windows Server 2003 Support Tools
and Support Tools Help, see the Sreadme.doc file in the \Support\Tools folder on the Windows Server 2003
operating system CD.
You can use the Nslookup.exe command-line tool to perform query testing of the DNS domain namespace
and to display configuration information.
Additional Resources
These resources contain additional information and tools related to this chapter.
Related Information
• “Designing a Resource Authorization Strategy” in Designing and Deploying Directory and
Security Services of this kit for information about establishing security policies.
• “Designing the Active Directory Logical Structure” in Designing and Deploying Directory
and Security Services of this kit for information about how to deploy DNS specifically for
Active Directory.
• “Deploying Security Policy” in Designing a Managed Environment of this kit for more
information about security policies.
• “Designing an Authentication Strategy” in Designing and Deploying Directory and Security
Services of this kit.
• “Deploying ISA Server” in this book for more information about perimeter networks.
• “Deploying DHCP” in this book.
• “Designing a Group Policy Infrastructure” in Designing a Managed Environment of this kit.
• The Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking
Guide on the Web at http://www.microsoft.com/reskit) for more information about the DNS
Server service and DNS troubleshooting .
• The Directory Services Guide of the Windows Server 2003 Resource Kit (or see the
Directory Services Guide on the Web at http://www.microsoft.com/reskit) for more
information, about Active Directory installation and removal.
• RFC 1035: Domain Names — Implementation and Specification.
• DNS and BIND, 4th ed., by Paul Albitz and Cricket Liu, 2001, Sebastopol, CA: O’Reilly &
Associates for more information about DNS.
• Windows 2000 TCP/IP Protocols and Services, by Thomas Lee and Joseph Davies, 2000,
Redmond, Washington: Microsoft Press for more information about the DNS wire protocol.
• The Internet Engineering Task Force (IETF) link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources for more information about
Request for Comments (RFC) documents and IETF Internet-Drafts.
Related Tools
For information about installing and using the Windows Server 2003 Support Tools and Support Tools Help,
see the file Sreadme.doc in the \Support\Tools folder of the Windows Server 2003 operating system CD.
• Dnscmd.exe
You can use the Dnscmd.exe command-line tool to perform most of the tasks that you can
perform from the DNS MMC snap-in.
• DNSLint
DNSLint is a command-line tool that you can use to address some common DNS name
resolution issues, such as lame delegation, DNS record verification, and verifying DNS
records that are used for Active Directory replication.
• Netdiag.exe
Netdiag.exe helps you to isolate networking and connectivity problems by performing a
series of tests to determine the state of your network client and whether it is functional.
• Nslookup.exe
You can use the Nslookup.exe command-line tool to submit DNS queries and display the
results of the queries.
Related Help Topics
For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click
Set search options. Under Help Topics, select the Search in title only checkbox.
• “Migrating servers” in Help and Support Center for Windows Server 2003 for information
about upgrading your existing DNS servers or migrating third-party DNS servers.
• “Monitor servers” in Help and Support Center for Windows Server 2003 for more
information about testing DNS server performance.
• “Initiate a zone transfer at a secondary server” in Help and Support Center for Windows
Server 2003 for more information about using zone transfer.
• “Dynamic update” in Help and Support Center for Windows Server 2003 for information
about how to configure dynamic updates.
• “Allow only secure dynamic updates” in Help and Support Center for Windows Server 2003
for information about how to allow only secure dynamic updates.
• “Configuring DNS client settings” in Help and Support Center for Windows Server 2003 for
more information about how to install and configure DNS clients.

Deploying DNS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deploying DNS

Uploaded by

Copyright:

Available Formats

C H A P T E R 3

Overview of DNS Deployment

Process for Deploying DNS

DNS designer role

New in Windows Server 2003

Tools for Deploying DNS

Terms and Definitions

Internal namespace A namespace internal to an organization to which it can control access.

Examining Your Current

Determining Internet Status

Identifying the DNS Data Host

Analyzing Your Network Topology

Diagram Your Existing DNS Infrastructure

Identify Your Security Policies

Designing a DNS Namespace

Figure 3.3 Designing a DNS Namespace

Identifying Your DNS Namespace

namespace to support Active Directory, names match your existing DNS

Creating Internal and External Domains

Using an Internal Subdomain

Using Different Internal and External Domain Names

Deciding Whether to Deploy an Internal

Configuring Name Resolution for

Integrating a Windows Server 2003 DNS

Creating DNS Domain Names and

Creating an Internet DNS Domain Name

Creating Internal DNS Domain Names

Creating DNS Computer Names

Creating Computer Names in a New Windows Server 2003 DNS

Creating Computer Names in an Integrated DNS Infrastructure

Creating Computer Names When Upgrading a DNS Infrastructure

Determining if You Need to Support NetBIOS Names

Example: Merging DNS Namespaces

Figure 3.5 shows this configuration.

Designing a DNS Server

Allocating Hardware Resources

Determining the Number of Required DNS

• If high-volume traffic is a consideration in your environment, add additional DNS servers to

Determining DNS Server Placement

Placing DNS Servers for Availability

Using Conditional Forwarding to Query for Names in Off-Site

Administrators configured DNS3.corp.fabrikam.com to forward any queries for corp.treyresearch.com to

Using Conditional Forwarding to Query for Names in Other

Upgrading DNS Servers to Windows

Designing DNS Zones

Choosing a Zone Type

Stub Zones and Conditional Forwarding

Active Directory–Integrated Zones

Storing Active Directory–Integrated Zones in Application Directory

Choosing a Propagation Method

File-Based Zone Transfer

Active Directory Replication

Active Directory zone replication provides the following additional benefits:

Migrating Zones to Windows

Configuring and Managing

Configuring Client DNS Server Lists and

Using Group Policy to Simplify Client

Securing Your DNS Infrastructure

Identifying DNS Security Threats

Developing a DNS Security Policy

Low-Level DNS Security Policy

Mid-Level DNS Security Policy