DNS Server Overview

By using the Domain Name System (DNS) server role, you can provide a primary name resolution
process for users on your network. The name resolution process enables users to locate computers on
the network by querying for a user-friendly computer name instead of an IP address. A computer
running the DNS server role can host the records of a distributed DNS database and use the records to
resolve DNS name queries that are sent by DNS client computers. These queries can include requests
such as the names of Web sites or computers in your network or on the Internet.

You can also integrate the DNS server role with Active Directory Domain Services (AD DS) to store and
replicate DNS zones. This makes multimaster replication possible, along with more secure
transmission of DNS data. In turn, AD DS requires DNS so that clients can locate domain controllers.

In the following sections, learn more about the DNS server role, the required and optional features in
the DNS server role, and hardware and software for running it. In addition, learn how to open the
administrative tool for the DNS server role and how to find more information about it.

What is the DNS server role?

DNS is a system for naming computers and network services that organizes them into a hierarchy of
domains. DNS naming is used on TCP/IP networks, such as the Internet, to locate computers and
services with user-friendly names. When a user enters the DNS name of a computer in an application,
DNS clients and servers work together to look up the name and provide other information that is
associated with the computer, such as its IP address or services that it provides for the network. This
process is called name resolution.

The DNS server role makes it possible for a server running Windows Server® 2008 to act as a name
resolution server for a TCP/IP network. The network can contain computers running Windows as well as
computers running other operating systems. The DNS service in Windows Server 2008 is tightly
integrated with Dynamic Host Configuration Protocol (DHCP) so that Windows-based DHCP clients and
Windows-based DHCP servers automatically register host names and IP addresses on the DNS server
for the appropriate domain.

Typically, Windows Server 2008 DNS is integrated with AD DS. In this environment, DNS namespaces
mirror the Active Directory forests and domains for an organization. Network hosts and services are
configured with DNS names so that they can be located in the network, and they are also configured
with DNS servers that resolve the names of Active Directory domain controllers.

Windows Server 2008 DNS is also often deployed as a non–AD DS, or "standard," DNS solution. For
example, it can be deployed for the purposes of hosting the Internet presence of an organization.

The Windows Server 2008 DNS server service supports and complies with standards that are specified
in the set of DNS Requests for Comments (RFCs). Therefore, it is fully compatible with any other RFC-
compliant DNS server. A DNS client resolver is included as a service in all client and server versions of
the Windows operating system.

New features in the DNS server role

The central feature of the DNS server role is the DNS Server service. This service provides a DNS
server that is fully compliant with industry standards, and it supports all standards-compliant DNS
clients. You can administer a Windows Server 2008 DNS server by using a Microsoft Management
Console (MMC) snap-in as well as a number of command-line tools.

Windows Server 2008 supports the new features in the following table.

Feature Description
DNAME The DNAME resource record provides nonterminal domain name redirection. That
resource is, unlike the CNAME record, which creates an alias for a single node only, a single
record DNAME resource record causes the renaming of a root and all descendents in a
support domain namespace subtree. This makes it possible for organizations to rename a
portion of their domain namespace—for example, to merge two namespaces as a
result of a business acquisition.

Support for Internet Protocol version 6 (IPv6) specifies addresses that are 128 bits in length,
IPv6 compared to IP version 4 (IPv4) addresses, which are 32 bits long. This greater
addresses length allows for a much greater number of globally unique addresses, which are
required to accommodate the explosive growth of the Internet around the world.
IPv6 also provides for better routing and network autoconfiguration. The DNS
server in Windows Server 2008 now supports IPv6 addresses as fully as it
supports IPv4 addresses.

Read-only Windows Server 2008 introduces a new type of domain controller, the read-only
domain domain controller (RODC). An RODC provides, in effect, a shadow copy of a
controller domain controller. You can install it in locations where physical security cannot be
support guaranteed, such as branch offices.

To support RODCs, the DNS server in Windows Server 2008 supports a new type
of zone, the primary read-only zone (also sometimes referred to as a branch
office zone). The primary read-only zone is created automatically when a
computer running the DNS server role is promoted to be an RODC. The zone
contains a read-only copy of the DNS data that is stored in the read-only AD DS
database on the RODC.

The writeable version of the data is stored on a centrally located domain

controller, such as a hub site domain controller. The DNS zone data on the RODC
is updated when the DNS data is replicated from the centrally located domain
controllers to the RODC according to the configured replication schedule.

The administrator of the RODC can view the contents of the read-only primary
zone, but only a domain administrator with permissions on the centrally located
domain controller can change the zone data.

Single-label The DNS Server service now supports a special zone called the GlobalNames zone
name to hold single-label host names. This zone can be replicated across an entire
resolution forest, so that single-label host names (for example, webserver1) can be resolved
throughout the forest without the use of the Windows Internet Naming System
(WINS) protocol. Although the GlobalNames zone is not intended to provide peer-
to-peer single-label name resolution, you can use it to simplify the location of
servers and intranet Web sites, for example.

Hardware and software considerations

Use performance counters, testing in the lab, data from existing hardware in a
production environment, and pilot roll-outs to determine the hardware capacity that is
necessary for your server.

Note

A limited set of server roles is available for the Server Core installation option of Windows
Server 2008 and for Windows Server 2008 for Itanium-Based Systems.
Typical DNS server hardware recommendations include the following:

 Single-processor computers with 400-megahertz (MHz) Pentium II CPUs

 512 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 improve the scalability and performance of your
DNS servers. DNS servers use approximately 100 bytes of RAM for each resource record. Using this
figure, which you can obtain by looking at each zone in the DNS snap-in, you can calculate how much
memory you need.

Installing a DNS server

After you finish installing the operating system, a list of initial configuration tasks appears. To install a
DNS server, in the list of tasks, click Add roles, and then click DNS server.

Managing a DNS server

You can manage server roles with MMC snap-ins. Use the DNS snap-in to manage a DNS server. To
open the DNS snap-in, click Start, point to Administrative Tools, and then click DNS.

DNS Infrastructure
Updated: November 13, 2007

The Domain Name System (DNS) infrastructure consists of DNS servers that run the DNS Server
service and DNS clients that run the DNS Client service.

DNS is a system for naming computers and network services that is organized into a hierarchy of
domains. DNS naming is used in TCP/IP networks, such as the Internet, to locate computers and
services with user-friendly names. When a user enters a DNS name in an application, DNS services can
resolve the name to other information that is associated with the name, such as an IP address.

Hierarchy of Managed Entities

Managed Entities

Name Description

DNS A DNS server hosts the information that enables client computers to resolve memorable,
Server alphanumeric DNS names to the IP addresses that computers use to communicate with
each other. Most often, the DNS server responds to requests from DNS clients to provide
the IP address associated with a host's DNS domain name. DNS servers can also be
configured to provide the name of a host when it receives a query containing the host's
IP address, and DNS servers can also provide the IP addresses of other servers
configured to provide certain services, such as e-mail.
DNS names are organized into a hierarchy of domains, and domains are grouped and
managed in zones on the DNS server.
The DNS Server role in Windows Server 2008 combines support for standard DNS
protocols with the benefits of integration with Active Directory Domain Services (AD DS)
and other Windows networking and security features, including such advanced
capabilities as secure dynamic update of DNS resource records.

DNS The DNS Client service is the client component that resolves and caches Domain Name
Client System (DNS) domain names. When the DNS Client service receives a request to resolve
a DNS name that it does not contain in its cache, it queries an assigned DNS server for
 an IP address for the name. If the DNS Client service receives the requested address, it
stores the name and address in its cache to resolve future requests without having to
query the DNS server. All computers that use DNS to resolve domain names (including
DNS servers and domain controllers) use the DNS Client service for this purpose.

What's New in DNS in Windows Server 2008

Updated: April 25, 2007

Domain Name System (DNS) is a system that is used in TCP/IP networks for naming computers and
network services that is organized into a hierarchy of domains. DNS naming locates computers and
services through user-friendly names. When a user enters a DNS name in an application, DNS services
can resolve the name to other information that is associated with the name, such as an IP address.

Windows Server® 2008 provides a number of enhancements to the DNS Server service that improve
how DNS performs. For details about these changes, see DNS Server Role.

Overview of the Improvements in DNS

The DNS Server role in Windows Server 2008 contains four new or enhanced features that improve the
performance of the DNS Server service or give it new abilities:

 Background zone loading: DNS servers that host large DNS zones that are stored in Active
Directory Domain Services (AD DS) are able to respond to client queries more quickly when
they restart because zone data is now loaded in the background.
 IP version 6 (IPv6) support: The DNS Server service now fully supports the longer addresses of
the IPv6 specification.
 Support for read-only domain controllers (RODCs): The DNS Server role in Windows
Server 2008 provides primary read-only zones on RODCs.
 Global single names: The GlobalNames zone provides single-label name resolution for large
enterprise networks that do not deploy Windows Internet Name Service (WINS). The
GlobalNames zone is useful when using DNS name suffixes to provide single-label name
resolution is not practical.
 Global query block list: Clients of such protocols as the Web Proxy Auto-Discovery Protocol
(WPAD) and the Intra-site Automatic Tunnel Addressing Protocol (ISATAP) that rely on DNS
name resolution to resolve well-known host names are vulnerable to malicious users who use
dynamic update to register host computers that pose as legitimate servers. The DNS Server
role in Windows Server 2008 provides a global query block list that can help reduce this
vulnerability.

Checklist: Add a Domain Controller with the DNS Server

Service
Integrating Domain Name System (DNS) with Active Directory Domain Services (AD DS) provides
automatic replication between domain controllers in a common domain or forest. By installing multiple
domain controllers in a domain running the DNS Server service, you can ensure that DNS will continue
to work if a domain controller fails or is taken offline for maintenance. Having multiple domain
controllers can also give you the ability to locate the servers in sites where they can be reached most
efficiently by DNS clients. In addition, the resulting load balancing can improve overall DNS
performance.

Task Reference

Read about DNS integration with AD DS. Understanding Active

 Directory Domain Services
Integration

Plan how to divide up your DNS domain name and network address Planning DNS Zones
space into forward and reverse lookup zones, as needed.

Plan your server deployment, including determining how many Planning DNS Servers
servers to use and where to put them on your network, keeping in
mind that by default domain controllers also operate as DNS
servers.

If clients on your network must be able to resolve external DNS Using Forwarders;
names, consider whether you should configure and use forwarders
at DNS servers on your network. Configure a DNS Server to
Use Forwarders

Determine how to manage DNS client resolver configurations. Checklist: Configure DNS
Client Settings

Install and configure domain controllers and domains for hosting Install a DNS Server;
your zones.
Configure a DNS Server for
Use with Active Directory
Domain Services

As needed, add delegations in parent zones for any subdomains. Understanding Zone
Delegation;
For example, if you are adding sub.corp.contoso.com as a new
Active Directory domain, you add to it a delegation at the Create a Zone Delegation
corp.contoso.com zone.

Understanding Active Directory Domain Services

Integration
The DNS Server service is integrated into the design and implementation of Active Directory Domain
Services (AD DS). AD DS provides an enterprise-level tool for organizing, managing, and locating
resources in a network.

When you deploy Domain Name System (DNS) servers with AD DS, consider the following:

 DNS is required for locating domain controllers.

The Net Logon service uses DNS server support to provide registration of domain controllers
in your DNS domain namespace.
 DNS servers running Windows Server 2003 or Windows Server 2008 can use AD DS for storing
and replicating your zones.
By integrating your zones with AD DS, you can take advantage of DNS features, such as
AD DS replication, secure dynamic updates, and record aging and scavenging.

How DNS integrates with AD DS

When you install AD DS on a server, you promote the server to the role of a domain controller for a
specified domain. As part of this process, you are prompted to specify a DNS domain name for the
AD DS domain which you are joining and for which you are promoting the server, and you are offered
the option to install the DNS Server role. This option is provided because a DNS server is required to
locate this server or other domain controllers for members of an AD DS domain.

Benefits of AD DS integration

For networks that deploy DNS to support AD DS, directory-integrated primary zones are strongly
recommended. They provide the following benefits:

 DNS features multimaster data replication and enhanced security based on the capabilities of
AD DS.
 In a standard zone storage model, DNS updates are conducted based on a single-master
update model. In this model, a single authoritative DNS server for a zone is designated as the
primary source for the zone. This server maintains the master copy of the zone in a local file.
With this model, the primary server for the zone represents a single fixed point of failure. If
this server is not available, update requests from DNS clients are not processed for the zone.
With directory-integrated storage, dynamic updates to DNS are sent to any AD DS-integrated
DNS server and are replicated to all other AD DS-integrated DNS servers by means of AD DS
replication. In this model, any AD DS-integrated DNS servercan accept dynamic updates for
the zone. Because the master copy of the zone is maintained in the AD DS database, which is
fully replicated to all domain controllers, the zone can be updated by the DNS servers
operating at any domain controller for the domain. With the multimaster update model of
AD DS, any of the primary servers for the directory-integrated zone can process requests
from DNS clients to update the zone as long as a domain controller is available and reachable
on the network.
Also, when you use directory-integrated zones, you can use access control list (ACL) editing to
secure a dnsZone object container in the directory tree. This feature provides detailed access
to either the zone or a specified resource record in the zone. For example, an ACL for a zone
resource record can be restricted so that dynamic updates are allowed only for a specified
client computer or a secure group, such as a domain administrators group. This security
feature is not available with standard primary zones.
 Zones are replicated and synchronized to new domain controllers automatically whenever a
new one is added to an AD DS domain.
Although the DNS Server service can be selectively removed from a domain controller,
directory-integrated zones are already stored at each domain controller. Therefore, zone
storage and management is not an additional resource. Also, the methods that are used to
synchronize directory-stored information offer performance improvement over standard zone
update methods, which can potentially require transfer of the entire zone.
 By integrating storage of your DNS zone databases in AD DS, you can streamline database
replication planning for your network.
When your DNS namespace and AD DS domains are stored and replicated separately, you
must plan and potentially administer each of these items separately. For example, when you
use standard DNS zone storage and AD DS together, you have to design, implement, test,
and maintain two different database replication topologies.
For example, one replication topology is needed for replicating directory data between
domain controllers, and another topology is needed for replicating zone databases between
DNS servers. This can create additional administrative complexity for planning and designing
your network and allowing for its eventual growth. By integrating DNS storage, you unify
storage management and replication issues for both DNS and AD DS, merging and viewing
them together as a single administrative entity.
 Directory-integrated replication is faster and more efficient than standard DNS replication.
Because AD DS replication processing is performed on a per-property basis, only relevant
changes are propagated. Less data is used and submitted in updates for directory-stored
zones.

Only primary zones can be stored in the directory. A DNS server cannot store secondary zones in the
directory. It must store them in standard text files. The multimaster replication model of AD DS
removes the need for secondary zones when all zones are stored in AD DS.

For more information about configuring DNS for AD DS integration, see Configure a DNS Server for Use
with Active Directory Domain Services and Checklist: Add a Domain Controller with the DNS Server
Service.

Configure a DNS Server to Use Forwarders

A forwarder is a Domain Name System (DNS) server on a network that is used to forward DNS queries
for external DNS names to DNS servers outside that network. You can also configure your server to
forward queries according to specific domain names using conditional forwarders.

A DNS server on a network is designated as a forwarder when the other DNS servers in the network
are configured to forward the queries that they cannot resolve locally to that DNS server. By using a
forwarder, you can manage name resolution for names outside your network, such as names on the
Internet, which can improve the efficiency of name resolution for the computers in your network. For
more information about forwarders and conditional forwarders, see Understanding Forwarders.

Membership in the Administrators group, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

Configuring a DNS server to use forwarders

 Using the Windows interface

 Using a command line

To configure a DNS server to use forwarders using the Windows interface

1. Open DNS Manager.

2. In the console tree, click the applicable DNS server.

Where?

 DNS/Applicable DNS server

3. On the Action menu, click Properties.

4. On the Forwarders tab, click Edit.

5. Type the IP address or fully qualified domain name (FQDN) of a forwarder, and then click OK.

Additional considerations

 To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

 To create a new domain name, click New, and then, under DNS domain, type the domain
name.
 When you specify a conditional forwarder, select a DNS domain name before you enter an IP
address.
 By default, the DNS server waits five seconds for a response from one forwarder IP address
before it tries another forwarder IP address. In Number of seconds before forward
queries time out, you can change the number of seconds that the DNS server waits. When
the server has exhausted all forwarders, it attempts standard recursion.
 If you want the DNS server to only use forwarders and not attempt any further recursion if the
forwarders fail, select the Do not use recursion for this domain check box.
You can disable recursion for the DNS server so that it will not perform recursion on any
query. If you disable recursion on the DNS server, you will not be able to use forwarders on
the same server.
 Do not enter a forwarder's IP address more than once in a DNS server's forwarders list
because it is a more reliable or geographically closer server. If you prefer one of the
forwarders, put that forwarder first in the series of forwarder IP addresses.
 You cannot use a domain name in a conditional forwarder if the DNS server hosts a primary
zone, secondary zone, or stub zone for that domain name. For example, if a DNS server is
 authoritative for the domain name corp.contoso.com (that is, it hosts the primary zone for
that domain name), you cannot configure that DNS server with a conditional forwarder for
corp.contoso.com.
 You can prevent common problems that are associated with forwarders by configuring your
DNS servers to avoid overusing your forwarders.

To configure a DNS server to use forwarders using a command line

1. Open a command prompt.

2. Type the following command, and then press ENTER:

Copy Code
dnscmd <ServerName> /ResetForwarders <MasterIPaddress ...>
[/TimeOut <Time>] [/Slave]

Parameter Description

dnscmd Specifies the name of the command-line tool for managing DNS servers.

<ServerName> Required. Specifies the DNS host name of the DNS server. You can also
type the IP address of the DNS server. To specify the DNS server on the
local computer, you can also type a period (.).

/ResetForwarders Required. Configures a forwarder.

<MasterIPaddress... Required. Specifies a space-separated list of one or more IP addresses of

> the DNS servers where queries are forwarded. You may specify a list of
space-separated IP addresses.

/TimeOut Specifies the timeout setting. The timeout setting is the number of
seconds before unsuccessful forward queries time out.

<Time> Specifies the value for the /TimeOut parameter. The value is in seconds.
The default timeout is five seconds.

/Slave Determines whether or not the DNS server uses recursion when it queries
for the domain name that is specified by ZoneName.

To view the complete syntax for this command, at a command prompt, type the following command,
and then press ENTER:

Copy Code
dnscmd /ResetForwarders /help
Additional considerations

 To open an elevated Command Prompt window, click Start, point to All Programs, click
Accessories, right-click Command Prompt, and then click Run as administrator.
 To set the conditional forwarder for a zone, use the following command:

Copy Code
dnscmd <ServerName> /ZoneAdd <ZoneName> /Forwarder
<MasterIPaddress ...> [/TimeOut <Time>] [/Slave]
 The /ZoneAdd command adds the zone specified by the ZoneName parameter. The
parameter IPAddress is the IP address where the DNS server will forward unsolvable DNS
queries. The /Slave parameter sets the DNS server as a subordinate server. The /NoSlave
parameter (default setting) sets the DNS server as a nonsubordinate server, which means
that it will perform recursion. The /Timeout and Time parameters are described in the
previous table.

 To view a zone that is added only as a conditional forwarder, use the following command:

Copy Code
dnscmd <ServerName> /ZoneInfo <ZoneName>

 To reset the forwarder IP addresses for a conditional forwarder domain name, use the
following command:

Copy Code
dnscmd <ServerName> /ZoneResetMasters <ZoneName> [/Local]
[<ServerIPs>]

The /Local parameter sets the local master list for Active Directory–integrated forwarders.
The ServerIPs parameter is the list of one or more IP addresses of master servers for the
zone. Master servers may include DNS servers that host primary or secondary copies of the
zone, but they should not include DNS server IP addresses in such a way that two DNS
servers that host copies of a zone use each other as master servers. Such a configuration
makes the forwarding path cyclical.

 You cannot use a domain name in a conditional forwarder if the DNS server hosts a primary
zone, secondary zone, or stub zone for that domain name. For example, if a DNS server is
authoritative for the domain name corp.contoso.com (that is, it hosts the primary zone for
that domain name), you cannot configure that DNS server with a conditional forwarder for
corp.contoso.com.
 You can prevent common problems that are associated with forwarders by configuring your
DNS servers to avoid overusing your forwarders.

Install a DNS Server

Installing a Domain Name System (DNS) server involves adding the DNS server role to an existing
Windows Server 2008 server. You can also install the DNS server role when you install the Active
Directory Domain Services (AD DS) role. This is the preferred method for installing the DNS Server role
if you want to integrate your DNS domain namespace with the AD DS domain namespace.

Membership in the Administrators group, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

To install a DNS server

1. Open Server Manager. To open Server Manager, click Start, and then click Server Manager.

2. In the results pane, under Roles Summary, click Add roles.

3. In the Add Roles Wizard, if the Before You Begin page appears, click Next.

4. In the Roles list, click DNS Server, and then click Next.
5. Read the information on the DNS Server page, and then click Next.

6. On the Confirm Installation Options page, verify that the DNS Server role will be installed,
and then click Install.

Additional considerations

 We recommend that you configure the computer to use a static IP address. If the DNS server
is configured to use DHCP-assigned dynamic addresses, when the DHCP server assigns a new
IP address to the DNS server, the DNS clients that are configured to use that DNS server's
previous IP address will not be able to resolve the previous IP address and locate the DNS
server.
 After you install a DNS server, you can decide how to administer it and its zones. Although
you can use a text editor to make changes to server boot and zone files, this method is not
recommended. DNS Manager and the DNS command-line tool, dnscmd, simplify
maintenance of these files, and they should be used whenever possible. After you begin using
DNS Manager or command-line management of these files, editing them manually is not
recommended.
 You can administer DNS zones that are integrated with AD DS only with DNS Manager or the
dnscmd command-line tool. You cannot administer these zones with a text editor.
 If you uninstall a DNS server that hosts AD DS-integrated zones, these zones are saved or
deleted according to their storage type. For all storage types, the zone data is stored on other
domain controllers or DNS servers. The zone data is not deleted unless the DNS server that
you uninstall is the last DNS server hosting that zone.
 If you uninstall a DNS server that hosts standard DNS zones, the zone files remain in the
%systemroot%\system32\Dns directory, but they are not reloaded if the DNS server is
reinstalled. If you create a new zone with the same name as an old zone, the old zone file is
replaced with the new zone file.
 When they write DNS server boot and zone data to text files, DNS servers use the Berkeley
Internet Name Domain (BIND) file format that is recognized by legacy BIND 4 servers, not the
more recent BIND 8 format.

Configure a DNS Server for Use with Active Directory

Domain Services
When you install Active Directory Domain Services (AD DS) with the Active Directory Domain Services
Installation Wizard, the wizard gives you the option to automatically install and configure a DNS
server. The resulting DNS zone is integrated with the AD DS domain that is controlled by the AD DS
server.

To install AD DS on this computer, use Server Manager.

 This method applies only to server computers that are used as domain controllers. If member
servers (server that are not used as domain controllers) are used as DNS servers, they are
not integrated with AD DS.
 If you choose the wizard option to automatically install and configure a local DNS server, the
DNS server is installed on the computer where you are running the wizard and the computer's
preferred DNS server setting is configured to use the new local DNS server. Configure any
other computers that will join this domain to use this DNS server's IP address as their
preferred DNS server.

Understanding Zone Delegation

Domain Name System (DNS) provides the option of dividing up the namespace into one or more zones,
which can then be stored, distributed, and replicated to other DNS servers. When you are deciding
whether to divide your DNS namespace to make additional zones, consider the following reasons to
use additional zones:

 You want to delegate management of part of your DNS namespace to another location or
department in your organization.
 You want to divide one large zone into smaller zones to distribute traffic loads among multiple
servers, improve DNS name resolution performance, or create a more-fault-tolerant DNS
environment.
 You want to extend the namespace by adding numerous subdomains at once, for example, to
accommodate the opening of a new branch or site.

If, for any of these reasons, you can benefit from delegating zones, it might make sense to restructure
your namespace by adding additional zones. When you are deciding how to structure zones, use a
plan that reflects the structure of your organization.

When you delegate zones within your namespace, remember that for each new zone that you create,
you need delegation records in other zones that point to the authoritative DNS servers for the new
zone. This is necessary both to transfer authority and to provide correct referral to other DNS servers
and clients of the new servers that are being made authoritative for the new zone.

When a standard primary zone is first created, all the resource record information is stored as a text
file on a single DNS server. This server acts as the primary master for the zone. Zone information can
be replicated to other DNS servers to improve fault tolerance and server performance.

When you are structuring your zones, there are several good reasons to use additional DNS servers for
zone replication:

 Added DNS servers provide zone redundancy, which makes it possible for DNS names in the
zone to be resolved for clients if a primary server for the zone stops responding.
 Added DNS servers can be placed so as to reduce DNS network traffic. For example, adding a
DNS server to the opposing side of a low-speed, wide area network (WAN) link can be useful
in managing and reducing network traffic.
 Additional secondary servers can be used to reduce loads on a primary server for a zone.

Example: Delegating a subdomain to a new zone

As shown in the following illustration, when a new zone for a subdomain (example.microsoft.com) is
created, delegation from the parent zone (microsoft.com) is needed.
In this example, an authoritative DNS server computer for the newly delegated example.microsoft.com
subdomain is named that is based on a derivative subdomain that is included in the new zone
(ns1.na.example.microsoft.com). To make this server known to other servers outside the new
delegated zone, two resource records are necessary in the microsoft.com zone to complete delegation
to the new zone.

These resource records include the following:

 A name server (NS) resource record to effect the delegation. This resource record advertises
that the server named ns1.na.example.microsoft.com is an authoritative server for the
delegated subdomain.
 A host (A or AAAA) resource record (also known as a glue record) is necessary to resolve the
name of the server that is specified in the NS resource record to its IP address. The process of
resolving the host name in this resource record to the delegated DNS server in the name
server (NS) resource record is sometimes referred to as glue chasing.

Create a Zone Delegation

You can divide your Domain Name System (DNS) namespace into one or more zones. You can
delegate management of part of your namespace to another location or department in your
organization by delegating the management of the corresponding zone. For more information, see
Understanding Zone Delegation.

When you delegate a zone, remember that for each new zone that you create, you will need
delegation records in other zones that point to the authoritative DNS servers for the new zone. This is
necessary both to transfer authority and to provide correct referral to other DNS servers and clients of
the new servers that are being made authoritative for the new zone.

Membership in the Administrators group, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

Creating a zone delegation

  Using the Windows interface

 Using a command line

To create a zone delegation using the Windows interface

1. Open DNS Manager.

2. In the console tree, right-click the applicable subdomain, and then click New Delegation.

3. Follow the instructions in the New Delegation Wizard to finish creating the new delegated
domain.

Additional considerations

 To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

 All domains (or subdomains) that appear as part of the applicable zone delegation must be
created in the current zone before delegation is performed as described here. As necessary,
use DNS Manager to first add domains to the zone before you complete this procedure.

To create a zone delegation using a command line

1. Open a command prompt.

2. Type the following command, and then press ENTER:

Copy Code
dnscmd <ServerName> /RecordAdd <ZoneName> <NodeName> [/Aging]
[/OpenAcl] [<Ttl>] NS {<HostName>|<FQDN>}

Parameter Description

dnscmd Specifies the name of the command-line tool for managing DNS servers.

<ServerName> Required. Specifies the DNS host name of the DNS server. You can also
type the IP address of the DNS server. To specify the DNS server on the
local computer, you can also type a period (.)

/RecordAdd Required. Specifies the command to add a resource record.

<ZoneName> Required. Specifies the fully qualified domain name (FQDN) of the zone.

<NodeName> Required. Specifies the FQDN of the node in the DNS namespace for
which the start of authority (SOA) resource record is added. You can also
type the node name relative to the ZoneName or @, which specifies the
zone's root node.

/Aging If this command is used, this resource record is able to be aged and
scavenged. If this command is not used, the resource record remains in
the DNS database unless it is manually updated or removed.

/OpenAcl Specifies that new records are open to modification by any user. Without
this parameter, only administrators may modify the new record.

<Ttl> Specifies the Time To Live (TTL) setting for the resource record. (The
default TTL is defined in start of authority (SOA) resource record).

NS Required. Specifies that you are adding a name server (NS) resource
 record to the zone that is specified in ZoneName.

<HostName>| Required. Specifies the host name or FQDN of the new authoritative
<FQDN> server.

To view the complete syntax for this command, at a command prompt, type the following command,
and then press ENTER:

Copy Code
dnscmd /RecordAdd /help

Checklist: Store Data in an AD DS Application Partition

You can store Domain Name System (DNS) zones in the domain or application directory partitions of
Active Directory Domain Services (AD DS). An application directory partition is a data structure in
AD DS that distinguishes data for different replication purposes. When you store a DNS zone in an
application directory partition, you can control the zone replication scope by controlling the replication
scope of the application directory partition. For a zone to be stored in the specified application
directory partition, the DNS server hosting the zone must be enlisted in the specified application
directory partition. By default, each AD DS-integrated DNS server maintains enlistments for itself in
the appropriate DomainDnsZones and ForestDnsZones application directory partitions.

Task Reference

Read about AD DS integration. Understanding Active Directory Domain

Services Integration

Read about zone replication. Understanding DNS Zone Replication in

Active Directory Domain Services

Create an application directory partition. Create a DNS Application Directory

Partition

Enlist additional domain controllers in the Enlist a DNS Server in a DNS Application
application directory partition. Directory Partition

Configure the replication scope of the zones to the Change the Zone Replication Scope
scope of the application directory partition.

Understanding Active Directory Domain Services

Integration
The DNS Server service is integrated into the design and implementation of Active Directory Domain
Services (AD DS). AD DS provides an enterprise-level tool for organizing, managing, and locating
resources in a network.

When you deploy Domain Name System (DNS) servers with AD DS, consider the following:

 DNS is required for locating domain controllers.

The Net Logon service uses DNS server support to provide registration of domain controllers
in your DNS domain namespace.
 DNS servers running Windows Server 2003 or Windows Server 2008 can use AD DS for storing
and replicating your zones.
By integrating your zones with AD DS, you can take advantage of DNS features, such as
AD DS replication, secure dynamic updates, and record aging and scavenging.

How DNS integrates with AD DS

When you install AD DS on a server, you promote the server to the role of a domain controller for a
specified domain. As part of this process, you are prompted to specify a DNS domain name for the
AD DS domain which you are joining and for which you are promoting the server, and you are offered
the option to install the DNS Server role. This option is provided because a DNS server is required to
locate this server or other domain controllers for members of an AD DS domain.

Benefits of AD DS integration

For networks that deploy DNS to support AD DS, directory-integrated primary zones are strongly
recommended. They provide the following benefits:

 DNS features multimaster data replication and enhanced security based on the capabilities of
AD DS.
In a standard zone storage model, DNS updates are conducted based on a single-master
update model. In this model, a single authoritative DNS server for a zone is designated as the
primary source for the zone. This server maintains the master copy of the zone in a local file.
With this model, the primary server for the zone represents a single fixed point of failure. If
this server is not available, update requests from DNS clients are not processed for the zone.
With directory-integrated storage, dynamic updates to DNS are sent to any AD DS-integrated
DNS server and are replicated to all other AD DS-integrated DNS servers by means of AD DS
replication. In this model, any AD DS-integrated DNS servercan accept dynamic updates for
the zone. Because the master copy of the zone is maintained in the AD DS database, which is
fully replicated to all domain controllers, the zone can be updated by the DNS servers
operating at any domain controller for the domain. With the multimaster update model of
AD DS, any of the primary servers for the directory-integrated zone can process requests
from DNS clients to update the zone as long as a domain controller is available and reachable
on the network.
Also, when you use directory-integrated zones, you can use access control list (ACL) editing to
secure a dnsZone object container in the directory tree. This feature provides detailed access
to either the zone or a specified resource record in the zone. For example, an ACL for a zone
resource record can be restricted so that dynamic updates are allowed only for a specified
client computer or a secure group, such as a domain administrators group. This security
feature is not available with standard primary zones.
 Zones are replicated and synchronized to new domain controllers automatically whenever a
new one is added to an AD DS domain.
Although the DNS Server service can be selectively removed from a domain controller,
directory-integrated zones are already stored at each domain controller. Therefore, zone
storage and management is not an additional resource. Also, the methods that are used to
synchronize directory-stored information offer performance improvement over standard zone
update methods, which can potentially require transfer of the entire zone.
 By integrating storage of your DNS zone databases in AD DS, you can streamline database
replication planning for your network.
When your DNS namespace and AD DS domains are stored and replicated separately, you
must plan and potentially administer each of these items separately. For example, when you
use standard DNS zone storage and AD DS together, you have to design, implement, test,
and maintain two different database replication topologies.
For example, one replication topology is needed for replicating directory data between
domain controllers, and another topology is needed for replicating zone databases between
DNS servers. This can create additional administrative complexity for planning and designing
your network and allowing for its eventual growth. By integrating DNS storage, you unify
storage management and replication issues for both DNS and AD DS, merging and viewing
them together as a single administrative entity.
  Directory-integrated replication is faster and more efficient than standard DNS replication.
Because AD DS replication processing is performed on a per-property basis, only relevant
changes are propagated. Less data is used and submitted in updates for directory-stored
zones.

Only primary zones can be stored in the directory. A DNS server cannot store secondary zones in the
directory. It must store them in standard text files. The multimaster replication model of AD DS
removes the need for secondary zones when all zones are stored in AD DS.

For more information about configuring DNS for AD DS integration, see Configure a DNS Server for Use
with Active Directory Domain Services and Checklist: Add a Domain Controller with the DNS Server
Service.

Understanding DNS Zone Replication in Active Directory

Domain Services
You can store Domain Name System (DNS) zones in the domain or application directory partitions of
Active Directory Domain Services (AD DS). A partition is a data structure in AD DS that distinguishes
data for different replication purposes. For more information, see Understanding Active Directory
Domain Services Integration.

The following table describes the available zone replication scopes for AD DS-integrated DNS zone
data.

Zone replication scope Description

All DNS servers in the forest Replicates zone data to all Windows Server 2003 and Windows
that are domain controllers Server 2008 domain controllers running the DNS Server service in
running Windows the AD DS forest. This option replicates zone data to the
Server 2003 or Windows ForestDNSZones partition. Therefore, it provides the broadest
Server 2008 replication scope.

All DNS servers in the Replicates zone data to all Windows Server 2003 and Windows
domain that are domain Server 2008 domain controllers running the DNS Server service in
controllers running Windows the Active Directory domain. This option replicates zone data to
Server 2003 or Windows the DomainDNSZone partition. It is the default setting for DNS zone
Server 2008 replication in Windows Server 2003 and Windows Server 2008.

All domain controllers in the Replicates zone data to all domain controllers in the
Active Directory domain Active Directory domain. If you want Windows 2000 DNS servers to
load an Active Directory–integrated zone, you must specify this
scope for that zone.

All domain controllers in a Replicates zone data according to the replication scope of the
specified application specified application directory partition. For a zone to be stored in
directory partition the specified application directory partition, the DNS server hosting
the zone must be enlisted in the specified application directory
partition. Use this scope when you want zone data to be replicated
to domain controllers in multiple domains but you do not want the
data to replicate to the entire forest. For more information, see
Create a DNS Application Directory Partition and Enlist a DNS
Server in a DNS Application Directory Partition.

When you decide which replication scope to choose, consider that the broader the replication scope,
the greater the network traffic caused by replication. For example, if you decide to have AD DS–
integrated DNS zone data replicated to all DNS servers in the forest, this will produce greater network
traffic than replicating the DNS zone data to all DNS servers in a single AD DS domain in that forest.

AD DS-integrated DNS zone data that is stored in an application directory partition is not replicated to
the global catalog for the forest. The domain controller that contains the global catalog can also host
application directory partitions, but it will not replicate this data to its global catalog.
AD DS-integrated DNS zone data that is stored in a domain partition is replicated to all domain
controllers in its AD DS domain, and a portion of this data is stored in the global catalog. This setting is
used to support Windows 2000.

If an application directory partition's replication scope replicates across AD DS sites, replication will
occur with the same intersite replication schedule as is used for domain partition data.

By default, the Net Logon service registers domain controller locator (Locator) DNS resource records
for the application directory partitions that are hosted on a domain controller in the same manner as it
registers domain controller locator (Locator) DNS resource records for the domain partition that is
hosted on a domain controller.

Create a DNS Application Directory Partition

You can store Domain Name System (DNS) zones in the domain or application directory partitions of
Active Directory Domain Services (AD DS). A partition is a data structure in AD DS that distinguishes
data for different replication purposes. When you create an application directory partition for DNS, you
can control the scope of replication for the zone that is stored in that partition. For more information,
see Understanding Active Directory Domain Services Integration.

Membership in the Enterprise Admins group is required to complete this procedure. Review details
about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.

To create a DNS application directory partition

1. Open a command prompt.

2. Type the following command, and then press ENTER:

Copy Code
dnscmd <ServerName> /CreateDirectoryPartition <FQDN>

Parameter Description

dnscmd Specifies the name of the command-line tool for managing DNS
servers.

<ServerName> Required. Specifies the DNS host name of the DNS server. You can also
type the IP address of the DNS server. To specify the DNS server on the
local computer, you can also type a period (.).

/ Required. Creates a DNS application directory partition.

CreateDirectoryPartition

<FQDN> Required. Specifies the name of the new DNS application directory
partition. You must use a DNS fully qualified domain name (FQDN).

To view the complete syntax for this command, at a command prompt, type the following command,
and then press ENTER:

Copy Code
dnscmd /CreateDirectoryPartition /?
Additional considerations

 To open an elevated Command Prompt window, click Start, point to All Programs, click
Accessories, right-click Command Prompt, and then click Run as administrator.
Enlist a DNS Server in a DNS Application Directory
Partition
After you create a Domain Name System (DNS) application directory partition to store a zone, you
must enlist the DNS server that hosts the zone in the application directory partition. For more
information, see Understanding DNS Zone Replication in Active Directory Domain Services.

Membership in DnsAdmins or Domain Admins, or the equivalent, is the minimum required to

complete this procedure. Review details about using the appropriate accounts and group memberships
at http://go.microsoft.com/fwlink/?LinkId=83477.

To enlist a DNS server in a DNS application directory partition

1. Open a command prompt.

2. Type the following command, and then press ENTER:

Copy Code
dnscmd <ServerName> /EnlistDirectoryPartition <FQDN>

Value Description

dnscmd Specifies the name of the command-line tool for managing DNS servers.

<ServerName> Required. Specifies the DNS host name of the DNS server. You can also
type the IP address of the DNS server. To specify the DNS server on the
local computer, you can also type a period (.).

/ Required. Enlists a DNS server in a DNS application directory partition.

EnlistDirectoryPartition

<FQDN> Required. Specifies the fully qualified domain name (FQDN) of the DNS
application directory partition.

To view the complete syntax for this command, at a command prompt, type the following command,
and then press ENTER:

Copy Code
dnscmd /EnlistDirectoryPartition /?

Change the Zone Replication Scope

You can use the following procedure to change the replication scope for a zone. Only Active Directory
Domain Services (AD DS)–integrated primary and stub forward lookup zones can change their
replication scope. Secondary forward lookup zones cannot change their replication scope.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure.

Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

Changing zone replication scope

 Using the Windows interface

 Using a command line

To change zone replication scope using the Windows interface

1. Open DNS Manager.

2. In the console tree, right-click the applicable zone, and then click Properties.
3. On the General tab, note the current zone replication type, and then click Change.

4. Select a replication scope for the zone.

Additional considerations

 To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To change zone replication scope using the command line

 At a command prompt, type the following command, and then press ENTER:

Copy Code
dnscmd <ServerName> /ZoneChangeDirectoryPartition <ZoneName>
<NewPartitionName>

Parameter Description

dnscmd Specifies the name of the command-line tool for managing DNS
servers.

<ServerName> Required. Specifies the Domain Name System (DNS) host name
of the DNS server. You can also type the IP address of the DNS
server. To specify the DNS server on the local computer, you can
also type a period (.)

/ Required. Changes a zone's replication scope.

ZoneChangeDirectoryPartition

<ZoneName> Required. Specifies the fully qualified domain name (FQDN) of the
zone.

<NewPartitionName> Required. The FQDN of the DNS application directory partition

where the zone will be stored.

Checklist: Use Forwarders

By using a forwarder, you can manage name resolution for names that are outside your network, such
as names on the Internet or names in other forests or domains.

Task Reference

Read about forwarders. Understanding Forwarders

Plan how you will deploy forwarders in your network. Using Forwarders

Configure the firewall that your network uses to allow only one
Domain Name System (DNS) server to communicate with the
Internet.

Configure other servers to use this DNS server as a forwarder. Configure a DNS Server to
Use Forwarders

Checklist: Automatically Remove Stale Resource Records

Aging and scavenging together provide a mechanism for removing stale resource records. These
resource records can accumulate in Domain Name System (DNS) zone data over time when computers
permanently leave the network. For example, if a computer registers its host (A) resource record at
startup and is later disconnected from the network, its host (A) resource record might not be deleted.
If your network has mobile users and computers, this situation can occur frequently.

Task Reference

Read about aging and scavenging. Understanding Aging and Scavenging

Enable and configure aging and scavenging Set Aging and Scavenging Properties for the DNS
for the DNS server. Server

Enable and configure aging and scavenging Set Aging and Scavenging Properties for a Zone
for zones

Configure aging and scavenging for Reset Aging and Scavenging Properties for a
individual resource records. Specified Resource Record

Understanding Aging and Scavenging

The DNS Server service supports aging and scavenging features. These features are provided as a
mechanism for performing cleanup and removal of stale resource records, which can accumulate in
zone data over time.

With dynamic update, resource records are automatically added to zones when computers start on the
network. However, in some cases, they are not automatically removed when computers leave the
network. For example, if a computer registers its own host (A) resource record at startup and is later
improperly disconnected from the network, its host (A) resource record might not be deleted. If your
network has mobile users and computers, this situation can occur frequently.

If left unmanaged, the presence of stale resource records in zone data may cause some problems:

 If a large number of stale resource records remain in zones, they can eventually take up
server disk space and cause unnecessarily long zone transfers.
 Domain Name System (DNS) servers that load zones that contain stale resource records
might use outdated information to answer client queries, potentially causing the clients to
experience name resolution problems on the network.
 The accumulation of stale resource records at the DNS server can degrade its performance
and responsiveness.
 In some cases, the presence of a stale resource record in a zone can prevent a DNS domain
name from being used by another computer or host device.

To solve these problems, the DNS Server service has the following features:

 Time stamping, based on the current date and time that is set at the server computer, for any
resource records that are added dynamically to primary-type zones. In addition, time stamps
are recorded in standard primary zones where aging and scavenging is enabled.
For resource records that you add manually, a time-stamp value of zero is used, indicating
that these records are not affected by the aging process and that they can remain without
limitation in zone data unless you otherwise change their time stamp or delete them.
 Aging of resource records in local data, based on a specified refresh time period, for any
eligible zones.
Only primary-type zones that are loaded by the DNS Server service are eligible to participate
in this process.
  Scavenging for any resource records that persist beyond the specified refresh period.
When a DNS server performs a scavenging operation, it can determine that resource records
have aged to the point of becoming stale and remove them from zone data. You can
configure servers to perform recurring scavenging operations automatically, or you can
initiate an immediate scavenging operation at the server.
For more information, see either Enable Automatic Scavenging of Stale Resource Records or
Start Immediate Scavenging of Stale Resource Records.

Caution

By default, the aging and scavenging mechanism for the DNS Server service is disabled. It should
be enabled only when all parameters are fully understood. Otherwise, the server can be
accidentally configured to delete records that should not be deleted. If a record is accidentally
deleted, not only will users fail to resolve queries for that record, but any user can create a record
and take ownership of it, even on zones that are configured for secure dynamic update.
A server uses the contents of each resource-record-specific time stamp, along with other aging and
scavenging properties that you can adjust or configure, to determine when it scavenges records.

Prerequisites for aging and scavenging

Before you can use the aging and scavenging features of DNS, several conditions must be met:

1. Scavenging and aging must be enabled, both at the DNS server and on the zone.
By default, aging and scavenging of resource records is disabled.
2. Resource records must either be dynamically added to zones or manually modified to be used
in aging and scavenging operations.
Typically, only those resource records that are added dynamically using the DNS dynamic update
protocol are subject to aging and scavenging.
You can, however, enable scavenging for other resource records that are added through
nondynamic means. For records that are added to zones in this way, either by loading a text-based
zone file from another DNS server or by manually adding them to a zone, a time stamp of zero is
set. This makes these records ineligible for use in aging and scavenging operations.
To change this default, you can administer these records individually, to reset and permit them to
use a current (nonzero) time-stamp value. This makes it possible for these records to become aged
and scavenged.
For more information, see Reset Aging and Scavenging Properties for a Specified Resource Record .

Note

In the case of changing a zone from standard primary to Active Directory-integrated, you may
want to enable scavenging of all existing resource records in the zone. To enable aging for all
existing resource records in a zone, you can use the AgeAllRecords command, which is
available through the dnscmd command-line tool.

Aging and scavenging terminology

The following table indicates new or revised terms that have been introduced to help specifically when
discussing aging and scavenging.

Term Description
Resource A date and time value that is used by the DNS server to determine removal of the
record time resource record when it performs aging and scavenging operations.
stamp

Current The current date and time on the DNS server. This number can be expressed as
server time an exact numeric value at any point in time.

No-refresh An interval of time, determined for each zone, as bounded by the following two
interval events:

1. The date and time when the record was last refreshed and its time
stamp was set.
2. The date and time when the record next becomes eligible to be
refreshed and have its time stamp reset.

This value is needed to decrease the number of write operations to the Active
Directory database. By default, this interval is set to seven days. It should not be
increased to an unreasonably high level, because the benefits of the aging and
scavenging feature might either be lost or diminished.

Refresh An interval of time, determined for each zone, as bounded by the following two
interval distinct events:

1. The earliest date and time when the record becomes eligible to be
refreshed and have its time stamp reset.
2. The earliest date and time when the record becomes eligible to be
scavenged and removed from the zone database.

This value should be large enough to allow all clients to refresh their records. By
default, this interval is set to seven days. It should not be increased to an
unreasonably high level, because the benefits of the aging and scavenging
feature might either be lost or diminished.

Start A specific time, expressed as a number. This time is used by the server to
scavenging determine when a zone becomes available for scavenging.
time

Scavenging When automatic scavenging is enabled at the server, this period represents the
period time between repetitions of the automated scavenging process. The default value
for this is seven days. To prevent deterioration of DNS server performance, the
minimum allowed value for this is one hour.

Record When a DNS dynamic update is processed for a resource record when only the
refresh resource record time stamp, and no other characteristics of the record, are
revised.

Refreshes generally occur for the following reasons:

1. When a computer is restarted on the network and, if at startup, its name

and IP address information are consistent with the same name and address
information it used before being shut down, it sends a refresh to renew its
associated resource records for this information.
2. A periodic refresh is sent by the computer while it is running.
The Windows DNS Client service renews DNS registration of client resource
records every 24 hours. When this dynamic update occurs, if the dynamic
update request does not cause modification to the DNS database, it is
considered to be a refresh and not a resource record update.

3. Other network services make refresh attempts, such as: DHCP servers,
 which renew client address leases; cluster servers, which register and update
records for a cluster; and the Net Logon service, which can register and
update resource records that are used by Active Directory domain controllers.

Record When a DNS dynamic update is processed for a resource record where other
update characteristics of the record in addition to its time stamp are revised.

Updates generally occur for the following reasons:

1. When a new computer is added to the network and, at startup, it sends

an update to register its resource records for the first time with its configured
zone.
2. When a computer with existing records in the zone has a change in IP
address, causing updates to be sent for its revised name-to-address mappings
in DNS zone data.

3. When the Net Logon service registers a new Active Directory domain
controller.

Scavenging An optional advanced zone parameter that enables you to specify a restricted list
servers of IP addresses for DNS servers that are enabled to perform scavenging of the
zone.

By default, if this parameter is not specified, all DNS servers that load a directory-
integrated zone (also enabled for scavenging) attempt to perform scavenging of
the zone. In some cases, this parameter can be useful if it is preferable that
scavenging only be performed at some servers loading the directory-integrated
zone.

To set this parameter, you must specify the list of IP addresses for the servers
that are enabled to scavenge the zone in the ZoneResetScavengeServers
parameter for the zone. This can be done using the dnscmd command, a
command-line based tool for administering Windows DNS servers.

When scavenging can start

After all prerequisites for enabling the use of scavenging are met, it can start for a server zone when
the current server time is greater than the value of the start scavenging time for the zone.

The server sets the time value to start scavenging on a per-zone basis whenever one of the following
events occurs:

 Dynamic updates are enabled for the zone.

 A change in the state of the Scavenge stale resource records check box is applied. You
can use DNS Manager to modify this setting at either an applicable DNS server or one of its
primary zones.
 The DNS server loads a primary zone that is enabled to use scavenging.
This can occur when the server computer is started or when the DNS Server service is
started.
 When a zone resumes service after having been paused.
 If the zone is AD DS-integrated, replication for the zone must have taken place at least once
since the DNS service was restarted or the domain controller was rebooted. When the
previous events occur, the DNS server sets the value of start scavenging time by calculating
the following sum:
Current server time + Refresh interval = Start scavenging time
This value is used as a basis of comparison during scavenging operations.
Example: the aging and scavenging process for a sample record

To understand the process of aging and scavenging at the server, consider the life span and
successive stages of a single resource record, as it is added to a server and zone where this process is
in effect and then aged and removed from the database.

1. A sample DNS host, "host-a.example.microsoft.com", registers its host (A) resource record at
the DNS server for a zone where aging and scavenging are enabled for use.
2. When registering the record, the DNS server places a time stamp on this record based on
current server time.
After the record time stamp is written, the DNS server does not accept refreshes for this record for
the duration of the zone no-refresh interval. It can, however, accept updates before that time. For
example, if the IP address for "host-a.example.microsoft.com" changes, the DNS server can accept
the update. In this case, the server also updates (resets) the record time stamp.
3. Upon expiration of the no-refresh period, the server begins to accept attempts to refresh this
record.
When the initial no-refresh period ends, the refresh period immediately begins for the record.
During this time, the server does not suppress attempts to refresh the record for its remaining life
span.
4. During and after the refresh period, if the server receives a refresh for the record, it
processes it.
This resets the time stamp for the record based on the method that is described in step 2.
5. When subsequent scavenging is performed by the server for the "example.microsoft.com"
zone, the record (and all other zone records) are examined by the server.
Each record is compared to current server time on the basis of the following sum to determine
whether the record should be removed:
Record time stamp + No-refresh interval for zone + Refresh interval for zone
 If the value of this sum is greater than current server time, no action is taken and
the record continues to age in the zone.
 If the value of this sum is less than current server time, the record is deleted both
from any zone data currently loaded in server memory and also from the applicable
DnsZone object store in Active Directory Domain Services (AD DS) for the directory-
integrated "example.microsoft.com" zone.

Set Aging and Scavenging Properties for the DNS Server

The DNS Server service supports aging and scavenging features. These features are provided as a
mechanism for performing cleanup and removal of stale resource records, which can accumulate in
zone data over time. You can use this procedure to set the default aging and scavenging properties for
the zones on a server.

Membership in the Administrators group, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

Setting aging and scavenging properties for the DNS server

 Using the Windows interface

 Using a command line

To set aging and scavenging properties for the DNS server using the Windows interface
1. Open DNS Manager.
2. In the console tree, right-click the applicable DNS server, and then click Set
Aging/Scavenging for all zones.

3. Select the Scavenge stale resource records check box.

4. Modify other aging and scavenging properties as needed.

Additional considerations

 To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

 Aging and scavenging properties that are configured by this procedure act as server defaults
that apply only to Active Directory Domain Services (AD DS)–integrated zones. For standard
primary zones, you must set the appropriate properties at the applicable zone.
 When you apply changes for server aging and scavenging settings, DNS Manager prompts
you to confirm the changes. You then have the option to apply your changes to new AD DS-
integrated zones only. If necessary, you can also apply your changes to existing AD DS-
integrated zones.
 Regardless of whether the Scavenge stale resource records check box is selected as
described in step 3, for standard primary zones, this feature is disabled unless it is manually
enabled at the applicable zone.

To set aging and scavenging properties for the DNS server using a command line
1. Open a command prompt.

2. Type the following command, and then press ENTER:

Copy Code
dnscmd <ServerName> /Config {/ScavengingInterval
<Value>|/DefaultAgingState <Value>|/DefaultNoRefreshInterval
<Value>|/DefaultRefreshInterval <Value>}

Parameter Description

dnscmd The command-line tool for managing DNS servers.

<ServerName> Required. Specifies the DNS host name of the DNS server. You can
also type the IP address of the DNS server. To specify the DNS server
on the local computer, you can also type a period (.)

/Config Required. Configures the specified server.

/ScavengingInterval Required. Sets the frequency by which the server will perform
scavenging for all scavenging-enabled zones.

/DefaultAgingState Required. Sets the default aging configuration for all zones on the
server.

/ Required. Sets the default no-refresh interval for scavenging-enabled

DefaultNoRefreshInterval zones.

/DefaultRefreshInterval Sets the default refresh interval for scavenging-enabled zones.

<Value> For /ScavengingInterval, type a value in hours. The default is 168

(one week). For /DefaultAgingState, type 1 to enable aging for new
zones when they are created. Type 0 to disable aging for new zones.
 For /DefaultNoRefreshInterval, type a value in hours. The default is
168 (one week). For /DefaultRefreshInterval, type a value in hours.
The default is 168 (one week).

To view the complete syntax for this command, at a command prompt, type the following command,
and then press ENTER:

Copy Code
dnscmd /Config /help
Additional considerations

 To open an elevated Command Prompt window, click Start, point to All Programs, click
Accessories, right-click Command Prompt, and then click Run as administrator.

Checklist: Create an Alias (CNAME) Record

With alias (CNAME) resource records, you can use more than one name to point to a single computer.
For example, you can use an alias (CNAME) resource record to allow a server named
webserver.contoso.com to also be known as www.contoso.com.

Task Reference

Read about alias (CNAME) resource records. Adding Resource Records

Add alias (CNAME) resource records as Add an Alias (CNAME) Resource Record to a
needed. Zone

Adding Resource Records

After you create a zone, you must add additional resource records to it. The most common resource
records that you add include the following:

 Host (A) resource records: for mapping a Domain Name System (DNS) domain name to an
IP address that is used by a computer.
 Alias (CNAME) resource records: for mapping an alias DNS domain name to another
primary or canonical name.
 Mail exchanger (MX) resource records: for mapping a DNS domain name to the name of
a computer that exchanges or forwards mail.
 Pointer (PTR) resource records: for mapping a reverse DNS domain name that is based on
the IP address of a computer that points to the forward DNS domain name of that computer.
 Service location (SRV) resource records: for mapping a DNS domain name to a specified
list of DNS host computers that offer a specific type of service, such as Active Directory
domain controllers.
 Other resource records as needed.

Host (A) resource records

You use host (A) resource records in a zone to associate DNS domain names of computers (or hosts) to
their IP addresses. You can add them to a zone in several ways:

 You can manually create a host (A) resource record for a static TCP/IP client computer by
using DNS Manager.
 Windows clients and servers use the DHCP Client service to dynamically register and update
their own host (A) resource records in DNS when an IP configuration change occurs.
  Dynamic Host Configuration Protocol (DHCP)–enabled client computers running earlier
versions of Microsoft operating systems can have their host (A) resource records registered
and updated by proxy if they obtain their IP lease from a qualified DHCP server. (Only the
Windows 2000, Windows Server 2003, and Windows Server 2008 DHCP Server service
support this feature.)

Not all computers require the host (A) resource records, but computers that share resources on a
network need them. Any computer that shares resources and must be identified by its DNS domain
name must use host (A) resource records to provide DNS name resolution to the IP address for the
computer.

Most host (A) resource records that are required in a zone can include other workstations or servers
that share resources, other DNS servers, mail servers, and Web servers. These resource records make
up the majority of resource records in a zone database.

Alias (CNAME) resource records

Alias (CNAME) resource records are also sometimes called canonical name resource records. With
these records, you can use more than one name to point to a single host, which makes it easy to do
such things as host both a File Transfer Protocol (FTP) server and a Web server on the same computer.
For example, the well-known server names (ftp, www) are registered with alias (CNAME) resource
records that map to the DNS host name (such as server-1) for the server computer that hosts these
services.

We recommend alias (CNAME) resource records for the following scenarios:

 When a host that is specified in an host (A) resource record in the same zone must be
renamed
 When a generic name for a well-known server, such as www, must resolve to a group of
individual computers (each with individual host (A) resource records) that provide the same
service, for example, in a group of redundant Web servers.

When you rename a computer with an existing host (A) resource record in the zone, you can use an
alias (CNAME) resource record temporarily to allow a grace period for users and programs to switch
from the old computer name to the new one, as follows:

 For the new DNS domain name of the computer, add a new host (A) resource record to the
zone.
 For the old DNS domain name, add an alias (CNAME) resource record that points to the new
host (A) resource record.
 Remove the original host (A) resource record for the old DNS domain name (and its
associated pointer (PTR) resource record, if applicable) from the zone.

When you use an alias (CNAME) resource record for aliasing or renaming a computer, set a temporary
limit on how long the record is used in the zone before removing it from DNS. If you forget to delete
the alias (CNAME) resource record and later its associated host (A) resource record is deleted, the alias
(CNAME) resource record can waste server resources trying to resolve queries for a name that is no
longer used on the network.

The most common or popular use of an alias (CNAME) resource record is to provide a permanent DNS
aliased domain name for generic name resolution of a service-based name, such as
www.tailspintoys.com, to more than one computer or one IP address on a Web server. The following
example shows the basic syntax of an alias (CNAME) resource record:
alias_nameIN CNAMEprimary_canonical_name

In this example, a computer named host-a.tailspintoys.com functions as both a Web server named
www.tailspintoys.com. and as an FTP server named ftp.tailspintoys.com. To achieve the intended
objective of naming this computer, you can add the following CNAME entries in the tailspintoys.com
zone:

Copy Code
host-a IN A 10.0.0.20
ftp IN CNAME host-a
www IN CNAME host-a
If you later decide to move the FTP server to another computer—, separate from the Web server on
host-a—simply change the alias (CNAME) resource record in the zone for ftp.tailspintoys.com and add
an additional host (A) resource record to the zone for the new computer hosting the FTP server.

Based on the earlier example, if the new computer is named host-b.tailspintoys.com, the new and
revised host (A) and alias (CNAME) resource records appear as follows:

Copy Code
host-a IN A 10.0.0.20
host-b IN A 10.0.0.21
ftp IN CNAME host-b
www IN CNAME host-a

Mail exchanger (MX) resource records

E-mail applications use the mail exchanger (MX) resource record to locate a mail server based on a
DNS domain name in the destination address for the e-mail recipient of a message. For example, a
DNS query for the name example.tailspintoys.com can be used to find a mail exchanger (MX) resource
record, which makes it possible for an e-mail application to forward or exchange mail to a user with
the e-mail address user@tailspintoys.com.

The mail exchanger (MX) resource record shows the DNS domain name for the computer or computers
that process mail for a domain. If multiple mail exchanger (MX) resource records exist, the DNS Client
service attempts to contact mail servers in the order of preference from lowest value (highest priority)
to highest value (lowest priority). The following example shows the basic syntax of a mail exchanger
(MX) resource record:

mail_domain_nameIN MXpreferencemailserver_host

Using the mail exchanger (MX) resource records in the following example for tailspintoys.com zone,
mail that is addressed to user@tailspintoys.com is delivered to user@mailserver0.tailspintoys.com
first, if possible. If this server is unavailable, the resolver client can then use
user@mailserver1.tailspintoys.com instead.

Copy Code
@ IN MX 1 mailserver0
@ IN MX 2 mailserver1
Note that the use of the "at" sign (@) in the records indicates that the mailer DNS domain name is the
same as the name of origin (tailspintoys.com) for the zone.

Pointer (PTR) resource records

Pointer (PTR) resource records support the reverse lookup process, based on zones that are created
and rooted in the in-addr.arpa domain. These records locate a computer by its IP address and resolve
this information to the DNS domain name for that computer.

Pointer (PTR) resource records can be added to a zone in several ways:

 You can manually create a pointer (PTR) resource record for a static TCP/IP client computer
using DNS, either as a separate procedure or as part of the procedure for creating a host (A)
resource record.
 Computers use the DHCP Client service to dynamically register and update their pointer (PTR)
resource record in DNS when an IP configuration change occurs.
 All other Dynamic Host Configuration Protocol (DHCP)-enabled client computers can have
their pointer (PTR) resource records registered and updated by the DHCP server if they obtain
their IP lease from a qualified server. The Windows 2000, Windows Server 2003, and Windows
Server 2008 DHCP Server service provides this capability.

The pointer (PTR) resource record is used only in reverse lookup zones to support reverse lookup.

Service location (SRV) resource records

Service location (SRV) resource records are required for location of Active Directory domain
controllers. Typically, you can avoid manual administration of service location (SRV) resource records
when you install Active Directory Domain Services (AD DS).

By default, the Active Directory Domain Services Installation Wizard attempts to locate a DNS server
based on the list of preferred or alternate DNS servers, which are configured in any of its TCP/IP client
properties, for any of its active network connections. If a DNS server that can accept dynamic update
of the service location (SRV) resource record is contacted, the configuration process is complete. (This
is also true for other resource records that are related to registering AD DS as a service in DNS.)

If, during the installation, a DNS server that can accept updates for the DNS domain name that is used
to name your directory is not found, the wizard can install a DNS server locally and automatically
configure it with a zone to support the Active Directory domain.

For example, if the Active Directory domain that you choose for your first domain in the forest is
example.tailspintoys.com, you can add and configure a zone that is rooted at the DNS domain name of
example.tailspintoys.com to use with the DNS server that is running on the new domain controller.

In the future, the service location (SRV) resource record may also be used to register and look up other
well-known TCP/IP services on your network if applications implement and support DNS name queries
that specify this record type.

Add an Alias (CNAME) Resource Record to a Zone

Alias (CNAME) resource records are also sometimes called canonical name resource records. With
these records, you can use more than one name to point to a single host, making it easy to do such
things as host both a File Transfer Protocol (FTP) server and a Web server on the same computer. For
example, the well-known server names (ftp, www) are registered using alias (CNAME) resource records
that map to the Domain Name System (DNS) host name, such as server-1, for the server computer
that hosts these services.

Membership in the Administrators group, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

Adding an alias (CNAME) resource record to a zone

  Using the Windows interface

 Using a command line

To add an alias (CNAME) resource record to a zone using the Windows interface
1. Open DNS Manager.

2. In the console tree, right-click the applicable forward lookup zone, and then click New Alias.

3. In Alias name, type the alias name.

4. In Fully qualified domain name (FQDN) for target host, type the FQDN of the DNS host
computer for which this alias is to be used.

As an option, you can click Browse to search the DNS namespace for hosts in this domain that
have host (A) resource records already defined.

5. Click OK to add the new record to the zone.

Additional considerations

 To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To add an alias (CNAME) resource record to a zone using a command line

1. Open a command prompt.

2. Type the following command, and then press ENTER:

dnscmd <ServerName>/RecordAdd <ZoneName> <NodeName> [/Aging] [/OpenAcl] [<Ttl>]

CNAME <HostName>|<DomainName>

Copy Code

Parameter Description

dnscmd The command-line tool for managing DNS servers.

<ServerName> Required. Specifies the DNS host name of the DNS server. You
can also type the IP address of the DNS server. To specify the
DNS server on the local computer, you can also type a period (.)

/RecordAdd Required. Adds a new resource record.

<ZoneName> Required. Specifies the name of the zone where this alias
(CNAME) resource record will be added.

<NodeName> Required. Specifies the FQDN of the node in the DNS namespace.
You can also type the node name relative to the ZoneName or @,
which specifies the zone's root node.

/Aging Specifies that this resource record is aged and scavenged. If this
parameter is not used, the resource record remains in the DNS
database unless it is manually updated or removed.

/OpenAcl Specifies that new records are open to modification by any user.
Without this parameter, only administrators may modify the new
record.

<Ttl> Specifies the Time To Live (TTL) setting for the resource record.
 (The default TTL is defined in the start of authority (SOA)
resource record.)

CNAME Required. Specifies the resource record type of the record that
you are adding.

<HostName>| Required. Specifies the FQDN of any valid DNS host or domain
<DomainName> name in the namespace. For FQDNs, a trailing period (.) is used
to fully qualify the name.

Understanding Zone Types

The DNS Server service provides for three types of zones:

 Primary zone

 Secondary zone
 Stub zone

Note

If the DNS server is also an Active Directory Domain Services (AD DS) domain controller, primary
zones and stub zones can be stored in AD DS. See Understanding Active Directory Domain
Services Integration for more information.
The following sections describe each of these zone types.

Primary zone

When a zone that this DNS server hosts is a primary zone, the DNS server is the primary source for
information about this zone, and it stores the master copy of zone data in a local file or in AD DS.
When the zone is stored in a file, by default the primary zone file is named zone_name.dns and it is
located in the %windir%\System32\Dns folder on the server.

Secondary zone

When a zone that this DNS server hosts is a secondary zone, this DNS server is a secondary source for
information about this zone. The zone at this server must be obtained from another remote DNS server
computer that also hosts the zone. This DNS server must have network access to the remote DNS
server that supplies this server with updated information about the zone. Because a secondary zone is
merely a copy of a primary zone that is hosted on another server, it cannot be stored in AD DS.

Stub zone

When a zone that this DNS server hosts is a stub zone, this DNS server is a source only for information
about the authoritative name servers for this zone. The zone at this server must be obtained from
another DNS server that hosts the zone. This DNS server must have network access to the remote DNS
server to copy the authoritative name server information about the zone.

You can use stub zones to:

 Keep delegated zone information current. By updating a stub zone for one of its child zones
regularly, the DNS server that hosts both the parent zone and the stub zone will maintain a
current list of authoritative DNS servers for the child zone.
 Improve name resolution. Stub zones enable a DNS server to perform recursion using the
stub zone's list of name servers, without having to query the Internet or an internal root
server for the DNS namespace.
  Simplify DNS administration. By using stub zones throughout your DNS infrastructure, you can
distribute a list of the authoritative DNS servers for a zone without using secondary zones.
However, stub zones do not serve the same purpose as secondary zones, and they are not an
alternative for enhancing redundancy and load sharing.

There are two lists of DNS servers involved in the loading and maintenance of a stub zone:

 The list of master servers from which the DNS server loads and updates a stub zone. A
master server may be a primary or secondary DNS server for the zone. In both cases, it will
have a complete list of the DNS servers for the zone.
 The list of the authoritative DNS servers for a zone. This list is contained in the stub zone
using name server (NS) resource records.

When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the master servers,
which can be in different locations, for the necessary resource records of the authoritative servers for
the zone widgets.tailspintoys.com. The list of master servers may contain a single server or multiple
servers, and it can be changed anytime.

Enable DNS to Use WINS Resolution

The DNS Server service can use Windows Internet Name Service (WINS) servers to look up names that
are not found in the Domain Name System (DNS) domain namespace by checking the NetBIOS
namespace that is managed by WINS.

To use WINS lookup integration, two special resource record types—the WINS and
WINS-R resource records—are enabled and added to a zone. When the WINS
resource record is used, DNS queries that fail to find a matched host (A) resource
record in the zone are forwarded to WINS servers that are configured in the WINS
resource record. For reverse lookup zones, the WINS-R resource record can be
enabled and used to provide a similar benefit for further resolving a reverse query that
is not answerable in the reverse in-addr.arpa domain.

Note

As an alternative to using WINS for resolving single-label host names, you can configure DNS
client computers to use suffix search lists. You can also deploy a specially named zone, called
GlobalNames, to provide name resolution for a limited set of centrally managed host names. For
more information about these alternatives to WINS, see Understanding DNS Client Settings and
Deploying a GlobalNames Zone.
Membership in the Administrators group, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

To enable DNS to use WINS resolution

1. Open DNS Manager.

2. In the console tree, right-click the applicable zone, then click Properties.

3. Do one of the following:

 If the applicable zone is a forward lookup zone, on the WINS tab, select the Use
WINS forward lookup check box. In IP address, type the IP address of a WINS server to
be used for resolution of names that are not found in DNS, and then click Add.
  If the applicable zone is a reverse lookup zone, on the WINS-R tab, select the Use
WINS-R lookup check box. In Domain to append to returned name, type a name.
4. Select the Do not replicate this record check box for this WINS record, if applicable.

If you are replicating this zone between DNS servers that do not recognize the WINS or WINS-R
resource records, select this check box. This prevents these records from being replicated to these
other servers during zone transfers. If this zone will be used in performing zone transfers to BIND
servers, this is a critical option because Berkeley Internet Name Domain (BIND) will not recognize
WINS records.