In Windows 2000, DNS is required to use Active Directory.

Domain Name Service is used to change internet domain and computer computer names into IP
addresses and vice versa. DNS works at the application layer and uses TCP and UDP for
transport. TCP is only used if returned data is truncated. See the DNS section in the Networking
Guide for information about DNS. DNS was originally based on HOSTS files that were
maintained by a centralized Network Information Center. Today of is based on a hierarchy of
servers with a distributed hierarchial database throughout the network or internet.
DNS Levels
DNS is a hierarchial naming structure with the following levels:
• Root designated by a dot (.).
• First level - This indicates country or type of organization such as "org", "com", and
"net".
• Second level - Indicates the organization name and can be purchased for a yearly fee.
Notice that the highest level of the domain is listed last. An example of a domain name that you
may be familiar with is:
comptechdoc.org.
DNS Operation
DNS Servers
On the client side, a DNS resolver is used to send queries to DNS servers. The resolver is
normally part of a library routine or it is built into the application. DNS uses zone files to keep
name and IP address database information for the internet domain or hierarchial set of domains.
Zones are a storage of information in a file for a DNS domain or DNS subdomains (DNS
domains are not the same as Windows domains). DNS does not yet support dynamic
configuration but has been modified for Windows systems to do so. Different aliases may be
created by the administrator for the same host. Three types of name servers as defined by how it
relates to the zone information:
• Primary - Locally stored files exist on the name server data base. The master zone file
copy is stored here.
• Secondary - Gets data called a zone transfer from another server that is the zone
authority.
• Caching Only - Caches name server information and does not contain its own files.
A primary and secondary name server should be used on a network. When a zone is defined,
some server must be configured to be a master name server for the zone. There can be
different master name servers for different zones. The master server provides copies of the zone
information to the secondary DNS server. Name servers can be configured to get information
from other name servers when the information is not found in the local database. These types
are forwarders and slaves. Name servers as categorized by function:
• Master - The zone authority that contains the master zone files.
• Forwarders - A name server that passes name resolution requests to other name servers.
This configuration is done on a per server basis.
 • Slaves - Slave name servers are configured to use forwarders.
Windows introduces additional terminalogy:
• Standard primary - The same as a primary DNS server listed above. This is a master
server by function.
• Active Directory Integrated (primary) - DNS entries are stored with Active Directory
data rather than a normal zone file. More than one of these Active Directory primary
servers may exist due to Active directory replication. This term is used to refer to both
the Active Directory Integrated zones and files that support the zone.
• Standard secondary - The same as a secondary DNS server listed above. This is a slave
server by function.
• Root server - The server that has the DNS data for the root zone. The root zone is the
organization internal network root zone or internet root zone. It is used when a private
network is not directly on the internet (no connection or via proxy server).
If the DNS server is connected to the internet, the DNS Server Wizard will not allow the DNS
server to be configured as a root server.
Queries
Query types are:
• Inverse - Getting the name from the IP address. These are used by servers as a security
check.
• Iterative - Server gives its best answer. This type of inquiry is sent from one server to
another.
• Recursive - Cannot refer the query to another name server.
Zone Transfers
The DNS zone file serial number is used to trach DNS changes. The notify function is used to
initiate zone transfers. Zone transfer types are:
• Full - AXFR Query - Secondary server refresh interval expires and it sends an AXFR
qurey.
• Incremental - IXFR query - Only new or updated entries are copied.
DNS Zones
Possible zones include:
• Forward lookup zone - Name to IP address map.
• Reverse lookup zone - IP address to name map.
• Standard primary zone (primary zone) - A master copy of a forward or reverse lookup
zone.
• Active Directory integrated zone - A copy of a standard primary or Active Directory
integrated zone. The IP address and computer name is stored in Active Directory and
replicated to all local domain controllers. DNS information is not replicated to domain
controllers outside the domain.
• Standard secondary zone (secondary zone)
Microsoft DNS
Microsoft DNS is compatible with BIND, but it is not the same. Microsoft supports RFCs 1033,
1034, 1035, 1101, 1123, 1183, 1536, 2052, and 2136. RFC 1996 addresses DNS notify issues.
RFC 2065 defines DNS security extensions. Windows 2000 Server or more advanced server is
required to run DNS. It will not run on Windows 2000 Professional.
Windows 2000 DHCP clients register forward lookup entries (A record) by default. The DHCP
server registers forward (A) and reverse (PTR) DNS records.
Windows 2000 computers can register their IP address and names with the network DNS server
that supports dynamic updates (Not all DNS servers support dynamic updates, but Windows
2000 DNS servers do). Other operating systems other than Windows 2000 can not register their
IP address and names with DNS dynamically. A Windows DHCP server can be configured to
register assigned IP address and host names with the DNS server which can support dynamic
updates. Heres the procedure on the DHCP server:
1. Run the administrative tool, "DHCP" and highlight the DHCP server.
2. Select "Action" and "Properties".
3. Click the DNS tab.
4. Select the checkbox, "Enable updates for DNS clients that do not support dynamic
update". Select the "Always update DNS" checkbox to have the DHCP server update
DNS, even for Windows 2000 systems.
Installing DNS
1. Configure the computer to use a static IP address for each local area connection. In the
Control Panel use the "Network and Dial-Up Connections" applet, right click on "Local
Area Connections", select "Properties", "Internet Protocol (TCP/IP)", and set the IP
address.
2. Configure the computer to use a primary DNS suffix. Right click "My Computer", select
"Properties", click the "Properties" tab, click "more" in the "Identification Changes" box
and type the FQDN in the NETBIOS Computer Name and DNS Suffix boxes.
3. Install the DNS Server Service by putting the Windows 2000 appropriate Server install
CD in the CD-ROM drive, then open the "Add/Remove Programs" applet in the control
panel. In the Windows Components Wizard, highlight "Networking Services", click
"Details", check "DNS", and continue.
Configuring DNS
Configure DNS from the "DNS" selection of Administrative tools. Do the following:
1. Configure the DNS server to be its own client so it can resolve other computer names and
IP addresses. In the Control Panel use the "Network and Dial-Up Connections" applet,
right click on "Local Area Connections", select "Properties", "Internet Protocol
(TCP/IP)". Enter the IP address of the DNS server. for the preferred DNS server. Click
"Advanced and "DNS" tab in the "Advanced TCP/IP Settings" box. Type the FQDN of
the DNS server.
2. Configure a root server (if required) if internet access is not available or the connection is
through a proxy server. This is done from the "DNS" selection of "Administrative Tools".
Highlight the computer, then select "Action", and "Configure the Server".
3. To configure properties perform the same action as in the item above, but select
"Properties" after the "Action" selection. Here the Interfaces (network cards) that will
provide the DNS service can be set or limited. Also IP addresses that are allowed service
can be set. Advanced Options include:
○ DNS process recursion can be enabled or disabled. - This means the processes of
trying to satisfy a query is repeated until a solution is found. This is enabled by
default causing DNS servers to contact other servers to resolve queries.
○ BIND secondaries - Zones are transferred to secondary servers from master
servers. Enabled by default
○ Fail on load if bad zone data - A zone with bad data is not used. This is not
enabled by default.
○ Enable round robin - Used to balance loads when multiple servers have the same
name and configuration with different IP addresses. A different IP address can be
provided to clients when the host name is requested.
○ Enable netmask ordering - This is for hosts with multiple network cards and is
resolved with the address that is on the same subnet of the client. This option is
selected by default and if it is not selected, round robin policy is used.
○ Secure cache against pollution - Normally all DNS server information due to
queries is cached for further use. This option only allows the final answer to be
cached.
○ Name Checking - The options are Strict RFC (ANSI), Non-RFC (ANSI), and
Multibyte (UTF8). Multibyte is the default.
○ Load zone data on startup - Determines where data is loaded when the DNS
service starts. It can be from Active Directory and registry, from file, or from the
registry.
○ Enable automatic scavenging of stale records - Old resource records on zones may
be deleted if older than a set amount of time.
The root hints tab is used to associate internet or the organizations root servers names and
IP addresses. Root hints is not configurable on a root server.
4. To configure other properties select "Start", "Administrative Tools", "DNS", click the
plus by the DNS server name, then click + next to the Forward or Reverse Lookup Zones.
Highlight the zone to configure and select "Action" and "Properties". Tabs include:
○ General - Set zone file name and allow or not allow dynamic updates. Set whether
stale resource records are scavenged, no-refresh interval time, and refresh interval
time. This allows old records in the zone to be deleted. The refresh interval is the
amount of time to wait before scavenging the record.
○ Start of Authority (SOA)
○ Name Servers
○ WINS - Configure DNS to use WINS.
○ Zone Transfers - Sets the servers the Active Directory DNS Zone transfers are
sent to.
Configuring Zones
This is done from the "DNS" selection of "Administrative Tools". Click the + next to the DNS
server name, Highlight the "Forward Lookup Zones (or "Reverse Lookup Zones") folder, then
select "Action", and "New Zone".
The Start of Authority (SOA) record defines the authoritative server for the DNS zone. SOA
properties are:
• Serial number - If less than master's SN, the slave will get a new copy of this file from
the master.
• Primary server
• Responsible person
• Refresh interval - The time in seconds between when the slave compares this file's SN
with the master.
• Retry Interval - The time the server should wait before asking again if the master fails to
respond to a file update (SOA request).
• Expires after - Time in seconds the slave server can respond even though it cannot get
an updated zone file. Needs to be longer than the refresh interval.
• Minimum TTL - The time to live (TTL) in seconds that a resolver will use data that was
received from a nameserver before it will ask for the same data again.
Monitoring DNS
Select "Start", "Programs", "Administrative Tools", "DNS". Highlight the DNS server name,
select "Action", "Properties" and click the Monitoring tab. Tabs include:
• Interfaces
• Forwarders
• Advanced
• Root Hints
• Logging - Used to set logging options to be sent to the file
SystemRoot\system32\dns\dns.log. Options representing DNS events are Query, Notify,
Update, Questions, Answers, Send, Receive, UDP, TCP, Full packets, and Write through.
• Monitoring - Select and perform tests such as a simple query to this DNS server or a
recursive query to another DNS server.
The event log will also show and DNS problems. The "Event Viewer" is an administrative tool.
Zone Properties Dialog Box
Tabs:
• General - Sections:
○ Status - The status is indicated and a "Pause" button allows DNS to be paused.
○ Zone type - Has a "Change" button that allows setting the zone type to one of
standard primary, standard secondary, and Active Directory integrated.
○ Allow dynamic updates - Updates can be allowed from DHCP servers.
 • Start of Authority (SOA) - Correspond to the SOA properties listed above.
○ Serial number
○ Primary server
○ Responsible person
○ Refresh interval
○ Retry interval
○ Expires after
○ Minimum (default) TTL
○ TTL for this record - Defines the TTL for the SOA record.
• Name Servers
• WINS - Controls whether WINS is used to resolve names in this zone.
• Zone Transfers - Determines how requests for zone transfers from other servers are
handled. These are the choices:
○ No zone transfers.
○ Allow zone transfers only to specified servers listed in this tab.
○ Allow zone transfers to servers listed in the name servers tab only.
○ Allow zone transfers to any server.
• Security
Configuring DNS
Characters allowed in DNS names are:
A-Z a-z 0-9 -
The characters / . _ are illegal. Configuration keywords:
• Interfaces - Specifies interfaces to use on a multihomed host.
• Forwarders - Specifies other name servers to use as a forwarder.
• Boot Method - Display whether the boot method is through the use of the registry or data
files.
DNS files are stored in:
\WINNTROOT\System32\DNS
Hosts File
The Hosts file at \SystemRoot\system32\drivers\etc can act as a replacement for DNS which is
a file containing IP addresses and DNS names for hosts. Files in this directory include:
• Hosts
• Protocol
• Lmhosts - NetBIOS name to IP address.
DNS Tools
 • NSLOOKUP - It is run from the command prompt. Syntax:
nslookup [-options] [searchname] [-server]
To see options, "Help" can be typed at the NSLOOKUP command prompt .

This is Google's cache of http://technet.microsoft.com/en-us/library/cc759550(WS.10).aspx. It is a

snapshot of the page as it appeared on 7 Dec 2010 21:18:03 GMT. The current page could have changed
in the meantime. Learn more

Text-only version
These search terms are highlighted: dns integrated active directory stores

Top of Form
/w EPDw UBMGRk

How DNS Support for Active Directory Works

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1,
Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2
How DNS Support for Active Directory Works
In this section
• DNS Support for Active Directory Architecture

• DNS Physical Structure in Support of Active Directory

• DNS Support for Active Directory Processes and Interactions

• Network Ports Used by DNS in Support of Active Directory

• Related Information

Active Directory uses DNS as its domain controller location mechanism and leverages the
namespace design of DNS in the design of Active Directory domain names. As a result, DNS is
positioned within the discoverability and logical structure components of Active Directory
technology components.
Note
In Windows 2000 Server and Windows Server 2003, the directory service is named
Active Directory. In Windows Server 2008 and Windows Server 2008 R2, the
directory service is named Active Directory Domain Services (AD DS). The rest of
this topic refers to Active Directory, but the information is also applicable to
Active Directory Domain Services.

Typically, a Windows Server 2003 and later DNS namespace is deployed to mirror an Active
Directory forest and domain infrastructure. In such a deployment, a partition of the DNS
namespace is set aside for Active Directory, where a DNS domain name such as
corp.contoso.com is used support the Active Directory forest root domain, and then subdomains
of this name are created to suit additional Active Directory domains as needed.
DNS Support for Active Directory Architecture
Active Directory is dependent on DNS as a domain controller location mechanism and uses
DNS domain naming conventions in the architecture of Active Directory domains. There are
three components in the dependency of Active Directory on DNS:
• Domain controller locator (Locator)

• Active Directory domain names in DNS

• Active Directory DNS objects

DNS Support for Active Directory Components

Component Description

The Windows Server 2003 or later domain controller locator, implemented in

Domain
the Net Logon service, enables a client to locate a domain controller. The
controller
component contains the DNS–compatible and the Windows NT 4.0–compatible
locator
locators that provide interoperability in a mixed Windows Server 2003 or later –
(Locator)
and Windows NT 4.0–based environment.

Active Every Windows Server 2003 or later Active Directory domain has a DNS
Directory domain name (for example, contoso.com), and every Windows Server 2003 or
domain names later based computer has a DNS name (for example, win2kserver.contoso.com).
in DNS Architecturally, domains and computers are represented both as objects in
Active Directory and as nodes in DNS.
Because DNS domains and Active Directory domains share identical domain
names, it is easy to confuse their roles. The two namespaces, although typically
sharing an identical domain structure, store different data and, therefore, manage
different objects:
• DNS stores zones and resource records, and Active
Directory stores domains and domain objects. Both systems
use a database to resolve names.

• DNS resolves domain names and computer names to resource

 records through requests received by DNS servers as DNS
queries to the DNS database.

• Active Directory resolves domain object names to object

records through requests that are received by domain
controllers either as LDAP search requests or as modify
requests to the Active Directory database.

Thus, the Active Directory domain computer account object is in a different

namespace from the DNS host record that represents the same computer in the
DNS zone.

When DNS data is stored in Active Directory, each DNS zone is an Active
Directory container object (class dnsZone). The dnsZone object contains a
DNS node object (class dnsNode) for every unique name within that zone.
These unique names include the variations assigned to a specific host computer
Active when it functions, for example, as a primary domain controller or as a global
Directory DNS catalog server. The dnsNode object has a dnsRecord multivalue attribute that
objects contains a value for every resource record that is associated with an object’s
name.
For more information about Active Directory DNS objects, see How DNS
Works.

Active Directory and DNS Domain Names

Active Directory domains have two types of names: DNS names and NetBIOS names. In
general, both names are visible to end users. The DNS names of Active Directory domains
include two parts, a prefix and a suffix. The DNS prefix is the first label in the DNS name of the
domain. The suffix is the name of the Active Directory forest root domain.
When a Windows NT 4.0 master user domain (MUD) is upgraded, the decision is made whether
or not to use the current NetBIOS name of the domain as a DNS prefix. If the name is
appropriate to represent the organizational structure of the enterprise and satisfies the prefix
naming rules in the table below, the name is typically kept. In this case, the NetBIOS name of
the domain is the same as the DNS prefix of the domain.
Registered DNS Name Prefix Rules

Rule Explanation

Avoid names such as a business line or operating system that

Select a prefix that is not likely
might change in the future. Geographical names are
to become outdated.
recommended.

Select a prefix that includes

Internet standard characters A-Z, a-z, 0-9, and (-), but not entirely numeric.
only.

Include 15 characters or less in If you choose a prefix length of 15 characters or less, then the
the prefix. NetBIOS name is the same as the prefix.

If the current NetBIOS name of the domain is inappropriate to represent the organizational
structure of the enterprise or if the current name fails to satisfy the prefix naming rules, a new
prefix is used. In this case, the NetBIOS name of the domain will be different from the DNS
prefix of the domain.
For each new Active Directory domain, a prefix that is appropriate for the organizational
structure of the enterprise and that satisfies prefix naming rules is used. Typically, the NetBIOS
name of the domain will be the same as the name of the DNS prefix.
The Active Directory forest root domain is also the name of the Active Directory forest. The
forest root name is a DNS name that consists of a prefix and a suffix in the form of prefix.suffix.
For example, an organization might have the forest root name corp.contoso.com. In this example,
corp is the prefix and contoso.com is the suffix.
The suffix is selected from a list of existing DNS names on the network. For the prefix, a new
name that has not been used on the network previously is selected. By attaching a new prefix to
an existing suffix, a unique namespace is created. Creating a new namespace for Active
Directory ensures that any existing DNS infrastructure does not need to be modified to
accommodate Active Directory.
Typically, the DNS names that are used in the Active Directory namespace are registered with
an Internet authority. Only registered names are guaranteed to be globally unique. If two
organizations register the same DNS domain name, or if an organization merges with, acquires,
or is acquired by another company that uses the same DNS name, then the two infrastructures
cannot interact with one another.
Note
• Using unregistered suffixes is not recommended. Using single label names,
such as .local, is not supported.

DNS Physical Structure in Support of Active Directory

The physical structure of Active Directory information in DNS is represented in DNS zones and
resource records, which, in turn, are typically stored in Active Directory as Active Directory–
integrated DNS zones. The DNS zones that support Active Directory domains can also be
stored in standard, file-based, DNS zones. In addition, the DNS dynamic update protocol is
utilized by Active Directory in order to make the registration of domain controller DNS
resource records automatic.
The following diagram illustrates the physical storage of Active Directory domain information
in DNS zones hosted on domain controllers, and in standard DNS zones hosted on member
servers.
DNS Physical Structure in Support of Active Directory

The following table describes the physical components in the Active Directory/DNS physical
structure.
DNS Physical Structure in Support of Active Directory Components

Active
Directory/DNS
Description
Physical Structure
Component

The DNS server used to support Active Directory must support the
Active Directory/DNS SRV resource record and, ideally, the DNS dynamic update protocol. If
physical structure the DNS server does not support the DNS dynamic update protocol, the
requirements SRV resource records required to locate Active Directory domain
controllers can be added to DNS manually.

The Microsoft-specific subdomain enables location of domain

controllers that have specific roles in the Active Directory domain or
_msdcs DNS subdomain forest. Resource records for the DNS root domain of a new Active
Directory forest are stored in a _msdcs zone instead of a subdomain,
and that zone is stored in the forest-wide application directory partition.

Domain controller SRV

There are multiple DNS SRV resource records registered on behalf of
resource records
domain controllers. A description of each resource record is below.
registered in DNS

In Windows Server 2003 and later, the Active Directory–integrated

DNS zones that support Active Directory domains can be stored in
DNS application
Active Directory application directory partitions. By default, the DNS
directory partitions
root domain of a new Active Directory forest is stored in the domain-
wide application directory partition for the forest root domain.

DNS Support for Active Directory Physical Structure Requirements

In order for a DNS server to be able to support Active Directory, the server is required to
support the service (SRV) resource record type and the dynamic update protocol, as described in
the RFC 2136. Active Directory uses DNS as the location mechanism for domain controllers,
enabling computers on the network to obtain IP addresses of domain controllers. During the
installation of Active Directory, the service (SRV) and address (A) resource records are
dynamically registered in DNS. Both types of records are necessary for the functionality of the
domain controller locator (Locator) mechanism.
To find domain controllers in a domain or forest, a client queries DNS for the SRV and A DNS
resource records of the domain controller. The resource records provide the client with the names
and IP addresses of the domain controllers. In this context, the SRV and A resource records are
referred to as Locator DNS resource records.
When a domain controller is added to a forest, a DNS zone hosted on a DNS server is updated
with the Locator DNS resource records for that domain controller. For this reason, the DNS zone
must allow dynamic updates (RFC 2136), and the DNS server hosting that zone must support the
SRV resource records (RFC 2782) to advertise the Active Directory directory service.
At the very least, the DNS server must support the SRV resource record; but the SRV resource
records can be added to DNS manually. After installing Active Directory, these records can be
found on the domain controller in the following location:
systemroot\System32\Config\Netlogon.dns.
Note
• The configuration of reverse lookup zones is not based on the Windows
Server 2003 and later domain structure; instead, it is based on the range of
IP addresses assigned to a company. If a company is assigned B class IP
addresses such as 172.56.X.Y., then a reverse lookup zone of 56.172.in-
addr.arpa. will be created. It might contain delegations to some other
domains such as 1.56.172.in-addr.arpa., 2.56.172.in-addr.arpa., etc. It is also
possible to configure classless reverse lookup zones as described in the RFC
Best Current Practice paper “Classless IN_ADDR.ARPA delegation.”

_msdcs Subdomain
To facilitate locating Windows Server 2003 or later based domain controllers, in addition to the
standard _Service._Protocol.DnsDomainName format, the Net Logon service registers SRV
records that identify the well-known server-type pseudonyms “dc” (domain controller), gc
(global catalog), pdc (primary domain controller), and “domains” (globally unique identifier, or
GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain enables
location of domain controllers that have Windows Server 2003 or laterspecific roles in the
domain or forest, as well as the location by GUID when a domain has been renamed. To
accommodate locating domain controllers by server type or by GUID (abbreviated “dctype”),
Windows Server 2003 and later based domain controllers register SRV records in the following
form:
_Service._Protocol.DcType. _msdcs. DnsDomainName
Note
• There are also site–specific DNS resource records that use a slightly different
format. For more information about site discovery, see “Domain Controller
Location in the Closest Site” later in this document.

The subdomain _msdcs.DnsDomainName is used to find an LDAP server that is running TCP
and also functioning in a particular Windows Server role. The name _msdcsis reserved for
locating domain controllers and Kerberos servers. The single keyword _msdcswas chosen to
avoid cluttering the DNS namespace unnecessarily. Other constant, well-known names (pdc, dc,
and gc) were kept short to avoid exceeding the maximum length allowed for a DNS name.
Domain Controller SRV Resource Records
When a Windows Server 2003 or later based domain controller starts up, the Net Logon service
uses dynamic updates to register SRV and A resource records in the DNS database, as described
in Internet Engineering Task Force (IETF) RFC 2782, “A DNS RR for specifying the location of
services (DNS SRV).” Windows Server 2003 also uses secure dynamic update using the GSS-
TSIG algorithm, as described in RFC 3645, “Generic Security Service Algorithm for Secret Key
Transaction Authentication for DNS (GSS-TSIG).”
The SRV record is used to map the name of a service (in this case, the LDAP service) to the
DNS computer name of a server that offers that service. In a Windows Server 2003 network, an
LDAP resource record locates a domain controller.
When a workstation logs on to a Windows Server 2003 or later domain, it queries DNS for SRV
records in this general form:
_Service ._ Protocol . DnsDomainName
Because Active Directory servers offer the LDAP service over the TCP protocol, clients find an
LDAP server by querying DNS for a record of the form:
_ldap._tcp. DnsDomainName
Note
• The service and protocol strings require an underscore (_) prefix to prevent
potential collisions with existing names in the namespace.

Active Directory site-specific resource records are also used during logon. For more
information, see “Domain Controller Location in the Closest Site” later in this document.
SRV Records Registered by Net Logon
The list in the following table provides the definitions of the names associated with registered
SRV records. It also describes the lookup criteria supported by each record and the checks
performed by Net Logon as each record is registered.
In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain name
that is used during creation of the domain controller when the domain tree is joined or created
(that is, when the computer runs the Active Directory Installation Wizard). DnsForestName
refers to the DNS domain name of the forest root domain.
An owner name is the name of the DNS node to which a resource record pertains. These resource
records are used by domain controller Locator. The following table lists the owner names of the
SRV records that are registered by Net Logon.
SRV Records That Are Registered by Net Logon

SRV Resource Record Description

Enables a client to locate a server that is running the LDAP

service in the domain named DnsDomainName. The server
is not necessarily a domain controller — that is, the only
assumption that can be made about the server is that it
_ldap._tcp. DnsDomainName .
supports the LDAP application programming interface
(API). All Windows Server 2003–based domain controllers
register this SRV record (for example,
_ldap._tcp.contoso.com.).

_ldap._tcp. SiteName . _sites. Enables a client to locate a server that is running the LDAP
DnsDomainName . service in the domain named DnsDomainName in the site
named SiteName. SiteName is the relative distinguished
name of the site object that is stored in the Configuration
 container in Active Directory. All Windows Server 2003
and later based domain controllers register this SRV record
(for example, _ldap._tcp.charlotte._sites.contoso.com.).

Enables a client to locate a domain controller (dc) of the

_ldap._tcp.dc._msdcs.
domain named DnsDomainName. All Windows Server 2003
DnsDomainName .
and later based domain controllers register this SRV record.

Enables a client to locate a domain controller for the domain

_ldap._tcp. SiteName .
named DnsDomainName and in the site named SiteName.
_sites.dc._msdcs. DnsDomainName
All Windows Server 2003 and laterbased domain controllers
.
register this SRV record.

Enables a client to locate the server that is acting as the

primary domain controller (PDC) in the mixed-mode
domain named DnsDomainName. Only the PDC emulator
_ldap._tcp.pdc._msdcs.
master of the domain (the Windows Server 2003 and
DnsDomainName .
laterbased domain controller that advertises itself as the
primary domain controller to computers that need a primary
domain controller) registers this SRV record.

Enables a client to locate a global catalog (gc) server for this

forest. Only domain controllers that are functioning as gc
_ldap._tcp.gc._msdcs.
servers for the forest named in DnsForestName register this
DnsForestName .
SRV record (for example,
_ldap._tcp.gc._msdcs.contoso.com.).

Enables a client to locate a global catalog (gc) server for this

forest in the site named in SiteName. Only domain
_ldap._tcp. SiteName . controllers that are serving as gc servers for the forest
_sites.gc._msdcs. DnsForestName . named in DnsForestName register this SRV record (for
example,
_ldap._tcp.charlotte._sites.gc._msdcs.contoso.com.).

Enables a client to locate a global catalog (gc) server for this

domain. The server is not necessarily a domain controller.
Only a server that is running the LDAP service and
functioning as the GC server for the forest named
DnsForestName registers this SRV record (for example,
_gc._tcp.DnsForestName.
_gc._tcp.contoso.com.). In Windows Server 2003 and later,
a GC server is a domain controller. Other implementations
of directory services (that are not Windows Server 2003 or
later implementations) can also register servers as GC
servers.

_gc._tcp.SiteName. Enables a client to locate a global catalog (gc) server for this
_sites.DnsForestName. forest in the site named SiteName. The server is not
necessarily a domain controller. Only a server that is
running the LDAP service and functioning as the GC server
 for the forest named DnsForestName registers this SRV
record (for example, _gc._tcp.charlotte._sites.contoso.com.).

Enables a client to locate a domain controller in a domain on

the basis of its GUID. A GUID is a 128-bit number that is
automatically generated for referencing objects in Active
Directory — in this case, the domain object. This operation
_ldap._tcp. DomainGuid . is expected to be infrequent; it occurs only when the
domains._msdcs. DnsForestName . DnsDomainName of the domain has changed, the
DnsForestName is known, and DnsForestName has not also
been renamed (for example, _ldap._tcp.4f904480-7c78-
11cf-b057-00aa006b4f8f.domains. _msdcs.contoso.com.).
All domain controllers register this SRV record.

Enables a client to locate a server that is running the

Kerberos KDC service for the domain that is named in
DnsDomainName. The server is not necessarily a domain
_kerberos._tcp. DnsDomainName .
controller. All Windows Server 2003 and later based
domain controllers that are running an RFC 1510–compliant
Kerberos KDC service register this SRV record.

_kerberos._udp. DnsDomainName Same as _kerberos._tcp.DnsDomainName, except that

. UDP is implied.

Enables a client to locate a server that is running the

Kerberos KDC service for the domain that is named
DnsDomainName and is also in the site named SiteName.
_kerberos._tcp. SiteName . _sites.
The server is not necessarily a domain controller. All
DnsDomainName .
Windows Server 2003 and later based domain controllers
that are running an RFC 1510–compliant Kerberos KDC
service register this SRV record.

Enables a client to locate a domain controller that is running

_kerberos._tcp.dc._msdcs.
DnsDomainName .
the Windows Server 2003 or later implementation of the
Kerberos KDC service for the domain named in
DnsDomainName. All Windows Server 2003 and later
based domain controllers that are running the KDC service
(that is, that implement a public key extension to the
Kerberos v5 protocol Authentication Service Exchange
subprotocol) register this SRV record.

_kerberos.tcp. SiteName . Enables a client to locate a domain controller that is running

_sites.dc._msdcs. DnsDomainName the Windows Server 2003 implementation of the Kerberos
. KDC service for the domain that is named
DnsDomainName and that is also in the site named
SiteName. All Windows Server 2003 and later based domain
controllers that are running the KDC service (that is, that
implement a public key extension to the Kerberos v5
 protocol Authentication Service Exchange subprotocol)
register this SRV record.

Enables a client to locate a Kerberos Password Change

server for the domain. All servers that provide the Kerberos
Password Change service (which includes all Windows
Server 2003 and later based domain controllers) register this
name. This server must at least conform to the Kerberos
_kpasswd._tcp.DnsDomainName. Change Password Protocol. (For more information about
this draft, see the Microsoft Platform SDK.) The server is
not necessarily a domain controller. All Windows
Server 2003 and later based domain controllers that are
running an RFC 1510–compliant Kerberos KDC service
register this SRV record.

Same as _kpasswd._tcp.DnsDomainName, except that UDP

_kpasswd._udp.DnsDomainName.
is implied.

In addition to the SRV records listed in the table above, Net Logon also registers a DNS alias
(CNAME) record for use by Active Directory replication, in the format:
DsaGuid._msdcs.DnsForestName. The Locator does not use this record. This record enables a
client to locate any domain controller in the forest by looking up an A record. The only
information that is known about the domain controller is the GUID of the directory system
agent (DSA) object for the domain controller and the name of the forest in which the domain
controller is located. This record is used to facilitate renaming a domain controller.
If multiple domain controllers have the same criteria, multiple records exist with the same owner
name. A client that is looking for a domain controller with specific criteria would receive all the
applicable records from the DNS server. The client would pick one of the returned records to
select a domain controller, as described in RFC 2782.
Other SRV Record Content
The following information is also included in an SRV record.

SRV
Record Description
Field

The priority of the server. Clients attempt to contact the server with the lowest
Priority
priority.

A load-balancing mechanism that is used when selecting a target host from those that
Weight have the same priority. Clients randomly choose SRV records that specify target hosts
to be contacted, with probability proportional to the weight.

Port
The port where the server is listening for this service.
number
Target The fully qualified domain name of the host computer.

The algorithm by which clients interpret and select among SRV resource records is defined in
RFC 2782, “A DNS RR for specifying the location of services (DNS SRV).”
Host Records for Non-SRV-Aware Clients
Net Logon registers the following DNS A records for the use of LDAP clients that do not
support DNS SRV records (that is, clients that are non-SRV-aware). Locator does not use these
records.
Host (A) Records Registered by Net Logon

Host (A)
Resource Description
Record

Enables a non-SRV-aware client to locate any domain controller in the

domain by looking up an A record. A name in this form is returned to the
DnsDomainName . LDAP client through an LDAP referral. A non-SRV-aware client looks up
the name; an SRV-aware client looks up the appropriate SRV resource
record.

Enables a non-SRV-aware client to locate any global catalog server in the

forest by looking up an A record. A name in this form is returned to the
gc._msdcs.
LDAP client through an LDAP referral. A non-SRV-aware client looks up
DnsForestName .
this name; an SRV-aware client looks up the appropriate SRV resource
record.

Example of Registered Resource Records

The following example illustrates the combined information that is contained in A resource
records and SRV resource records.
A domain controller named Phoenix in the domain contoso.com has an IP address of
157.55.81.157. It registers the following A records and SRV records with DNS:
phoenix.contoso.com A 157.55.81.157
_ldap._tcp.contoso.com SRV 0 0 389 phoenix.contoso.com
_kerberos._tcp.contoso.com SRV 0 0 88 phoenix.contoso.com
_ldap._tcp.dc._msdcs.contoso.com SRV 0 0 389 phoenix.contoso.com
_kerberos._tcp.dc._msdcs.contoso.com SRV 0 0 88 phoenix.contoso.com.
When the appropriate SRV records and A records are in place, a DNS query for
_ldap._tcp.dc._msdcs.contoso.com returns the names and addresses of all domain controllers in
the domain.
For more information about A records, SRV records, DNS, and dynamic updates, see “DNS
Protocol” and “DNS Physical Structure” in How DNS Works.
DNS Application Directory Partitions
DNS zones stored in Active Directory replicate to Active Directory domain controllers
according to different replication scopes. In Windows 2000 Server, a DNS zone stored in Active
Directory is replicated to all domain controllers in the Active Directory domain. Windows
Server 2003 and later have added application directory partitions, which enable the DNS zone to
be stored in different replication scopes. The following table describes all of the replication
scopes available to a DNS zone stored in Active Directory.
Windows Server 2003 and later Active Directory Storage Options

Active
Directory Replication Scope
Storage Option

Active Directory domain partition for each domain in the forest. DNS zones
stored in this partition are replicated to all domain controllers in the domain.
Domain partition
This is the only Active Directory storage option for DNS zones that are
replicated to domain controllers running Windows 2000 Server.

DNS application directory partition for the entire forest. DNS zones stored in
Forest-wide DNS this application directory partition are replicated to all DNS servers running
application on domain controllers in the forest. This DNS application directory partition
directory partition is created when you install the DNS Server service on the first Windows
Server 2003 or later domain controller in the forest.

DNS application directory partition for each domain in the forest. DNS
zones stored in this application directory partition are replicated to all DNS
servers running on domain controllers in the domain. For the forest root
Domain-wide DNS domain, this DNS application directory partition is created when you first
application install the DNS Server service on a Windows Server 2003 or later domain
directory partition controller in the forest.
For each new domain in the forest (child domain), this DNS application
directory partition is created when you first install the DNS Server service
on a Windows Server 2003 or later domain controller for the new domain.

DNS application directory partition for any domain controller that is enlisted
Custom DNS in its replication scope. This type of DNS application directory partition does
application not exist by default and must be created. DNS zones stored in this application
directory partition directory partition are replicated to all DNS servers running on domain
controller that enlist in the partition.

As stated earlier, the Locator DNS resource records for an Active Directory domain are stored
in the _msdcs.DnsDomainName subdomain for the Active Directory domain. In Windows
Server 2003 or later, when the DNS root domain of a new Active Directory forest is created on
a Windows Server 2003 or later domain controller, a DNS zone is automatically created for the
_msdcs.DnsForestName and stored in the forest-wide DNS application directory partition,
which replicates to all Windows Server 2003 and later domain controllers in the forest running
the DNS Server service.
Note
• DNS zones stored in application directory partitions cannot be accessed by
Windows 2000 Server domain controllers.

DNS Support for Active Directory Processes and

Interactions
When a Windows Server 2003 or later member server is promoted to an Active Directory
domain controller by installing Active Directory, the Net Logon service registers the DNS
resource records necessary for network hosts and services to be able to locate the domain
controller on the network. When network hosts and services attempt to perform an operation
(such as joining a domain, for example) that requires an Active Directory domain controller, the
Locator mechanism is used to locate the domain controller through DNS. The following table
describes the processes and interactions involved in the registration and location of domain
controllers in DNS.
Active Directory and DNS Processes and Interactions

Process or
Description
Interaction

Domain controller The Net Logon service registers DNS resource records on behalf of the
DNS name Active Directory domain controller in the DNS zone with the same name as
registration the Active Directory domain hosted by the domain controller.

DNS delegation resource records are created in the zone that is a parent of
the zone supporting the Active Directory domain. The delegation enables
the DNS name of the domain controller to be resolved downward from the
DNS delegation, root of the DNS hierarchy.
forwarders
DNS forwarders are another DNS feature that enable domain controller
location, and are commonly used for an Active Directory client in one
domain to locate a domain controller in another domain.

DNS domain Network hosts and services use the DNS Locator mechanism to locate
controller location domain controllers in the Active Directory forest.

Domain Controller Name Registration

Every Windows Server 2003 or laterbased domain controller registers two types of names at
startup:
• A DNS domain name with the DNS service (for example, noam.contoso.com).

• A NetBIOS name with Windows Internet Name Service (WINS) or another

transport-specific service (for example, noam).

When a user starts a computer and logs on to a domain, the computer must do one of two things:
 • If the name of the logon domain is a DNS name, the computer must query
DNS to find a domain controller with which to authenticate.

• If the name of the logon domain is a NetBIOS name, the computer must send
a mailslot message to find a domain controller for the specified domain.

After the computer has found a domain controller, the information is cached so that a new query
is not required for subsequent logon sessions.
DNS Domain Name Registration
Active Directory supports dynamic registration of domain controller addresses in DNS. After
Active Directory has been installed during domain controller creation, the Net Logon service
dynamically creates records in the DNS database that are used to locate the server. Dynamic
update (described in RFC 2136) is a recent addition to the DNS standard; this addition to the
standard defines a protocol for dynamically updating a DNS server with new or changed
resource record values. Before the advent of this new protocol, administrators had to manually
create the records that are stored on DNS servers. The implementation of DNS server that is
included with Windows Server 2003 and later supports dynamic updates, as does the Berkeley
Internet Name Domain (BIND) version 8.x implementation of DNS.
Note
• By default, the Windows Server 2003 or later DNS Server service running on
a domain controller is configured to accept secure dynamic update only.

Every Windows Server 2003 or later based domain controller dynamically registers SRV records
in DNS. The SRV records enable servers to be located by service type (for example, LDAP) and
protocol (for example, TCP). Because domain controllers are LDAP servers that communicate
over TCP, SRV records can be used to find the DNS computer names of domain controllers. In
addition to registering LDAP-specific SRV records, Net Logon also registers Kerberos v5
authentication protocol–specific SRV records to enable locating servers that run the Kerberos
Key Distribution Center (KDC) service.
Every Windows Server 2003 or later based domain controller also dynamically registers a single
host (A) resource record that contains the name of the domain (DnsDomainName) where the
domain controller is and the IP address of the domain controller. The host (A) resource record
makes it possible for clients that do not recognize service (SRV) resource records to locate a
domain controller by means of a generic host lookup.
NetBIOS Domain Name Registration
A domain controller registers its NetBIOS name (DomainName[1C]) by broadcasting or
directing a NetBIOS name registration request to a NetBIOS name server, such as a WINS
server. Registering the NetBIOS name makes it possible for Windows-based clients that are not
DNS-enabled to find the domain controllers are running Windows NT 3.51 or later. In this case,
the client finds the domain controller by sending a Net Logon mailslot request that is based on
the NetBIOS domain name.
Note
• NetBIOS recognizes domain controllers by the [1C] registration.
DNS Delegation, Forwarders
To fully support an Active Directory domain, the DNS infrastructure must have the DNS
delegations that are necessary to enable name resolution during domain controller location.
When an Active Directory domain is created, a DNS delegation entry must exist in the DNS
zone that is the parent of the zone supporting the Active Directory domain. The delegation
enables the name of the domain controller hosting the domain to be resolved by any host or
service in the DNS namespace. The delegation resource records must be added by the network
administrator who administers the DNS server hosting the parent zone. Alternately, the parent
zone could host the DNS resource records for the domain name and, in this case, the delegation
is unnecessary.
For example, if there is a DNS zone supporting the domain corp.contoso.com, then a delegation
for this name must exist in the parent zone contoso.com. When a DNS query for the name is sent
to the root of the DNS namespace, delegations can be followed until the DNS server hosting the
zone for corp.contoso.com is identified. Without this delegation, only those network hosts and
services configured with the IP address of the DNS server hosting the zone for corp.contoso.com
will be able to resolve its DNS name. All other network hosts and services will be unable to
resolve the name, and the domain controller will not be available to them for such Active
Directory operations as joining a domain, logging on to a domain, or searching Active
Directory.
When the Active Directory domain name is specified in the Active Directory Installation
Wizard, the wizard reads the delegation entry in DNS, prompts the user to install the DNS Server
service locally and configures the corresponding DNS zone automatically. Also, if the computer
is already configured with a preferred DNS server, the wizard will configure a forwarder on the
DNS Server service with the IP address of the prior preferred DNS server.
Forwarders are also commonly configured on the DNS server hosting a zone in support of an
Active Directory domain. Forwarders are used by a DNS server to forward queries for a domain
name about which it has no local data. If an Active Directory client in one domain needs to
access a resource in another Active Directory domain, it will need to locate a domain controller
in that domain. If the DNS server used by that client is unable to locate a domain controller for
the other domain using its local data, it can forward the client request to another DNS server,
such as the DNS server that hosts the zone for the Active Directory forest root domain.
In summary, delegation enables name resolution in a descending direction from the root of the
hierarchy, and forwarders enable name resolution in a ascending direction toward the root of the
hierarchy.
Windows Server 2003 and later introduces an enhancement to forwarding called conditional
forwarders. 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 standard forwarding chain and reduces network traffic. When conditional
forwarding is applied, the DNS server hosting a zone in support of the one Active Directory
domain can forward queries to DNS servers hosting zones in support of the Active Directory
domain name specified in the client query.
Although root hints (resource records that list the DNS servers hosting the DNS root zone) can
also be used to facilitate domain controller location in place of forwarders, DNS deployments
commonly use forwarders for remote domain controller location to reduce the complexity of
administering root hints for both internal and Internet resolution.
For more information about delegation, forwarders, and root hints, see “How DNS Works.”
Domain Controller Locator
The domain controller locator (Locator) algorithm consists of two main parts:
• Locator finds which domain controllers are registered with a DNS server.

• Locator submits a DNS query to the DNS server to locate a domain controller
in the specified domain.

After this query is resolved, an LDAP User Datagram Protocol (UDP) lookup is sent to one or
more of the domain controllers listed in the response to the DNS query to ensure their
availability. Finally, the Net Logon service caches the discovered domain controller to aid in
resolving future requests.
Domain Controller Locator Process
Each Windows Server 2003 or later based domain controller registers its DNS domain name on
the DNS server and registers its NetBIOS name by using a transport-specific mechanism (for
example, WINS). Thus, a DNS client locates a domain controller by querying DNS, and a
NetBIOS client locates a domain controller by querying the appropriate transport-specific name
service. Because the code for the DNS-compatible Locator and the Windows NT 4.0–compatible
Locator is shared, both DNS clients and NetBIOS clients are supported.
The process that the Locator follows can be summarized as follows:
1. On the client (the computer that is locating the domain controller), the
Locator is initiated as a remote procedure call (RPC) to the local Net Logon
service. The Locator API (DsGetDcName) is implemented by the Net Logon
service.

2. The client collects the information that is needed to select a domain

controller and passes the information to the Net Logon service by using the
DsGetDcName API.

3. The Net Logon service on the client uses the collected information to look up
a domain controller for the specified domain in one of two ways:

○ For a DNS name, Net Logon queries DNS by using the DNS-
compatible Locator — that is, DsGetDcName calls DnsQuery to read
the SRV records and A records from DNS after it appends an
appropriate string to the front of the domain name that specifies the
SRV record.

○ For a single label name, Net Logon performs domain controller

discovery by using the Windows NT 4.0–compatible Locator — that is,
by using the transport-specific mechanism (for example, WINS).

Note

In Windows NT 4.0 and earlier, “discovery” is a process for locating a domain controllerfor
authentication in either the primary domain or a trusted domain.
 1. The Net Logon service sends a datagram to the discovered domain
controllers that register the name. For NetBIOS domain names, the datagram
is implemented as a mailslot message. For DNS domain names, the
datagram is implemented as an LDAP UDP search.

2. Each available domain controller responds to the datagram to indicate that it

is currently operational and then returns the information to DsGetDcName.

3. The Net Logon service returns the information to the client from the domain
controller that responds first.

4. The Net Logon service caches the domain controller information so that it is
not necessary to repeat the discovery process for subsequent requests.
Caching this information encourages the consistent use of the same domain
controller and, thus, a consistent view of Active Directory.

Domain Controller Location in the Closest Site

During a search for a domain controller, the Locator attempts to find a domain controller in the
site closest to the client. When the domain that is being sought is a Windows Server 2003 or later
domain, the domain controller uses the information stored in Active Directory to determine the
closest site. When the domain being sought is a Windows NT 4.0 domain, domain controller
discovery occurs when the client starts and uses the first domain controller that it finds.
Each Windows Server 2003 or later based domain controller registers DNS records that indicate
the site where the domain controller is located. The site name (the relative distinguished name of
the site object in Active Directory) is registered in several records so that the various roles the
domain controller might perform (for example, global catalog server or Kerberos server) can be
associated with the domain controller’s site. When DNS is used, the Locator searches first for a
site-specific DNS record before it begins to search for a DNS record that is not site-specific
(thereby preferentially locating a domain controller in that site).
A client computer stores its own site information in the registry, but the computer is not
necessarily located physically in the site associated with its IP address. For example, a portable
computer that was moved to a new location could contact a domain controller in its home site,
which is not the site to which the computer is currently connected. In this situation, the domain
controller looks up the client site on the basis of the client IP address by comparing the address
to the sites that are identified in Active Directory, and then returns the name of the site that is
closest to the client. The client then updates the information in the registry.
The domain controller stores site information for the entire forest in the Configuration container.
The domain controller uses the site information to check the IP address of the client computer
against the list of subnets in the forest. In this way, the domain controller ascertains the name of
the site in which the client is assumed to be located, or the site that is the closest match, and
returns this information to the client.
Active Directory Site and Subnet Objects
A site is a collection of subnets that have high-speed connections. In Active Directory, a site is
defined by a site object in the cn=Sites,cn=Configuration,dc=ForestRootDomain container. A
subnet is an addressed segment within a site and is represented by an object in the
cn=Subnets,cn=Sites,cn=Configuration,dc=ForestRootDomain container.
The site in which a domain controller is located is identified in the Configuration container by
the domain controller object that is located within the cn=Servers container beneath the site
object for a particular site. A domain controller can identify the site of a client by using the
subnet object in the Sites container. Each subnet object has a siteObject property (“attribute”)
that links it to a site object; the value of the siteObject property is the distinguished name of the
site object. This link enables a domain controller to identify clients that have an IP address in the
specified subnet as being in the specified site.
Subnet names in Active Directory take the form “network/bits masked” (for example, the subnet
object 172.16.72.0/22 has a subnet of 172.16.72.0 and a 22-bit subnet mask). If this subnet had a
siteObject property value that contained the distinguished name of the Seattle site object, all IP
addresses in the 172.16.72.0/22 subnet would be considered to be in the Seattle site. The
siteObject property is a single value, which implies that a single subnet maps to a single site.
However, multiple subnet objects can be linked to the same site object. The directory
administrator manually creates subnet objects and, hence, the siteObject property value.
The Configuration container (including all of the site and subnet objects in it) is replicated to all
domain controllers in the forest. Therefore, any domain controller in the forest can identify the
site in which a client is located, compare it to the site in which the domain controller is located,
and indicate to the client whether that domain controller’s site is the closest site to the client.
For more information about networks, subnets, and subnet masks, see “How TCP/IP Works.”
IP Addresses Mapped to Site Names
During Net Logon startup, the Net Logon service on each domain controller enumerates the site
objects in the Configuration container. Net Logon on each domain controller is also notified of
any changes made to the site objects. Net Logon uses the site information to build an in-memory
structure that is used to map IP addresses to site names.
When a client that is searching for a domain controller receives the list of domain controller IP
addresses from DNS, the client begins querying the domain controllers in turn to find out which
domain controller is available and appropriate. Active Directory intercepts the query, which
contains the IP address of the client, and passes it to Net Logon on the domain controller. Net
Logon looks up the client IP address in its subnet-to-site mapping table by finding the subnet
object that most closely matches the client IP address and then returns the following information:
• The name of the site in which the client is located, or the site that most
closely matches the client IP address.

• The name of the site in which the current domain controller is located.

• A bit that indicates whether the found domain controller is located (bit is set)
or not located (bit is not set) in the site closest to the client.

The domain controller returns the information to the client. The response also contains various
other pieces of information that describe the domain controller.
The client inspects the information to determine whether to try to find a better domain controller.
The decision is made as follows:
• If the returned domain controller is in the closest site (the returned bit is set),
the client uses that domain controller.
 • If the client has already tried to find a domain controller in the site in which
the domain controller claims the client is located, the client uses that domain
controller.

• If the domain controller is not in the closest site, the client updates its site
information and sends a new DNS query to find a new domain controller in
the site. If the second query is successful, the client uses the new domain
controller. If the second query fails, the client uses the original domain
controller.

• If the domain that is being queried by a computer is the same as the domain
to which the computer is joined, the site in which the computer resides (as
reported by a domain controller) is stored in the computer registry. The client
stores this site name in the DynamicSiteName registry entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Netlogon\Parameters. Therefore, the DsGetSiteName API returns the site in
which the computer is located.

You can override the dynamically determined value using the registry, but you should never
change dynamically determined values. To override the dynamic site name, add the SiteName
entry with the REG_SZ data type in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. When
a value is present for the SiteName entry, the DynamicSiteName entry is not used.
Note
• Editing the registry directly can have serious, unexpected consequences that
can prevent the system from starting and require that you reinstall Windows
Server 2003 or later. There are programs available in Control Panel or
Microsoft Management Console (MMC) for performing most administrative
tasks. These programs provide safeguards that prevent you from entering
conflicting settings or settings that are likely to degrade performance or
damage your system. Registry editors bypass the standard safeguards that
are provided by these administrative tools. Modifying the registry is
recommended only when no administrative tool is available. Before you make
changes to the registry, it is recommended that you back up any valuable
data on the computer. For instructions about how to edit registry entries, see
Help for the registry editor that you are using.

If the domain being located is the same as the domain to which the computer is joined and the
computer has not physically moved to a different site since the last query, the dynamically
determined site name in the registry is the actual site in which the computer is located. Thus, the
client finds a domain controller in the correct site without having to retry the operation. On the
other hand, if the site name in the registry is not the current site of the computer (for example, if
the computer is portable), the domain controller location process serves to update the site
information in the registry.
Automatic Site Coverage
There is not necessarily a domain controller in every site. For various reasons, it is possible that
no domain controller exists for a particular domain at the local site. By default, each domain
controller checks all sites in the forest and then checks the replication cost matrix. A domain
controller advertises itself (registers a site-related SRV record in DNS) in any site that does not
have a domain controller for that domain and for which its site has the lowest-cost connections.
This process ensures that every site has a domain controller that is defined by default for every
domain in the forest, even if a site does not contain a domain controller for that domain. The
domain controllers that are published in DNS are those from the closest site (as defined by the
replication topology).
For example, given one domain and three sites, a domain controller for that domain might be
located in two of the sites, but there might be no domain controller for the domain in the third
site. Replication to the domain that does not have a domain controller in the third site might be
too expensive in terms of cost or replication latency. To ensure that a domain controller can be
located in the site closest to a client computer, if not the same site, Windows Server 2003 and
later automatically attempts to register a domain controller in every site. The algorithm that is
used to accomplish automatic site coverage determines how one site can cover another site when
no domain controller exists in the second site.
Determining Site Coverage on the Basis of Site-link Cost
Site coverage is determined according to site-link costs, and domain controllers register
themselves in sites accordingly. For example, given one domain and sites A, B, and C, site A has
no domain controllers for the domain. If a client in site A attempts to locate a domain controller,
which domain controller should be returned? The answer depends on which site covers site A for
the domain.
In the example, a site link exists between site A and both of the other sites — that is, the
connections between domain controllers in site A, site B, and site C are configured for
replication over site links in Active Directory Sites and Services. Costs are associated with site
links based on the expense of transferring data over the connections. The administrator uses the
speed of the connection between sites to assign a cost to the communication link, and replication
uses the cost to establish the least expensive route for replication traffic.
Site A and site B are connected by site link AB. Site A and site C are connected by site link AC,
with the following costs:
Site link AB cost = 50.
Site link AC cost = 100.
The link between site A and site C has a much higher cost than the link between site A and
site B. The administrator configured this cost based on the expensive Integrated Services Digital
Network (ISDN) line that connects site A and site C, and the administrator would prefer that
resources in site B be used when possible. The site coverage algorithm (described in the next
sub-section) ensures that a domain controller in site B registers itself as a domain controller for
site A. In this way, clients in Site A that are looking for a domain controller find one from site B,
instead of possibly finding one from site C.
Site Coverage Algorithm
During registration of SRV records in DNS, the following algorithm determines if the domain
controllers should register site SRV records to designate themselves as preferred domain
controllers in Active Directory sites where no domain controller exists for a particular domain.
For every domain controller in the forest, this procedure is followed:
 • Build a list of target sites — sites that have no domain controllers for this
domain (the domain of the current domain controller).

• Build a list of candidate sites — sites that have domain controllers for this
domain.

• For every target site, follow these steps:

1. Build a list of candidate sites of which this domain is a member. (If

none, do nothing.)

2. Of these, build a list of sites that have the lowest site link cost to the
target site. (If none, do nothing.)

3. If more than one, break ties (reduce this list to one candidate site) by
choosing the site with the largest number of domain controllers.

4. If more than one, break ties by choosing the site that is first
alphabetically.

5. Register target-site-specific SRV records for the domain controllers for

this domain in the selected site.

Cache Time-out and Closest Site

If a domain member computer requests a domain controller while all domain controllers in its
site are offline, the Locator necessarily returns a domain controller in a different site. The
location of this domain controller is stored in the client cache. The cache lifetime is controlled by
the CloseSiteTimeout entry in the registry.
In addition, the domain controller performs authentication, and a secure channel is set up. On
subsequent location attempts, the lifetime of the cache and the lifetime of the secure channel are
secondary to the location of a domain controller in the closest site.
If the domain controller that is stored in the client cache is not in a site that is close to the client,
Net Logon attempts to find a close domain controller when either of the following events occurs:
• An interactive logon process uses pass-through authentication on the secure
channel.

• The value in the CloseSiteTimeout registry entry has elapsed since the last
attempt, and any other attempt is made to use the secure channel (for
example, pass-through authentication of network logons).

Thus, Net Logon attempts to find a close domain controller only on demand. The default value of
the CloseSiteTimeout period is 15 minutes; the maximum value is 49 days; the minimum value
is 60 seconds. The implications of these settings are:
• If the time-out value is too large, a client never tries to find a close domain
controller if there is not one available at startup.

• If the time-out value is too small, secure channel traffic is unnecessarily

slowed down by discovery attempts.
Clients with No Apparent Site
Sometimes the client pings a domain controller and the client IP address cannot be found in the
subnet-to-site mapping table. In this case, the domain controller returns a NULL site name, and
the client uses the returned domain controller.
Types of Locators
On the basis of parameters passed to Net Logon in the DsGetDcName API, the process of
locating a domain controller proceeds in one of two ways:
• The DNS-compatible Locator is used if the domain name passed to
DsGetDcName is a DNS-compatible name. The Net Logon service on the
client looks up the name in DNS (by calling DnsQuery) after it appends an
appropriate string to the front of the domain name. The DNS service
supports a query for determining the set of domain controllers. If the client
site name is known, the client DNS query specifies the site. DNS returns the
IP addresses of domain controllers that match the DNS query. The client Net
Logon service sends an LDAP UDP message to one or more of the domain
controllers that have been returned by DNS in order to determine whether
any of the specified domain controllers are running and support the specified
domain.

• The Windows NT 4.0–compatible Locator is used if the domain name passed

to DsGetDcName is a NetBIOS name. The Net Logon service on the client
sends a transport-specific logon request query to locate a domain controller
in a particular domain and then sends a mailslot message to one or more of
the domain controllers to determine whether any of the domain controllers it
found are running and support the specified domain.

DNS Client Service Configuration Elements

The DNS configuration on Active Directory client computers follows a specific computer
naming scheme and specifies how these clients will locate DNS servers. The following table lists
the configurations for DNS configuration elements.
DNS Configuration for Client Computers

DNS
Configuration Configuration
Element

Use default naming. When a Windows 2000, Windows XP, or Windows

Server 2003 or later computer joins a domain, the computer assigns itself a
Computer naming
primary DNS name comprised of the host name of the computer and the name
of the domain.

Client resolver
Configure client computers to point to any DNS server on the network.
configuration

Note
 • Active Directory clients and domain controllers can dynamically register
their DNS names using a DNS server that is not authoritative for the DNS
name of the Active Directory domain. The DNS server used by these clients
will refer the registration to the DNS server that is authoritative for the name
of the Active Directory domain.

A computer might have an existing DNS name if the organization previously statically registered
the computer in DNS or the organization previously deployed an integrated DHCP solution. If
client computers already have a registered DNS name, when the domain to which they are joined
is upgraded to Windows Server 2003 or later Active Directory, the client computers will have
two names: the existing DNS name, and the new primary name.
Clients can be located by either name. Any existing DNS, DHCP, or integrated DNS/DHCP
solution is left intact. The new primary names are created automatically and updated by means of
dynamic update. The old names are cleaned up automatically by means of DNS scavenging.
To take advantage of Kerberos authentication when connecting to a server running Windows
2000, Windows XP, Windows Server 2003 or later, the client must connect to the server by
using the primary name.
Network Ports Used by DNS in Support of Active Directory
The network ports used by DNS are documented in the DNS Technical Reference. For more
information, see “Network Ports used by DNS” in How DNS Works.
Zones and Zone Transfer
DNS distributes the DNS namespace database using DNS zones, which store name information
about one or more DNS domains. There are three types of DNS zones supported in Windows
Server 2003:
• Primary zone. Original copy of a zone where all resource records are added,
modified, and deleted.

• Secondary zone. Read-only copy of the primary zone that is created and
updated by transferring zone data from the primary zone.

• Stub zone. Read-only copy of the primary zone containing only the DNS
resource records for the DNS servers listed in the zone (SOA, NS, and glue A
resource records).

Difference Between Zones and Domains

A zone starts as a storage database for a single DNS domain name. If other domains are added
below the domain used to create the zone, these domains can either be part of the same zone or
belong to another zone. Once a subdomain is added, it can then either be:
• Managed and included as part of the original zone records, or

• Delegated away to another zone created to support the subdomain

For example, the following figure shows the microsoft.com domain, which contains domain
names for Microsoft. When the microsoft.com domain is first created at a single server, it is
configured as a single zone for all of the Microsoft DNS namespace. If, however, the
microsoft.com domain needs to use subdomains, those subdomains must be included in the zone
or delegated away to another zone.
DNS Domain Names and Subdomain Names

In this example, the example.microsoft.com domain shows a new subdomain — the

example.microsoft.com domain — delegated away from the microsoft.com zone and managed in
its own zone. However, the microsoft.com zone needs to contain a few resource records to
provide the delegation information that references the DNS servers that are authoritative for the
delegated example.microsoft.com subdomain.
If the microsoft.com zone does not use delegation for a subdomain, any data for the subdomain
remains part of the microsoft.com zone. For example, the subdomain dev.microsoft.com is not
delegated away but is managed by the microsoft.com zone.
Why Zone Replication and Zone Transfers Are Needed
Because of the important role that zones play in DNS, it is intended that they be available from
more than one DNS server on the network, to provide availability and fault tolerance when
resolving name queries. Otherwise, if a single server is used and that server is not responding,
queries for names in the zone can fail. For additional servers to host a zone, zone transfers are
required to replicate and synchronize all copies of the zone used at each server configured to host
the zone.
When a new DNS server is added to the network and is configured as a new secondary server for
an existing zone, it performs a full initial transfer of the zone to obtain and replicate a full copy
of resource records for the zone. For most earlier DNS server implementations, this same method
of full transfer for a zone is also used when the zone requires updating after changes are made to
the zone. For DNS servers running Windows Server 2003, the DNS service supports incremental
zone transfer, a revised DNS zone transfer process for intermediate changes.
Domain Delegation
A subordinate domain name, or subdomain, can be delegated from the DNS zone where its
parent name is stored to a zone on another DNS server. When deciding whether to delegate your
DNS namespace to make additional zones, consider the following reasons to use additional
zones:
• A need to delegate management of part of your DNS namespace to another
location or department within your organization.

• A need to divide one large zone into smaller zones for distributing traffic
loads among multiple servers

• A need to extend the namespace by adding numerous subdomains at once,

such as to accommodate the opening of a new branch or site.

If, for any of these reasons, you could benefit from delegating subordinate domain names to
additional zones, it might make sense to restructure your namespace by adding additional zones.
When choosing how to structure zones, you should use a plan that reflects the structure of your
organization.
When delegating zones within your namespace, be aware that for each new zone 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 being made authoritative for the new zone.
When a standard primary zone is first created, it is stored as a text file containing all resource
record information about 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 structuring your zones, there are several good reasons to use additional DNS servers for
zone replication:
• Additional DNS servers provide zone redundancy, enabling DNS names in the
zone to be resolved for clients if a primary server for the zone stops
responding.

• Additional 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 DNS 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 figure, when a new zone for a subdomain (example.microsoft.com) is
created, delegation from the parent zone (microsoft.com) is needed.
Delegating a Subdomain

In this example, an authoritative DNS server computer for the newly delegated
example.microsoft.com subdomain is named based on a derivative subdomain included in the
new zone (ns1.na.example.microsoft.com). To make this server known to others outside of the
new delegated zone, two RRs are needed in the microsoft.com zone to complete delegation to the
new zone.
These RRs include:
• An NS RR to effect the delegation. This RR is used to advertise that the server
named ns1.na.example.microsoft.com is an authoritative server for the
delegated subdomain.

• An A RR (also known as a glue record) is needed to resolve the name of the

server specified in the NS RR to its IP address. The process of resolving the
host name in this RR to the delegated DNS server in the NS RR is sometimes
referred to as glue chasing.
 Note

○ When zone delegations are correctly configured, normal zone referral

behavior can sometimes be circumvented if you are using forwarders
in your DNS server configuration. For more information, see
“Forwarding” later in this document.

Incremental Zone Transfers

Incremental zone transfers are described in RFC 1995 as an additional DNS standard for
replicating DNS zones. When incremental transfers are supported by both a DNS server acting as
the source for a zone and any servers that copy the zone from it, the incremental transfer
provides a more efficient method of propagating zone changes and updates.
In earlier DNS implementations, any request for an update of zone data required a full transfer of
the entire zone database using an AXFR query. With incremental transfer, an alternate query
type (IXFR) can be used instead. This allows the secondary server to pull only those zone
changes it needs to synchronize its copy of the zone with its source, either a primary or
secondary copy of the zone maintained by another DNS server.
With IXFR zone transfers, differences between the source and replicated versions of the zone are
first determined. If the zones are identified to be the same version — as indicated by the serial
number field in the SOA resource record of each zone — no transfer is made.
If the serial number for the zone at the source is greater than at the requesting secondary server, a
transfer is made of only those changes to RRs for each incremental version of the zone. For an
IXFR query to succeed and changes to be sent, the source DNS server for the zone must keep a
history of incremental zone changes to use when answering these queries. The incremental
transfer process requires substantially less traffic on a network and zone transfers are completed
much faster.
Example: Zone Transfer
A zone transfer might occur during any of the following scenarios:
• When the refresh interval expires for the zone

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

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

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

Zone transfer requests are always initiated at the secondary server for a zone, and then sent to
their configured master servers which act as their source for the zone. Master servers can be any
other DNS server that loads the zone, such as either the primary server for the zone or another
secondary server. When the master server receives the request for the zone, it can reply with
either a partial or full transfer of the zone to the secondary server.
Zone transfer process
As shown in the following figure, zone transfers between servers follow an ordered process. This
process varies depending on whether a zone has been previously replicated, or if initial
replication of a new zone is being performed.
Zone Transfer Process

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

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

The zone is delivered to the destination server requesting the transfer with its
version established by use of a Serial number field in the properties for the
start of authority RR. The SOA RR also contains a stated refresh interval in
seconds (by default, 900 seconds or 15 minutes) to indicate when the
destination server should next request to renew the zone with the source
server.

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

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

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

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

If the value of the serial number in the SOA response is equal to its current
local serial number, it concludes that the zone is the same at both servers
and that a zone transfer is not needed. The destination server then renews
the zone by resetting its refresh interval based on the value of this field in the
SOA response from its source server.

If the value of the serial number in the SOA response is higher than its
current local serial number, it concludes that the zone has been updated and
that a transfer is needed.

5. If the destination server concludes that the zone has changed, it sends an
IXFR query to the source server, containing its current local value for the
serial number in the SOA record for the zone.
 6. The source server responds with either an incremental or full transfer of the
zone.

If the source server supports incremental transfer by maintaining a history of

recent incremental zone changes for modified resource records, it can answer
with an incremental zone transfer (IXFR) of the zone.

If the source server does not support incremental transfer, or does not have a
history of zone changes, it can answer with a full (AXFR) transfer of the zone
instead.

Note

○ For servers running Windows 2000 and Windows Server 2003,

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

DNS Notify
Windows-based DNS servers support DNS Notify, an update to the original DNS protocol
specification that permits a means of initiating notification to secondary servers when zone
changes occur (RFC 1996). DNS notification implements a push mechanism for notifying a
select set of secondary servers for a zone when the zone is updated. Servers that are notified can
then initiate a zone transfer as described above, to pull zone changes from their master servers
and update their local replicas of the zone.
For secondaries to be notified by the DNS server acting as their configured source for a zone,
each secondary server must first have its IP address in the notify list of the source server. When
using the DNS console, this list is maintained in the Notify dialog box, which is accessible from
the Zone Transfer tab located in zone Properties.
In addition to notifying the listed servers, the DNS console permits you to use the contents of the
notify list as a means to restrict or limit zone transfer access to only those secondary servers
specified in the list. This can help prevent an undesired attempt by an unknown or unapproved
DNS server to pull, or request, zone updates.
DNS notification process
The following is a brief summary of the typical DNS notification process for zone updates:
• The local zone at a DNS server acting as a master server, a source for the
zone to other servers, is updated. When the zone is updated at the master or
source server, the serial number field in the SOA RR is also updated,
indicating a new local version of the zone.

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

• All secondary servers that receive the notify message can then respond by
initiating a zone transfer request back to the notifying master server.
The normal zone transfer process can then continue as described in the previous section.
You cannot configure a notify list for a stub zone.
Use DNS notification only to notify servers operating as secondary servers for a zone. For
replication of directory-integrated zones, DNS notification is not needed. This is because any
DNS servers that load a zone from Active Directory automatically poll the directory (as specified
by the SOA resource record’s Refresh Interval) to update and refresh the zone. In these cases,
configuring a notify list can actually degrade system performance by causing unnecessary
additional transfer requests for the updated zone.
Note
• By default, the Windows Server 2003 DNS Server service will only allow a
zone transfer to authoritative DNS servers listed in the name server (NS)
resource records for the zone.

Stub Zones
In Windows Server 2003, a new zone type named stub zone has been introduced. A stub zone is
a copy of a zone that contains only those resource records necessary to identify the authoritative
DNS servers for that zone. A stub zone is used to resolve names between separate DNS
namespaces. The need for this type of resolution can occur when a corporate merger requires that
the DNS servers for two separate DNS namespaces resolve names for clients in both
namespaces.
A stub zone consists of:
• The start of authority (SOA) resource record, name server (NS) resource
records, and the glue A resource records for the delegated zone.

• The IP address of one or more master servers that can be used to update the
stub zone.

The master servers for a stub zone are one or more DNS servers authoritative for the child zone,
usually the DNS server hosting the primary zone for the delegated domain name.
Stub zone resolution
When a DNS client performs a recursive query operation on a DNS server hosting a stub zone,
the DNS server uses the resource records in the stub zone to resolve the query. The DNS server
sends an iterative query to the authoritative DNS servers specified in the NS resource records of
the stub zone as if it were using NS resource records in its cache. If the DNS server cannot find
the authoritative DNS servers in its stub zone, the DNS server hosting the stub zone attempts
standard recursion using its root hints.
The DNS server will store the resource records it receives from the authoritative DNS servers
listed in a stub zone in its cache, but it will not store these resource records in the stub zone
itself; only the SOA, NS, and glue A resource records returned in response to the query are
stored in the stub zone. The resource records stored in the cache are cached according to the
Time-to-Live (TTL) value in each resource record. The SOA, NS, and glue A resource records,
which are not written to cache, expire according to the expire interval specified in the stub zone’s
SOA record, which is created during the creation of the stub zone and updated during transfers to
the stub zone from the original, primary zone.
If the query was an iterative query, the DNS server returns a referral containing the servers
specified in the stub zone.
Stub zone updates
Stub zone updates involve the following conditions:
• When a DNS server loads a stub zone, it queries the zone’s master server for
the SOA resource record, NS resource records at the zone’s root, and glue A
resource records.

• During updates to the stub zone, the master server is queried by the DNS
server hosting the stub zone for the same resource record types requested
during the loading of the stub zone.

• The Refresh interval of the SOA resource record determines when the DNS
server hosting the stub zone will attempt a zone transfer (update).

• If an update fails, the Retry interval of the SOA resource record determines
when the update is retried.

• Once the Retry interval has expired without a successful update, the
expiration time as specified in the Expires field of the SOA resource record
determines when the DNS server stops using the stub zone data.

Root Hints
Root hints are used to prepare servers authoritative for non-root zones so that they can learn and
discover authoritative servers that manage domains located at a higher level or in other subtrees
of the DNS domain namespace. These hints are essential for servers authoritative at lower levels
of the namespace when locating and finding servers under these conditions.
For example, suppose a DNS server (Server A) has a zone called sub.example.microsoft.com. In
the process of answering a query for a higher-level domain, such as the example.microsoft.com
domain, Server A needs some assistance to locate an authoritative server (such as Server B) for
this domain.
In order for Server A to find Server B, or any other servers that are authoritative for the
microsoft.com domain, it needs to be able to query the root servers for the DNS namespace. The
root servers can then refer Server A to the authoritative servers for the com domain. The servers
for the com domain can, in turn, offer referral to Server B or other servers that are authoritative
for the microsoft.com domain.
The root hints used by Server A must have helpful hints to the root servers for this process to
locate Server B (or another authoritative server) as intended.
To configure and use root hints correctly, first determine how the following applies to your DNS
servers:
• Are you using DNS on the Internet or on a private network?

• Is the server used as a root server?

By default, the DNS Server service implements root hints using a file, Cache.dns, stored in the
systemroot\System32\Dns folder on the server computer. This file normally contains the NS and
A resource records for the Internet root servers. If, however, you are using the DNS Server
service on a private network, you can edit or replace this file with similar records that point to
your own internal root DNS servers.
Another server configuration in which root hints are treated differently is one in which a DNS
server is configured to be used by other DNS servers in an internal namespace as a forwarder for
any DNS queries of names managed externally (the Internet, for example). Even though the DNS
server used as a forwarder can be located internally on the same network as servers using it as a
forwarder, it needs hints for the Internet root servers to work properly and resolve external
names.
Note
• If you are operating internal root servers, do not use root hints. Instead,
delete the Cache.dns file entirely for any of your root servers.

EDNS0
Extension Mechanisms for DNS (EDNS0 as defined in RFC 2671) allow DNS requestors to
advertise the size of their UDP packets and facilitate the transfer of packets larger than 512
octets, the original DNS restriction for UDP packet size (RFC 1035). When a DNS server
receives a request over the UDP Transport Layer, it identifies the requestor’s UDP packet size
from the option (OPT) RR and scales its response to contain as many resource records as are
allowed in the maximum UDP packet size specified by the requestor.
Windows Server 2003 DNS support for EDNS0 is enabled by default. It can be disabled using
the registry. Locate the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters
Add the entry EnableEDNSProbes to the subkey. Give the entry a DWORD value and set it to
0x0 to disable EDNS0.
Use extreme caution when editing the registry Modifications to the registry are not validated by
the registry editor or by Windows before they are applied, and as a result, incorrect values can be
stored. This can result in unrecoverable errors in the system..
For more information about resource records, see “Related Information” at the end of this
document.
ENDS0 UDP responses
Before a DNS server assumes that the requestor supports EDNS0, the DNS server must receive a
query containing an OPT resource record. An OPT record contains no actual DNS data and its
contents relate to the UDP Transport Layer message only. The OPT record stores the sender’s
UDP payload size in its CLASS field and lists the number of octets in the largest UDP payload
that the requestor can deliver in the requestor’s network.
When the DNS server receives a query containing an OPT record advertising the maximum UDP
packet size, it will truncate any UDP response’s size larger than the limit specified in the OPT
record.
By default, the DNS server includes OPT resource records indicating its UDP maximum in
responses to queries containing OPT resource records.
If the DNS server receives a query that does not contain an OPT resource record, it assumes the
requestor’s server does not support EDNS0 and will respond to the requestor assuming that the
sender does not accept UDP packets larger than 512 octets. In this case, the DNS server will
truncate its UDP response size to a maximum of 512 octets.
EDNS0 UDP queries
Before the requesting DNS server sends a query, it checks its cache to identify if the responding
DNS server supports EDNS0. If the responding DNS server supports EDNS0, the requesting
DNS server attaches an OPT resource record to the additional section of the query it sends. (All
queries have five sections: header, question, answer, authority, and additional.) If, according to
the requesting DNS server’s cache, the responding DNS server does not support EDNS0, the
requesting DNS server will not attach an OPT resource record to the query before it is sent.
Identifying and caching EDNS0 support
When the DNS server receives a request or response from a host containing an OPT record, the
DNS server caches the EDNS version supported by the host (such as EDNS0). If there is no OPT
record in a request or response from a host, the DNS server’s cache will indicate that the host
does not support EDNS0. If the cache already indicates that the host does support ENDS0, then
cache will not be changed.
The default value for how long a host’s EDNS0 support information is cached is 86400 (one day
specified in seconds). This value can be modified in the registry.
The DNS server decides that a host does not support EDNS0 when it requests an OPT resource
record and receives a response containing one of the following RCODE values in the header, as
shown in the following table.
EDNS0 Failure Code Values

Valu
Name Description
e

FORMERR 1 Format Error. The name server did not interpret the OPT resource record.

Server Failure. The name server did not process the query because of a
SERVFAIL 2
problem with the name server.

Not Implemented. The name server does not support the kind of query
NOTIMPL 4
requested.

(The RCODE field, or response code field, is a 4-bit field set in the header section as part of
responses.) In this situation (as a requester), the DNS server identifies that the server does not
support EDNS0 and caches this information.
Note
• When considering packet sizes, you should take account of the network
transmission path’s discovered Maximum Transmission Unit (MTU), if this
information is available. When configuring the UDP packet size to be larger
than 512 octets, remember that the UDP packets must travel through devices
other than UDP hosts and these devices, such as routers, may not support
UDP packets larger than 512 octets. The maximum UDP packet size should
 always be compared with the MTU, which in some cases may be smaller. It is
recommended that you establish the maximum UDP packet length support
for all devices, and configure your UDP hosts for this maximum.

DNSSEC
Windows Server 2003 DNS provides basic support of the DNS Security Extensions (DNSSEC)
protocol as defined in RFC 2535. The current feature support allows DNS servers to perform as
secondary DNS servers for existing DNSSEC–compliant, secure zones. DNS supports the
storing and loading of the DNSSEC-specific resource records. Currently, a DNS server is not
capable of signing zones and resource records (creating cryptographic digital signatures) or
validating the SIG RRs. The DNSSEC resource records are KEY, SIG, and NXT. For more
information about resource records, see the “DNS Resource Records Reference” later in this
document. For more information about related RFCs, see “Related Information” at the end of this
document.
Server support for DNSSEC
When loading a zone containing DNSSEC resource records, the DNS server loads these records
along with all other types of resource records contained in the zone. When receiving a zone
transfer containing DNSSEC resource records (SIG, KEY, NXT), the DNS server writes these
records to the zone storage (zone data file or Active Directory) along with all other resource
records.
When a DNS server receives a request or response containing DNSSEC resource records, it does
not verify the digital signatures but caches the response and uses it for ensuing queries. When a
DNS server receives a request for a resource record in a zone also containing DNSSEC resource
records, it attaches the appropriate DNSSEC records to the response.
When a signed zone contains resource records for an owner name, including a CNAME resource
record for that name, the DNS server will return the DNSSEC resource records associated with
the owner name and the CNAME resource record’s alias name. The DNS server will not
suppress the retrieval of the CNAME resource record, and it will not return a SIG resource
record for the canonical name. Rather, it will return the SIG resource record for the alias name.
Client support for DNSSEC
The DNS client does not read and store a key for the trusted zone and, consequently, it does not
perform any cryptography, authentication, or verification. When a resolver initiates a DNS query
and the response contains DNSSEC resource records, programs running on the DNS client will
return these records and cache them in the same manner as any other resource records. This is the
extent to which Windows XP DNS clients support DNSSEC. When the DNS client receives the
SIG RR relating to the RRset, it will not perform an additional query to obtain the associated
KEY record or any other DNSSEC records.
Resolvers do not authenticate resource records by verifying the signature information contained
in the SIG resource record. The DNS client does not contain any information to indicate which
resource records have been authenticated or to what extent they have been authenticated.
When a resolver receives a response or performs a query operation, it does not recognize the
checking disabled (CD) query header bit, which in DNSSEC indicates that the data is
authenticated by the server according to its policies, nor does it set the authentic data query
header bit, which in DNSSEC indicates that unauthenticated data is acceptable to the resolver.
Note
• If there is a signing agent running on the DNS server running Windows
Server 2003 that signs the zone resource records, this DNS server may also
be used as a primary server for DNSSEC-compliant secure zones.

Active Directory Integration

The DNS Server service is integrated into the design and implementation of Active Directory.
Active Directory provides an enterprise-level tool for organizing, managing, and locating
resources in a network.
In addition to supporting a conventional way of maintaining and replicating DNS zone files, the
implementation of DNS in Windows Server 2003 has the option of using Active Directory as the
data storage and replication engine for DNS. DNS is the domain controller location mechanism
for Active Directory.
Benefits of Integrating DNS with Active Directory
Using Active Directory as the data storage and replication engine provides the following
benefits:
• DNS replication is performed by Active Directory, so there is no need to
support a separate replication topology for DNS servers.

• Active Directory service replication provides per-property replication.

• Active Directory service replication is secure.

• A primary DNS server is eliminated as a single point of failure. Original DNS

replication is single-master and relies on a primary DNS server to update all
the secondary servers. Unlike original DNS replication, Active Directory
service replication is multimaster; an update can be made to any domain
controller in it, and the change will be propagated to other domain
controllers. In this way if DNS is integrated into Active Directory service the
replication engine will always synchronize the DNS zone information.

Thus Active Directory integration significantly simplifies the administration of a DNS

namespace. At the same time, standard zone transfers to other DNS servers (DNS servers other
than Windows 2000 Server or Windows Server 2003 DNS servers, as well as earlier versions of
Microsoft DNS servers) is still supported.
How DNS Integrates with Active Directory
When you install Active Directory on a server, you promote the server to the role of a domain
controller for a specified domain. When completing this process, you are prompted to specify a
DNS domain name for the Active Directory domain for which you are joining and promoting the
server.
Note
• When specifying the DNS domain name for the first Active Directory domain
in the first Active Directory forest, known as the forest root domain, Windows
Server 2003 does not support single-label domain names.
If during this process, a DNS server authoritative for the domain that you specified either cannot
be located on the network or does not support the DNS dynamic update protocol, you are
prompted with the option to install a DNS server. This option is provided because a DNS server
is required to locate this server or other domain controllers for members of an Active Directory
domain.
Once you have installed Active Directory, you have two options for storing and replicating your
zones when operating the DNS server at the new domain controller:
• Standard zone storage, using a text-based file.

Zones stored this way are located in .dns files that are stored in the
systemroot\System32\Dns folder on each computer operating a DNS server.
Zone file names correspond to the name you choose for the zone when
creating it, such as “example.microsoft.com.dns” if the zone name was
“example.microsoft.com.”

• Directory-integrated zone storage, using the Active Directory database.

Zones stored this way are located in the Active Directory tree under the
domain or application directory partition. Each directory-integrated zone is
stored in a dnsZone container object identified by the name you choose for
the zone when creating it.

Zones stored in text files are typically referred to as file-backed zonesand zones stored in Active
Directory are referred to as Active Directory-integrated zones.
In Active Directory-integrated DNS, each DNS zone becomes an Active Directory container
object (DnsZone). The DnsZone object contains a DnsNode leaf object for every unique name
within that zone. The DnsNode object has a DnsRecord multivalued attribute with an instance of
a value for every record associated with the object’s name.
Note
• Active Directory-integrated zones can only be loaded onto a domain
controller when the Windows Server 2003 DNS Server service is running on
the domain controller.

Replication Model
When DNS zone information is stored in Active Directory and an update is made to a DNS
server, it writes the update data to Active Directory. Active Directory is now responsible for
replicating the data to other domain controllers. The DNS servers running on other domain
controllers will poll the updates from the Active Directory.
Because Active Directory service uses the multimaster replication model, DNS updates can be
written to any Active Directory-integrated DNS server, and the data will automatically be
replicated across all the domain controllers.
The ability to write to Active Directory from multiple domain controllers at the same time can
create a conflicting situation where the changes are made to the same object on two different
DNS servers. The conflict will eventually be resolved in favor of the last update made to the
object based on the timestamps of the updates. The same rule is applied in the case where two or
more nodes with the same name are created on two or more DNS servers. Until the conflict is
resolved and the DNS server, containing invalid update, polls the valid data from the Active
Directory, it is possible that requests for the same object made to two different DNS servers will
be resolved differently. This is why the Active Directory database is called loosely consistent.
Active Directory-integration provides an advantage over file-backed zones. With file-backed
zones, only the primary authoritative DNS server for a zone can modify the zone. With Active
Directory-integration, all domain controllers for the Active Directory domain where the zone is
stored can modify the zone and then replicate the changes to other domain controllers. This
replication process is called multimaster replication because multiple domain controllers can
update the zone.
Windows Server 2003 domain controllers replicate resource records contained in Active
Directory–integrated zones using Active Directory replication. Zones stored in Active Directory
can also be transferred to secondary servers to create secondary zones in the same way that file-
backed zones are transferred.
Active Directory–integration provides numerous benefits, including fault tolerance, security,
simplified management, and more efficient replication of zones.
Active Directory-integrated Zones
When you configure a primary zone to be Active Directory–integrated, the zone is stored in
Active Directory.
The following figure shows this configuration.
Active Directory–integrated Zone

The DNS server component contains only a copy of the zone. When DNS starts up, it reads a
copy of the zone from Active Directory (step 1). Then, when the DNS server receives a change,
it writes the change to Active Directory (step 2).
Through Active Directory replication, the zone is replicated to other domain controllers in the
same domain. Also, through standard zone transfer, the DNS server can send its copy of the zone
to any secondary DNS servers that request it. The DNS server can perform both incremental and
full zone transfers. The following figure shows how the same zone can be replicated by using
both Active Directory replication and standard zone transfer.
Active Directory Replication and Zone Transfer

By default, when the DNS Server service starts on a domain controller, it checks whether Active
Directory is available and if it contains any DNS zones. If Active Directory does have zones, the
DNS Server service loads them from Active Directory. The DNS Server service automatically
writes back to the boot file at regular intervals. The boot file can be updated manually by using
the DNS console.
The DNS Server service also loads the root hints and server and zone parameters from different
locations depending on its settings. The table below shows the locations from which the DNS
Server service loads and to which it writes zones, root hints, and server and zone parameters.
Note
• Changing the startup type is not recommended and could result in DNS
infrastructure errors.

How the DNS Server Loads Zones, Root Hints, and Parameters

Load Data
Load Data On Startup
On Startup Load Data On Startup
Task Set To: From Active
Set To: Set To: From Registry
Directory and Registry
From File

If available, the root hints file. If the directory is available

Read root hints Otherwise, if the Directory is and contains root hints, from
Root hints file
from: available and contains root the directory. Otherwise, from
hints, the directory the root hints file

Write root hints If the directory is available,

Root hints file Root hints file
to: the directory

Boot file, to get

The directory (for Active
list of zones,
Read zones from: Registry Directory–integrated zones)
then from zone
and the registry
files

Registry and, if the zone is Registry and, if the zone is

Boot file and
Write zones to: Active Directory–integrated, Active Directory–integrated,
the registry
the directory the directory

Read server and Registry and (for Active The directory (for Active
Boot file and
zones parameters Directory–integrated zones) Directory–integrated zones)
the registry
from: the directory and the registry

Write server and Registry (for all zones) and The directory (for Active
Boot file and
zones parameters (for Active Directory– Directory–integrated zones)
the registry
to: integrated zones) the directory and the registry

If you change the setting of the DNS Server service, it first writes the root hints file, zones, and
parameters to the locations specified in the default setting, and then the DNS Server service reads
them from the new setting.
Directory-integrated Zone Storage Location
Active Directory is an object-oriented X.500-compliant database that organizes resources
available on your network in a hierarchical tree-like structure. This database is managed by a set
of domain controllers. The portion of the Active Directory database for which a specific domain
controller is authoritative is physically located on the same computer as the domain controller is.
Every resource in Active Directory is represented by an object. There are two distinct types of
objects supported by Active Directory:
• Containers–objects that can contain other container and leaf objects.

• Leafs–objects representing a specific resource within the Active Directory

service tree.

Each Active Directory object has attributes associated with it that define particular characteristics
of the object.
The classes of objects in the Active Directory database, as well as the attributes of each object,
are defined in the Active Directory schema. In other words, the schema contains definitions for
each class object available in Active Directory. The following are examples of Active Directory
service class objects:
• User

• Group

• Organizational Unit

• DnsZone

• DnsNode

In Windows 2000 Server, Active Directory-integrated zones were stored in the domain partition
of the directory. Zones stored in the domain partition are replicated to all domain controllers in
the domain. This replication scope is not necessary for some applications, such as DNS.
Windows Server 2003 Active Directory provides a new type of partition, called application
directory partition, to enable different replication scopes. Application directory partitions provide
storage for application-specific data that can be replicated to any arbitrary set of domain
controllers in the forest, as few or as many as needed by the application that uses the data.
Note
• At the time a DNS application directory partition is created (manually by an
administrator or programmatically by an application), the domain naming
flexible single master operations (FSMO) role for the forest must be held by a
domain controller running Windows Server 2003. Following application
directory partition creation, you can move the domain naming role to a
domain controller that is running Windows 2000, if needed.

There are two default Windows Server 2003 DNS application directory partitions created to
allow for different DNS zone replication scopes: the forest-wide DNS application directory
partition and the domain-wide application directory partition. Active Directory-integrated zones
can be stored in the domain or application directory partitions. The following table describes the
Windows Server 2003 Active Directory storage options available for DNS zones.
Windows Server 2003 Active Directory Storage Options
 Active
Directory
Description
Storage
Option

Active Directory domain partition for each domain in the forest. DNS zones
stored in this partition are replicated to all domain controllers in the domain.
Domain partition
This is the only Active Directory storage option for DNS zones that are
replicated to domain controllers running Windows 2000 Server.

DNS application directory partition for the entire forest. DNS zones stored in
this application directory partition are replicated to all DNS servers running
Forest-wide DNS on domain controllers in the forest.
application
This DNS application directory partition is created when you install the DNS
directory partition
Server service on the first Windows Server 2003
domain controller in the forest.

DNS application directory partition for each domain in the forest. DNS zones
stored in this application directory partition are replicated to all DNS servers
running on domain controllers in the domain. For the forest root domain, this
Domain-wide DNS application directory partition is created when you first install the DNS
DNS application Server service on a Windows Server 2003 domain controller in the forest.
directory partition
For each new domain in the forest (child domain), this DNS application
directory partition is created when you first install the DNS Server service on
a Windows Server 2003 domain controller for the new domain.

DNS application directory partition for any domain controller that is enlisted
Custom DNS in its replication scope. This type of DNS application directory partition does
application not exist by default and must be created. DNS zones stored in this application
directory partition directory partition are replicated to all DNS servers running on domain
controller that enlist in the partition.

Note
• You can specify the DNS application directory partition where you want to
store the zone by using the DNS console or the Dnscmd support tool, or you
can change the zone storage option once the zone is created using DNS
console or Dnscmd.

Active Directory DNS Objects

By default, Windows Server 2003 Active Directory-integrated zones are stored in the domain-
wide application directory partition of the directory. The zone information is stored with the
container whose distinguished name is: CN=MicrosoftDNS,DC=DNS domain name. The zone
information for zones stored on domain controllers in the example.com domain would be stored
in CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=com.
The DNS application directory partitions are not displayed by all Active Directory administrative
tools. To see these directory partitions, you can use dnscmd (command-line tool) or ADSI Edit
(adsiedit.msc) in Support Tools.
The replication scope of a custom DNS application directory partition is defined by the number
of domain controllers enlisted in the partition. By default, only members of the Enterprise
Admins group can enlist a DNS server in a DNS application directory partition.
Once a DNS server is enlisted in a DNS application directory partition, you can store DNS zones
in that application directory partition using the DNS console. The required FQDN value specifies
the name of the new DNS application directory partition. You must use a DNS fully qualified
domain name.
The MicrosoftDNS container holds other objects that represent the zones and the individual DNS
resource records in those zones. The following table lists the DNS object types that are stored in
the Active Directory.
DNS Objects Stored in Active Directory

Object Description

DnsZone Container created when a zone is stored in Active Directory.

DnsNode Leaf object used to map and associate a name in the zone to resource data.

Multivalued attribute of a dnsNode object used to store the resource records

DnsRecord
associated with the named node object.

Multivalued attribute of a dnsZone object used to store zone configuration

DnsProperty
information.

The MicrosoftDNS container object contains one or more dnsZone container objects. Each
dnsZone object represents one zone.
MicrosoftDNS contains the following dnsZone objects:
• The reverse lookup zone, 72.16.172.in-addr.arpa

• The forward lookup zone, example.com

• The root hints, RootDNSServers

You can view DNS objects from within the Active Directory Users and Computers console. The
following graphic shows the dnsZone objects in Active Directory.
DNS Objects in Active Directory

The dnsZone container object contains a dnsNode leaf object for every unique name within that
zone. This figure shows the following dnsNode objects within the dnsZone container object for
example.com:
 • @, which signifies that the node has the same name as the dnsZone object.

• delegated, a delegated subdomain.

• host.notdelegated, a host in the domain not delegated.example.com, a

domain that is controlled by the zone on example.com.

• host1, a host in the domain example.com.

• mailserver, the mail server in the domain example.com.

• nameserver, the name server in example.com.

• notdelegated, the domain notdelegated.example.com, which is controlled

by the zone on example.com.

The dnsNode leaf object has a multivalued attribute called dnsRecord with an instance of a
value for every record associated with the object’s name. In this example, the dnsNode leaf
object mailserver.example.com has an “A” attribute containing the IP address.
Although you can view the zone objects from within the Active Directory Users and Computers
component, the Active Directory Users and Computers component cannot interpret the values of
the dnsRecord attribute. If you want to view the DNS domain hierarchy and associated records,
use the DNS console. Alternatively, if you want to view the zones, you can retrieve them by
using Nslookup.
Note
• Windows 2000 domain controllers do not support application directory
partitions and therefore you cannot view zones stored in DNS application
directory partitions using Windows 2000 administration tools.

DNS Processes and Interactions

DNS processes and interactions involve the communications between DNS clients and DNS
servers during the resolution of DNS queries and dynamic update, and between DNS servers
during name resolution and zone administration. Secondary processes and interactions depend on
the support for technologies such as Unicode and WINS.
For information about TCP/IP DNS messages, see “DNS Protocol” in this document.
How DNS Queries Work
When a DNS client needs to look up a name used in a program, it queries DNS servers to resolve
the name. Each query message the client sends contains three pieces of information, specifying a
question for the server to answer:
1. A specified DNS domain name, stated as a fully qualified domain name.

2. A specified query type, which can either specify a resource record by type or
a specialized type of query operation.

3. A specified class for the DNS domain name. For Windows DNS servers, this
should always be specified as the Internet (IN) class.
For example, the name specified could be the FQDN for a computer, such as ““host-
a.example.microsoft.com.””, and the query type specified to look for an address (A) resource
record by that name. Think of a DNS query as a client asking a server a two-part question, such
as “Do you have any A resource records for a computer named
‘hostname.example.microsoft.com.’ ”? When the client receives an answer from the server, it
reads and interprets the answered A resource record, learning the IP address for the computer it
asked for by name.
DNS queries resolve in a number of different ways. A client can sometimes answer a query
locally using cached information obtained from a previous query. The DNS server can use its
own cache of resource record information to answer a query. A DNS server can also query or
contact other DNS servers on behalf of the requesting client to fully resolve the name, then send
an answer back to the client. This process is known as recursion.
In addition, the client itself can attempt to contact additional DNS servers to resolve a name.
When a client does so, it uses separate and additional queries based on referral answers from
servers. This process is known as iteration.
In general, the DNS query process occurs in two parts:
• A name query begins at a client computer and is passed to a resolver, the
DNS Client service, for resolution.

• When the query cannot be resolved locally, DNS servers can be queried as
needed to resolve the name.

Both of these processes are explained in more detail in the following sections.
Part 1: DNS Client Service Resolver
The following figure shows an overview of the complete DNS query process.
Overview of DNS Query Process

As shown in the initial steps of the query process, a DNS domain name is used in a program on
the local computer. The request is then passed to the DNS Client service for resolution using
locally cached information. If the queried name can be resolved, the query is answered and the
process is completed.
The local resolver cache can include name information obtained from two possible sources:
• If a Hosts file is configured locally, any host name-to-address mappings from
that file are preloaded into the cache when the DNS Client service is started.

• Resource records obtained in answered responses from previous DNS queries

are added to the cache and kept for a period of time.

If the query does not match an entry in the cache, the resolution process continues with the client
querying a DNS server to resolve the name.
Part 2: Querying a DNS Server
As indicated in the previous figure, the client queries a preferred DNS server. The actual server
used during the initial client/server query is selected from a global list.
When the DNS server receives a query, it first checks to see if it can answer the query
authoritatively based on resource record information contained in a locally configured zone on
the server. If the queried name matches a corresponding resource record in local zone
information, the server answers authoritatively, using this information to resolve the queried
name.
If no zone information exists for the queried name, the server then checks to see if it can resolve
the name using locally cached information from previous queries. If a match is found here, the
server answers with this information. Again, if the preferred server can answer with a positive
matched response from its cache to the requesting client, the query is completed.
If the queried name does not find a matched answer at its preferred server — either from its
cache or zone information — the query process can continue, using recursion to fully resolve the
name. This involves assistance from other DNS servers to help resolve the name. By default, the
DNS Client service asks the server to use a process of recursion to fully resolve names on behalf
of the client before returning an answer.
In order for the DNS server to do recursion properly, it first needs some helpful contact
information about other DNS servers in the DNS domain namespace. This information is
provided in the form of root hints, a list of preliminary resource records that can be used by the
DNS service to locate other DNS servers that are authoritative for the root of the DNS domain
namespace tree. Root servers are authoritative for the domain root and top-level domains in the
DNS domain namespace tree.
By using root hints to find root servers, a DNS server is able to complete the use of recursion. In
theory, this process enables any DNS server to locate the servers that are authoritative for any
other DNS domain name used at any level in the namespace tree.
For example, consider the use of the recursion process to locate the name “host-
b.example.microsoft.com.” when the client queries a single DNS server. The process occurs
when a DNS server and client are first started and have no locally cached information available
to help resolve a name query. It assumes that the name queried by the client is for a domain name
of which the server has no local knowledge, based on its configured zones.
First, the preferred server parses the full name and determines that it needs the location of the
server that is authoritative for the top-level domain, “com”. It then uses an iterative query to the
“com” DNS server to obtain a referral to the “microsoft.com” server. Next, a referral answer
comes from the “microsoft.com” server to the DNS server for “example.microsoft.com”.
Finally, the “example.microsoft.com.” server is contacted. Because this server contains the
queried name as part of its configured zones, it responds authoritatively back to the original
server that initiated recursion. When the original server receives the response indicating that an
authoritative answer was obtained to the requested query, it forwards this answer back to the
requesting client and the recursive query process is completed.
Although the recursive query process can be resource-intensive when performed as described
above, it has some performance advantages for the DNS server. For example, during the
recursion process, the DNS server performing the recursive lookup obtains information about the
DNS domain namespace. This information is cached by the server and can be used again to help
speed the answering of subsequent queries that use or match it. Over time, this cached
information can grow to occupy a significant portion of server memory resources, although it is
cleared whenever the DNS service is cycled on and off.
The following three figures illustrate the process by which the DNS client queries the servers on
each adapter.
Querying the DNS Server, Part 1

Querying the DNS Server, Part 2

Querying the DNS Server, Part 3

The DNS Client service queries the DNS servers in the following order:
1. The DNS Client service sends the name query to the first DNS server on the
preferred adapter’s list of DNS servers and waits one second for a response.

2. If the DNS Client service does not receive a response from the first DNS
server within one second, it sends the name query to the first DNS servers on
all adapters that are still under consideration and waits two seconds for a
response.

3. If the DNS Client service does not receive a response from any DNS server
within two seconds, the DNS Client service sends the query to all DNS servers
on all adapters that are still under consideration and waits another two
seconds for a response.

4. If the DNS Client service still does not receive a response from any DNS
server, it sends the name query to all DNS servers on all adapters that are
still under consideration and waits four seconds for a response.

5. If it the DNS Client service does not receive a response from any DNS server,
the DNS client sends the query to all DNS servers on all adapters that are still
under consideration and waits eight seconds for a response.

If the DNS Client service receives a positive response, it stops querying for the name, adds the
response to the cache and returns the response to the client.
If the DNS Client service has not received a response from any server within eight seconds, the
DNS Client service responds with a time-out. Also, if it has not received a response from any
DNS server on a specified adapter, then for the next 30 seconds, the DNS Client service responds
to all queries destined for servers on that adapter with a time-out and does not query those
servers. Only computers running Windows 2000 or Windows Server 2003 return this time-out.
If at any point the DNS Client service receives a negative response from a server, it removes
every server on that adapter from consideration during this search. For example, if in step 2, the
first server on Alternate Adapter A gave a negative response, the DNS Client service would not
send the query to any other server on the list for Alternate Adapter A.
The DNS Client service keeps track of which servers answer name queries more quickly, and it
moves servers up or down on the list based on how quickly they reply to name queries.
The following figure shows how the DNS client queries each server on each adapter.
Multihomed Name Resolution

Alternate Query Responses

The previous discussion of DNS queries assumes that the process ends with a positive response
returned to the client. However, queries can return other answers as well. These are the most
common query answers:
• An authoritative answer

• A positive answer

• A referral answer (used by the Windows Server 2003 DNS Server service
only)

• A negative answer

An authoritative answer is a positive answer returned to the client and delivered with the
authority bit set in the DNS message to indicate the answer was obtained from a server with
direct authority for the queried name.
A positive response can consist of the queried RR or a list of RRs (also known as an RRset) that
fits the queried DNS domain name and record type specified in the query message.
A referral answer contains additional RRs not specified by name or type in the query. This type
of answer is returned to the client if the recursion process is not supported. The records are meant
to act as helpful reference answers that the client can use to continue the query using iteration. A
referral answer contains additional data such as RRs that are other than the type queried. For
example, if the queried host name was “www” and no A RRs for this name were found in this
zone but a CNAME RR for “www” was found instead, the DNS server can include that
information when responding to the client. If the client is able to use iteration, it can make
additional queries using the referral information in an attempt to fully resolve the name for itself.
A negative response from the server can indicate that one of two possible results was
encountered while the server attempted to process and recursively resolve the query fully and
authoritatively:
• An authoritative server reported that the queried name does not exist in the
DNS namespace.
 • An authoritative server reported that the queried name exists but no records
of the specified type exist for that name.

The resolver passes the results of the query, in the form of either a positive or negative response,
back to the requesting program and caches the response.
If the resultant answer to a query is too long to be sent and resolved in a single UDP message
packet, the DNS server can initiate a failover response over TCP port 53 to answer the client
fully in a TCP connected session.
Disabling the use of recursion on a DNS server is generally done when DNS clients are being
limited to resolving names to a specific DNS server, such as one located on your intranet.
Recursion might also be disabled when the DNS server is incapable of resolving external DNS
names, and clients are expected to fail over to another DNS server for resolution of these names.
If you disable recursion on the DNS server, you will not be able to use forwarders on the same
server.
By default, DNS servers use several default timings when performing a recursive query and
contacting other DNS servers. These defaults include:
• A recursion retry interval of 3 seconds. This is the length of time the DNS
service waits before retrying a query made during a recursive lookup.

• A recursion time-out interval of 15 seconds. This is the length of time the DNS
service waits before failing a recursive lookup that has been retried.

Under most circumstances, these parameters do not need adjustment. However, if you are using
recursive lookups over a slow-speed WAN link, you might be able to improve server
performance and query completion by making slight adjustments to the settings.
How Iteration Works
Iteration is the type of name resolution used between DNS clients and servers when the
following conditions are in effect:
• The client requests the use of recursion, but recursion is disabled on the DNS
server.

• The client does not request the use of recursion when querying the DNS
server.

An iterative request from a client tells the DNS server that the client expects the best answer the
DNS server can provide immediately, without contacting other DNS servers.
When iteration is used, a DNS server answers a client based on its own specific knowledge about
the namespace with regard to the names data being queried. For example, if a DNS server on
your intranet receives a query from a local client for “www.microsoft.com”, it might return an
answer from its names cache. If the queried name is not currently stored in the names cache of
the server, the server might respond by providing a referral — that is, a list of NS and A resource
records for other DNS servers that are closer to the name queried by the client.
When iteration is used, a DNS server can further assist in a name query resolution beyond giving
its own best answer back to the client. For most iterative queries, a client uses its locally
configured list of DNS servers to contact other name servers throughout the DNS namespace if
its primary DNS server cannot resolve the query.
The Windows Server 2003 DNS Client service does not perform recursion.
How Caching Works
As DNS servers process client queries using recursion or iteration, they discover and acquire a
significant store of information about the DNS namespace. This information is then cached by
the server.
Caching provides a way to speed the performance of DNS resolution for subsequent queries of
popular names, while substantially reducing DNS-related query traffic on the network.
As DNS servers make recursive queries on behalf of clients, they temporarily cache resource
records (RRs). Cached RRs contain information obtained from DNS servers that are authoritative
for DNS domain names learned while making iterative queries to search and fully answer a
recursive query performed on behalf of a client. Later, when other clients place new queries that
request RR information matching cached RRs, the DNS server can use the cached RR
information to answer them.
When information is cached, a Time-To-Live (TTL) value applies to all cached RRs. As long as
the TTL for a cached RR does not expire, a DNS server can continue to cache and use the RR
again when answering queries by its clients that match these RRs. Caching TTL values used by
RRs in most zone configurations are assigned the Minimum (default) TTL which is set in the
zone’s start of authority (SOA) resource record. By default, the minimum TTL is 3,600 seconds
(one hour) but can be adjusted or, if needed, individual caching TTLs can be set at each RR.
Note
• By default, the DNS Server service uses a root hints file, cache.dns, that is
stored in the systemroot\System32\Dns folder on the server computer. This
file contains the NS and A resource records for the root servers of the DNS
namespace (the Internet root servers or intranet root servers). When the DNS
Server service is started, the root server list is queried for a current list of all
the root servers. The results of the query are used to update the root hints
file. This operation is also performed periodically while the service is running.
When changes are made to the root hints by an administrator, these changes
are written back to the root hints file.

Reverse Lookup
In most DNS lookups, clients typically perform a forward lookup, which is a search based on the
DNS name of another computer as stored in an address (A) resource record. This type of query
expects an IP address as the resource data for the answered response.
DNS also provides a reverse lookup process, enabling clients to use a known IP address during a
name query and to look up a computer name based on its address. A reverse lookup takes the
form of a question, such as “Can you tell me the DNS name of the computer that uses the IP
address 192.168.1.20?”
DNS was not originally designed to support this type of query. One problem for supporting the
reverse query process is the difference in how the DNS namespace organizes and indexes names
and how IP addresses are assigned. If the only method available to answer the previous question
was to search all domains in the DNS namespace, a reverse query would take too long and
require too much processing to be useful.
To solve this problem, a special domain called the in-addr.arpa domain was defined in the DNS
standards and reserved in the Internet DNS namespace to provide a practical and reliable way to
perform reverse queries. To create the reverse namespace, subdomains within the in-addr.arpa
domain are formed using the reverse ordering of the numbers in the dotted-decimal notation of
IP addresses.
This reversed ordering of the domains for each octet value is needed because, unlike DNS
names, when IP addresses are read from left to right, they are interpreted in the opposite manner.
When an IP address is read from left to right, it is viewed from its most generalized information
(an IP network address) in the first part of the address to the more specific information (an IP
host address) contained in the last octets.
For this reason, the order of IP address octets must be reversed when building the in-addr.arpa
domain tree. The IP addresses of the DNS in-addr.arpa tree can be delegated to companies as
they are assigned a specific or limited set of IP addresses within the Internet-defined address
classes.
Finally, the in-addr.arpa domain tree, as built into DNS, requires that an additional RR type —
the pointer (PTR) RR — be defined. This RR is used to create a mapping in the reverse lookup
zone that typically corresponds to a host (A) named RR for the DNS computer name of a host in
its forward lookup zone.
The in-addr.arpa domain applies for use in all TCP/IP networks that are based on Internet
Protocol version 4 (IPv4) addressing. The New Zone Wizard automatically assumes that you are
using this domain when creating a new reverse lookup zone.
If you are installing DNS and configuring reverse lookup zones for an Internet Protocol version 6
(IPv6) network, you can specify an exact name in the New Zone Wizard. This will permit you to
create reverse lookup zones in the DNS console that can be used to support IPv6 networks,
which use a different special domain name, the ip6.arpa domain.
For information about IPv6 and DNS, including examples of how to create and use ip6.arpa
domain names as described in RFC 1886 (“DNS Extensions to support IP version 6”), see
“Related Information” at the end of this section.
Note
• The configuration of PTR resource records and reverse lookup zones for
identifying hosts by reverse query is strictly an optional part of the DNS
standard implementation. You are not required to use reverse lookup zones,
although for some networked applications, they are used to perform security
checks.

Example: Reverse Query (for IPv4 networks)

The following figure shows an example of a reverse query initiated by a DNS client (host-b) to
learn the name of another host (host-a) based on its IP address, 192.168.1.20.
Reverse Query
The reverse query process as shown in this figure occurs in the following steps:
1. The client, “host-b”, queries the DNS server for a pointer (PTR) RR that maps
to the IP address of 192.168.1.20 for “host-a”.

Because the query is for PTR records, the resolver reverses the address and
appends the in-addr.arpa domain to the end of the reverse address. This
forms the fully qualified domain name (“20.1.168.192.in-addr.arpa.”) for
which to be searched in a reverse lookup zone.

2. Once located, the authoritative DNS server for “20.1.168.192.in-addr.arpa”

can respond with the PTR record information. This includes the DNS domain
name for “host-a”, completing the reverse lookup

Keep in mind that if the queried reverse name is not answerable from the DNS server, normal
DNS resolution (either recursion or iteration) can be used to locate a DNS server that is
authoritative for the reverse lookup zone and that contains the queried name. In this sense, the
name resolution process used in a reverse lookup is identical to that of a forward lookup.
Note
• The DNS console provides a means for you to configure a subnetted reverse
lookup “classless” zone when the Advanced view is selected. This allows you
to configure a zone in the in-addr.arpa domain for a limited set of assigned IP
addresses where a nondefault IP subnet mask is used with those addresses.

Forwarding
A forwarder is a Domain Name System (DNS) server on a network used to forward DNS queries
for external DNS names to DNS servers outside of that network. You can also forward queries
according to specific domain names using conditional forwarders.
A DNS server on a network is designated as a forwarder by having the other DNS servers in the
network forward the queries they cannot resolve locally to that DNS server. By using a
forwarder, you can manage name resolution for names outside of your network, such as names
on the Internet, and improve the efficiency of name resolution for the computers in your
network.
Directing Name Queries Using Forwarders
The following figure illustrates how external name queries are directed using forwarders.
External Name Queries Directed Using Forwarders

Without having a specific DNS server designated as a forwarder, all DNS servers can send
queries outside of a network using their root hints. As a result, a lot of internal, and possibly
critical, DNS information can be exposed on the Internet. In addition to this security and privacy
issue, this method of resolution can result in a large volume of external traffic that is costly and
inefficient for a network with a slow Internet connection or a company with high Internet service
costs.
When you designate a DNS server as a forwarder, you make that forwarder responsible for
handling external traffic, thereby limiting DNS server exposure to the Internet. A forwarder will
build up a large cache of external DNS information because all of the external DNS queries in
the network are resolved through it. In a small amount of time, a forwarder will resolve a good
portion of external DNS queries using this cached data and thereby decrease the Internet traffic
over the network and the response time for DNS clients.
Behavior of a DNS Server Configured to Use Forwarding
A DNS server configured to use a forwarder will behave differently than a DNS server that is not
configured to use a forwarder. A DNS server configured to use a forwarder behaves as follows:
1. When the DNS server receives a query, it attempts to resolve this query using
the primary and secondary zones that it hosts and its cache.

2. If the query cannot be resolved using this local data, then it will forward the
query to the DNS server designated as a forwarder.

3. The DNS server will wait briefly for an answer from the forwarder before
attempting to contact the DNS servers specified in its root hints.

When a DNS server forwards a query to a forwarder it sends a recursive query to the forwarder.
This is different than the iterative query that a DNS server will send to an other DNS server
during standard name resolution (name resolution that does not involve a forwarder).
Forwarding Sequence
The sequence in which the forwarders configured on a DNS server are used is determined by the
order in which the IP addresses are listed on the DNS server. After the DNS server forwards the
query to the forwarder with the first IP address, it waits a short period for an answer from that
forwarder (according to the DNS server’s time out setting) before resuming the forwarding
operation with the next IP address. It continues this process until it receives an affirmative
answer from a forwarder.
Unlike conventional resolution, where a roundtrip time (RTT) is associated with each server, the
IP addresses in the forwarders list are not ordered according to roundtrip time and must be
reordered manually to change preference.
Forwarders and Delegation
A DNS server configured with a forwarder and hosting a parent zone will use its delegation
information before forwarding queries. If no delegation record exists for the DNS name in the
query, then the DNS server will use its forwarders to resolve the query.
Forwarders and Root Servers
A common error when configuring forwarding is to attempt to configure forwarding on the root
servers of a private DNS namespace. The goal of attempting to configure forwarding on root
servers for a private DNS namespace is to forward all offsite queries to Internet DNS servers.
Root servers cannot be configured with standard forwarding. If a root server is queried about any
domain name, then it will refer to a DNS server that can answer the question (from its local
zones, cache), or it will respond with a failure (NXDOMAIN), but it cannot be configured to
forward to specific servers.
Note
• A root server can be configured with a conditional forwarder. Conditional
forwarding can be used to forward queries between root servers in separate
DNS namespaces, although the DNS servers for the top-level domains in the
namespace are better suited for this method of resolution.

Conditional Forwarders
A conditional forwarder is a DNS server on a network that is used to forward DNS queries
according to the DNS domain name in the query. For example, a DNS server can be configured
to forward all the queries it receives for names ending with widgets.example.com to the IP
address of a specific DNS server or to the IP addresses of multiple DNS servers.
Intranet Name Resolution
A conditional forwarder can be used to improve name resolution for domains within your
intranet. Intranet name resolution can be improved by configuring DNS servers with forwarders
for specific internal domain names. For example, all DNS servers in the domain
widgets.example.com could be configured to forward queries for names that end with
test.example.com to the authoritative DNS servers for merged.widgets.example.com, thereby
removing the step of querying the root servers of example.com, or removing the step of
configuring DNS servers in the widgets.example.com zone with secondary zones for
test.example.com.
Internet Name Resolution
DNS servers can use conditional forwarders to resolve queries between the DNS domain names
of companies that share information. For example, two companies, Widgets Toys and
TailspinToys, want to improve how the DNS clients of Widgets Toys resolve the names of the
DNS clients of Tailspin Toys. The administrators from Tailspin Toys inform the administrators
of Widgets Toys about the set of DNS servers in the Tailspin Toys network where Widgets can
send queries for the domain dolls.tailspintoys.com. The DNS servers within the Widgets Toys
network are configured to forward all queries for names ending with dolls.tailspintoys.com to the
designated DNS servers in the network for Tailspin Toys. Consequently, the DNS servers in the
Widgets Toys network do not need to query their internal root servers, or the Internet root
servers, to resolve queries for names ending with dolls.tailspintoys.com.
Dynamic Update
Dynamic update enables DNS client computers to register and dynamically update their resource
records with a DNS server whenever changes occur. This reduces the need for manual
administration of zone records, especially for clients that frequently move or change locations
and use DHCP to obtain an IP address.
The DNS Client and Server services support the use of dynamic updates, as described in RFC
2136, “Dynamic Updates in the Domain Name System.” The DNS Server service allows
dynamic update to be enabled or disabled on a per-zone basis at each server configured to load
either a standard primary or directory-integrated zone. By default, the Windows Server 2003
DNS Client service will dynamically update host (A) resource records in DNS when configured
for TCP/IP. The Windows Server 2003 DNS Server service is configured, by default, to allow
only secure dynamic update. You must change this configuration if you will be using dynamic
update only.
Protocol Description
RFC 2136 introduces a new opcode or message format called UPDATE. The update message
can add and delete resource records from a specified zone as well as test for prerequisite
conditions. Update is atomic, that is, all prerequisites must be satisfied or no update operation
will take place.
As in any conventional DNS implementation, the zone update must be committed on a primary
DNS server for that zone. If an update is received by a secondary DNS server, it will be
forwarded up the replication topology until it reaches the primary DNS server. Note that in the
case of an Active Directory integrated zone, an update for a resource record in a zone may be
sent to any DNS server running on an Active Directory domain controller whose data store
contains the zone.
A zone transfer process will always lock a zone so that a secondary DNS server receives a
consistent zone view while transferring the zone data. When the zone is locked it can no longer
accept dynamic updates. If the zone is large and is locked very often for zone transfer purposes,
it will starve dynamic update clients, and the system can become unstable. The Windows
Server 2003 DNS Server service queues the update requests that arrived during the zone transfer
and processes them after the zone transfer is completed.
How client and server computers update their DNS names
By default, computers that are statically configured for TCP/IP attempt to dynamically register
host (A) and pointer (PTR) resource records for IP addresses configured and used by their
installed network connections. All computers register records based on their fully qualified
domain name (FQDN).
The following defaults also apply to how computers update their DNS names:
• By default, the DNS client on Windows XP does not attempt dynamic update
over a Remote Access Service or virtual private network connection. To
modify this configuration, you can modify the advanced TCP/IP settings of the
particular network connection or modify the registry.

• By default, the DNS client does not attempt dynamic update of top-level
domain (TLD) zones. Any zone named with a single-label name is considered
a TLD zone, for example, com, edu, blank, my-company.

• By default, the primary DNS suffix portion of a computer’s FQDN is the same
as the name of the Active Directory domain to which the computer is joined.
To allow different primary DNS suffixes, a domain administrator may create a
restricted list of allowed suffixes by modifying the msDS-
AllowedDNSSuffixes attribute in the domain object container. This attribute
is managed by the domain administrator using Active Directory Service
Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Dynamic updates can be sent for any of the following reasons or events:
• An IP address is added, removed, or modified in the TCP/IP properties
configuration for any one of the installed network connections.
 • An IP address lease changes or renews with the DHCP server any one of the
installed network connections. For example, when the computer is started or
if the ipconfig /renew command is used.

• The ipconfig /registerdns command is used to manually force a refresh of the

client name registration in DNS.

• At startup time, when the computer is turned on.

• A member server is promoted to a domain controller.

When one of the previous events triggers a dynamic update, the DHCP Client service (not the
DNS Client service) sends updates. This is designed so that if a change to the IP address
information occurs because of DHCP, corresponding updates in DNS are performed to
synchronize name-to-address mappings for the computer. The DHCP Client service performs
this function for all network connections used on the system, including connections not
configured to use DHCP.
The update process described above assumes that installation defaults are in effect for computers
running Windows 2000, Windows XP, or servers running Windows Server 2003. Specific names
and update behavior is tunable where advanced TCP/IP properties are configured to use non-
default DNS settings.
In addition to the full computer name (or primary name) of the computer, additional connection-
specific DNS names can be configured and optionally registered or updated in DNS.
Example: How dynamic update works
Dynamic updates are typically requested when either a DNS name or IP address changes on the
computer. For example, suppose a client named “oldhost” is first configured in System
properties with the following names:

Computer name oldhost

DNS domain name of computer example.microsoft.com

Full computer name oldhost.example.microsoft.com

In this example, no connection-specific DNS domain names are configured for the computer.
Later, the computer is renamed from “oldhost” to “newhost”, resulting in the following name
changes on the system:

Computer name newhost

DNS domain name of computer example.microsoft.com

Full computer name newhost.example.microsoft.com

Once the name change is applied in System properties, you are prompted to restart the
computer. When the computer restarts Windows, the DHCP Client service performs the
following sequence to update DNS:
1. The DHCP Client service sends a start of authority (SOA) type query using the
DNS domain name of the computer.

The client computer uses the currently configured FQDN of the computer
(such as “newhost.example.microsoft.com”) as the name specified in this
query.

2. The authoritative DNS server for the zone containing the client FQDN
responds to the SOA-type query.

For standard primary zones, the primary server (owner) returned in the SOA
query response is fixed and static. It always matches the exact DNS name as
it appears in the SOA RR stored with the zone. If, however, the zone being
updated is directory-integrated, any DNS server that is running on a domain
controller for the Active Directory domain in the FQDN can respond and
dynamically insert its own name as the primary server (owner) of the zone in
the SOA query response.

3. The DHCP Client service then attempts to contact the primary DNS server.

The client processes the SOA query response for its name to determine the IP
address of the DNS server authorized as the primary server for accepting its
name. It then proceeds to perform the following sequence of steps as needed
to contact and dynamically update its primary server:

○ It sends a dynamic update request to the primary server determined in

the SOA query response.

○ If the update succeeds, no further action is taken.

○ If this update fails, the client next sends an NS-type query for the zone
name specified in the SOA record.

○ When it receives a response to this query, it sends an SOA query to the

first DNS server listed in the response.

○ After the SOA query is resolved, the client sends a dynamic update to
the server specified in the returned SOA record.

○ If the update succeeds, no further action is taken.

○ If this update fails, then the client repeats the SOA query process by
sending to the next DNS server listed in the response.

4. Once the primary DNS server that can perform the update is contacted, the
client sends the update request and the DNS server processes it.
 The contents of the update request include instructions to add A (and
possibly PTR) resource records for “newhost.example.microsoft.com” and
remove these same record types for “oldhost.example.microsoft.com”, the
name that was previously registered.

The DNS server also checks to ensure that updates are permitted for the
client request. For standard primary zones, dynamic updates are not secured,
so any client attempt to update succeeds. For Active Directory–integrated
zones, updates are secured and performed using directory-based security
settings. For more information, see “Secure Dynamic Updates” later in this
document.

Dynamic updates are sent or refreshed periodically. By default, computers send a refresh once
every seven days. If the update results in no changes to zone data, the zone remains at its current
version and no changes are written. Updates result in actual zone changes or increased zone
transfer only if names or addresses actually change.
Note that names are not removed from DNS zones if they become inactive or are not updated
within the refresh interval (seven days). DNS does not use a mechanism to release or tombstone
names, although DNS clients do attempt to delete or update old name records when a new name
or address change is applied.
When the DHCP Client service registers A and PTR resource records for a computer, it uses a
default caching Time to Live (TTL) of 15 minutes for host records. This determines how long
other DNS servers and clients cache a computer’s records when they are included in a query
response.
DNS and DHCP Clients and Servers
Windows 2000, Windows XP, and Windows Server 2003 DHCP clients are dynamic update-
aware and can initiate the dynamic update process. A DHCP client negotiates the process of
dynamic update with the DHCP server when the client leases an IP address or renews the lease,
determining which computer updates the A and PTR resource records of the client. Depending
on the negotiation process, the DHCP client, the DHCP server, or both, update the records by
sending the dynamic update requests to the primary DNS servers that are authoritative for the
names that are to be updated.
Clients and servers that are running versions of Windows earlier than Windows 2000 do not
support dynamic update. The Windows 2000 and Windows Server 2003 DHCP Server service
can perform dynamic updates on behalf of clients that do not support the DHCP Client service
FQDN option (which is described in the following section). For example, clients that are running
Microsoft Windows 95, Windows 98, and Windows NT do not support the FQDN option.
However, this functionality can be enabled in the DNS tab of the server properties for the DHCP
console. The DHCP server first obtains the name of legacy clients from the DHCP REQUEST
packet. It then appends the domain name given for that scope and registers the A and PTR
resource records.
In some cases, stale PTR or A resource records can appear on DNS servers when the lease of a
DHCP client expires. For example, when a Windows 2000, Windows XP or Windows
Server 2003 DHCP client tries to negotiate a dynamic update procedure with a Windows NT 4.0
DHCP server, the DHCP client must register both A and PTR resource records itself. Later, if the
Windows 2000, Windows XP or Windows Server 2003 DHCP client is improperly removed
from the network, the client cannot deregister its A and PTR resource records and they become
stale.
If a stale A resource record appears in a zone that allows only secure dynamic updates, no
computer is able to register any other resource record for the name in that A resource record. To
prevent problems with stale PTR and A resource records, you can enable the aging and
scavenging feature. For more information about the aging and scavenging feature, see
“Understanding Aging and Scavenging” in this document.
To provide fault tolerance for dynamic updates, consider Active Directory integration for those
zones that accept dynamic updates from Windows Server 2003 network-based clients. To speed
up the discovery of authoritative DNS servers, you can configure each client with a list of
preferred and alternate DNS servers that are primary for that directory-integrated zone. If a client
fails to update the zone with its preferred DNS server because the DNS server is unavailable, the
client can try an alternate server. When the preferred DNS server becomes available, it loads the
updated, directory-integrated zone that includes the update from the client.
Dynamic Update Process for Network Connections Configured by DHCP
To negotiate the dynamic update process, the DHCP client sends its fully qualified domain name
(FQDN) to the DHCP server in the DHCPREQUEST packet by using the DHCP Client service
FQDN option. The DHCP server then replies to the DHCP client by sending a DHCP
acknowledgment (DHCPACK) message that includes the FQDN option (option code 81).
The table below lists the fields of the FQDN option of the DHCPREQUEST packet.
Fields in the FQDN Option of the DHCPREQUEST Packet

Field Explanation

Code Specifies the code for this option (81).

Len Specifies the length, in octets, of this option (minimum of 4).

Can be one of the following values:

0. Client wants to register the A resource record and requests that the server
update the PTR resource record.
Flags
1. Client wants server to register the A and PTR resource records.
3. DHCP server registers the A and PTR resource records regardless of the
request of the client.

The DHCP server uses these fields to specify the response code from the A and
RCODE1 and
PTR resource records registrations performed on the client’s behalf and to
RCODE 2
indicate whether it attempted the update before sending DHCPACK.

Domain Name Specifies the FQDN of the client.

The conditions under which DHCP clients send the FQDN option and the actions taken by
DHCP servers depend on the operating system that the client and server are running and how the
client and server are configured.
The client requests a dynamic update depending on whether or not it is running Windows
Server 2003 operating system, Windows 2000, or earlier. It also depends on the client
configuration. Clients can take any of the following actions:
• By default, the Windows 2000, Windows XP and Windows Server 2003 DHCP
Client service sends the FQDN option with the Flags field set to 0 to request
that the client update the A resource record, and the DHCP Server service
updates the PTR resource record. After the client sends the FQDN option, it
waits for a response from the DHCP server. Unless the DHCP server sets the
Flags field to 3, the client then initiates an update for the A resource record. If
the DHCP server does not support or is not configured to perform registration
of the DNS record, then no FQDN is included in the DHCP servers response
and the client attempts registration of the A and PTR resource records.

• If the DHCP client is running a Windows operating system earlier than

Windows 2000, or if the client is Windows 2000 and it is configured not to
register DNS resource records, then the client does not send the FQDN
option. In this case, the client does not update either record.

Depending on what the DHCP client requests, the DHCP server can take different actions. If the
DHCP client sends a DHCPREQUEST message without the FQDN option, behavior depends on
the type of DHCP server and how it is configured. The DHCP server can update both records if it
is configured to update records on behalf of DHCP clients that do not support the FQDN option.
In the following cases, the DHCP server does not perform any action:
• The DHCP server does not support dynamic update (for example, a
Windows NT 4.0 server).

• The DHCP server is running Windows 2000 or Windows Server 2003 operating
system and is configured not to do dynamic updates for clients that do not
support the FQDN option.

• The DHCP server is running Windows 2000 or Windows Server 2003 operating
system and configured not to register DNS resource records.

If the Windows 2000, Windows XP or Windows Server 2003 network–based DHCP client
requests that the server updates the PTR resource record but not the A resource record, behavior
depends on the type of DHCP server and how it is configured. The server can perform any of the
following actions:
• If the DHCP server is running Windows 2000 or Windows Server 2003
operating system and is configured not to perform dynamic updates, its
response does not contain the FQDN option and does not update either
resource record. In this case, the DHCP client attempts to update both the A
and PTR resource records, if it capable.

• If the DHCP server is running Windows 2000 or Windows Server 2003

operating system and is configured to update according to the request of the
DHCP client, the server attempts to update the PTR resource record. The
DHCP server DHCPACK message to the DHCP client contains the FQDN option
with the Flags set to 0, confirming that the DHCP server updates the PTR
 record. The DHCP client then attempts to update the A resource record, if it is
capable.

If the DHCP server is running Windows 2000 or Windows Server 2003 operating system and is
configured to always update A and PTR both records, the DHCP server attempts to update both
resource records. The DHCP server DHCPACK message to the DHCP client contains the FQDN
option with the Flags set to 3, notifying the DHCP client that the DHCP server updates A and
PTR records. In this case, the DHCP client does not attempt to update either resource record.
Dynamic Update Process for Statically Configured and Remote Access
Clients
Statically configured clients and remote access clients do not rely on the DHCP server for DNS
registration. Statically configured clients dynamically update their A and PTR resource records
every time they start and then every 24 hours in case the records become corrupted or need to be
refreshed in the DNS database.
Remote access clients can dynamically update A and PTR resource records when a dial-up
connection is made. They can also attempt to withdraw, or deregister, the A and PTR resource
records when the user closes down the connection explicitly. Computers running Windows 2000
or Windows Server 2003 operating system with a remote access network connection attempt the
dynamic registration of the A and PTR records corresponding to the IP address of this
connection. By default, the DNS Client service on Windows XP does not attempt dynamic
update over a Remote Access Service (RAS) or virtual private network (VPN) connection. To
modify this configuration, you can modify the advanced TCP/IP settings of the particular
network connection or modify the registry.
In all operating systems, if a remote access client does not receive a successful response from the
attempt to deregister a DNS resource record, or if for any other reasons fails to deregister a
resource record within four seconds, the DNS client closes the connection. In such cases, the
DNS database might contain a stale record.
If the remote access client fails to deregister a DNS resource record, it adds a message to the
event log, which you can view by using Event Viewer. The remote access client never deletes
stale records, but the remote access server attempts to deregister the PTR resource record when
the client is disconnected.
Windows 2000 dial-up networking clients attempt to register A and PTR records for the dial-up
connection. By default, the Windows XP and Windows Server 2003 DNS Client service dial-up
networking clients do not attempt to update A and PTR records automatically. Due to the nature
of their business, it is common that ISPs do not enable dynamic updating of DNS information by
their customers. If you use an ISP that does not support dynamic update, configure the
connection properties to prevent the computer from performing dynamic updates.
Dynamic Update Process for Multihomed Clients
If a dynamic update client is multihomed (has more than one network connection and associated
IP address), it registers the first IP address for each network connection by default. If you do not
want it to register these IP addresses, you can configure the network connection to not register IP
addresses.
The dynamic update client does not register all IP addresses with the DNS servers in all
namespaces that the computer is connected to. For example, a multihomed computer,
client1.noam.example.com, is connected to both the Internet and the corporate intranet. Client1
is connected to the intranet by adapter A, a DHCP adapter with the IP address 172.16.8.7.
Client1 is also connected to the Internet by adapter B, a remote access adapter with the IP
address 10.3.3.9. Client1 resolves intranet names by using a name server on the intranet,
NoamDC1, and resolves Internet names by using a name server on the Internet, ISPNameServer.
Time to Live
Whenever a dynamic update client registers in DNS, the associated A and PTR resource records
include the Time to Live (TTL), which by default is set to 10 minutes for records registered by
the Net Logon service, and 15 minutes for records registered by the DHCP Client service. If the
DNS Server service dynamically registers records for its own zones, the default TTL is 20
minutes. You can change the default setting in the registry. A small value causes cached entries
to expire sooner, which increases DNS traffic but decreases the risk of cached records becoming
outdated. Expiring entries quickly is useful for computers that frequently renew their DHCP
leases. Long retention times are useful for computers that renew their DHCP leases infrequently.
Resolving Name Conflicts
When the DNS Client service attempts to register an A record and it discovers that the
authoritative DNS zone already contains an A record for the same name but with a different IP
address, by default, the DNS Client service attempts to replace the existing A record (s) with the
new A record containing the IP address of the DNS client. As a result, any computer on the
network can modify the existing A record unless secure dynamic update is used. Zones that are
configured for secure dynamic update allow only authorized users to modify the resource record.
You can change the default setting so that the DNS Client service aborts the registration process
and logs the error in Event Viewer, instead of replacing the existing A record.
Secure Dynamic Update
DNS update security is available only for zones that are integrated into Active Directory. Once
you directory-integrate a zone, access control list (ACL) editing features are available in the
DNS console so you can add or remove users or groups from the ACL for a specified zone or
resource record. ACLs are for DNS administration access control only, and do not influence
DNS query resolution.
By default, dynamic update security for DNS servers and clients are handled as follows:
• DNS clients attempt to use unsecured dynamic update first. If an unsecured
update is refused, clients try to use secure update.

Also, clients use a default update policy that permits them to attempt to
overwrite a previously registered resource record, unless they are specifically
blocked by update security.

• Once a zone becomes Active Directory–integrated, DNS servers running

Windows Server 2003 default to allowing only secure dynamic updates.

When using standard zone storage, the default for the DNS Server service is
to not allow dynamic updates on its zones. For zones that are either
directory-integrated or use standard file-based storage, you can change the
zone to allow all dynamic updates which permits all updates to be accepted.
 Dynamic update is a recent additional DNS standard specification, defined in
RFC 2136. For more information about RFCs, see “Related Information” at the
end of this document.

The dynamic registration of DNS resource records can be restricted with the
use of registry entries.

How secure dynamic update works

The secure dynamic update process is described below:
• To initiate a secure dynamic update, the DNS client first initiates the security
context negotiation process, during which the tokens are passed between
client and server using TKEY resource records. At the end of the negotiation
process the security context is established.

• Next, the DNS client sends the dynamic update request (containing resource
records for the purpose of adding, deleting, or modifying data) to the DNS
server, signed using the previously established security context and passing
the signature in the TSIG resource record, included in the dynamic update
packet.

• The server attempts to update Active Directory using the clients credentials
and sends the result of the update to the client. These results are signed
using the security context and pass the signature in the TSIG resource record
included in the response.

Secure dynamic update process

The secure dynamic update process is described below:
1. The DNS client queries the preferred DNS server to determine which DNS
server is authoritative for the domain name it is attempting to update. The
preferred DNS server responds with the name of the zone and the primary
DNS server that is authoritative for the zone.

2. The DNS client attempts a standard dynamic update, and if the zone is
configured to allow only secure dynamic updates (the default configuration
for Active Directory-integrated zones), the DNS server refuses the non-secure
update. Had the zone been configured for standard dynamic update rather
than secure dynamic update, the DNS server would have accepted the DNS
client’s attempt to add, delete, or modify resource records in that zone.

3. The DNS client and DNS server begin TKEY negotiation.

4. First, the DNS client and DNS server negotiate an underlying security
mechanism. Windows dynamic update clients and DNS servers can only use
the Kerberos protocol.

5. Next, by using the security mechanism, the DNS client and DNS server verify
their respective identities and establish the security context.
 6. The DNS client sends the dynamic update request to the DNS server, signed
using the established security context . The signature is included in the
signature field of the TSIG resource record that is included in the dynamic
update request packet. The DNS server verifies the origin of the dynamic
update packet by using the security context and the TSIG signature.

7. The DNS server attempts to add, delete, or modify resource records in Active
Directory. Whether or not it can make the update depends on whether the
DNS client has the proper permissions to make the update and whether the
prerequisites have been satisfied.

8. The DNS server sends a reply to the DNS client stating whether or not it was
able to make the update, signed using the established security context. The
signature is included in the signature field of the TSIG resource record that is
included in the dynamic update response packet. If the DNS client receives a
spoofed reply, it ignores it and waits for a signed response.

Note

○ DHCP clients running Windows 2000, Windows XP, or Windows

Server 2003 explicitly request that the DHCP server update only
pointer (PTR) resource records used in DNS for the reverse lookup and
resolution of the client’s IP address to its name. These clients update
their address (A) resource records for themselves.

○ Clients running earlier versions of Windows cannot make an explicit

request for DNS dynamic update protocol preference. For these clients,
the DHCP service updates both the PTR and the A resource records.

Security for DHCP Clients That Do Not Support the FQDN Option
Windows DHCP clients that do not support the FQDN option (option 81) are not capable of
dynamic updates. If you want the A and PTR resource records for these clients dynamically
registered in DNS, you must configure the DHCP server to perform dynamic updates on their
behalf.
However, having the DHCP server to perform secure dynamic updates on behalf of DHCP
clients that do not support the FQDN option is undesirable because when a DHCP server
performs a secure dynamic update on a name, that DHCP server becomes the owner of that
name, and only that DHCP server can update any record for that name. This can cause problems
in a few different circumstances.
For example, suppose that the DHCP server DHCP1 created an object for the name
nt4host1.example.com and then stopped responding, and that later the backup DHCP server,
DHCP2, tried to update a record for the same name, nt4host1.example.com. In this situation,
DHCP2 is not able to update the name because it does not own the name. In another example,
suppose DHCP1 added an object for the name nt4host1.example.com, and then the administrator
upgraded nt4host1.example.com to a Windows 2000-based computer. Because the
Windows 2000-based computer did not own the name, it would not be able to update DNS
records for the name.
To solve this problem, the built-in security group called DnsUpdateProxy is provided. If all
DHCP servers are added as members of the DnsUpdateProxy group, one servers records can be
updated by another server if the first server fails. Also, because all objects created by the
members of the DnsUpdateProxy group are not secured, the first user (that is not a member of
the DnsUpdateProxy group) to modify the set of records associated with a DNS name becomes
its owner. When legacy clients are upgraded, they can therefore take ownership of their name
records at the DNS server. If every DHCP server registering resource records for older clients is
a member of the DnsUpdateProxy group, the problems discussed earlier are eliminated.
Securing records when using the DnsUpdateProxy group
DNS domain names that are registered by the DHCP server are not secure when the DHCP
server is a member of the DnsUpdateProxy group. As a result, do not use this group in an Active
Directory integrated-zone that allows only secure dynamic updates without taking additional
steps to allow records created by members of the group to be secured.
To protect against unsecured records, or to allow members of the DnsUpdateProxy group to
register records in zones that allow only secured dynamic updates, Windows Server 2003 DHCP
and DNS allow you to create a dedicated user account and configure DHCP servers to perform
DNS dynamic updates with the user account credentials (user name, password, and domain). The
credentials of one dedicated user account can be used by multiple DHCP servers.
The dedicated user account is a standard user account used only is supplying DHCP servers with
credentials for DNS dynamic update registrations. Each DHCP server supplies these credentials
when registering names on behalf of DHCP clients using DNS dynamic update. The dedicated
user account is created in the same forest where the primary DNS server for the zone to be
updated resides. The dedicated user account can also be located in another forest as long as the
forest it resides in has a forest trust established with the forest containing the primary DNS server
for the zone to be updated.
When installed on a domain controller, the DHCP Server service inherits the security
permissions of the domain controller and has the authority to update or delete any DNS record
that is registered in a secure Active Directory-integrated zone (this includes records that were
securely registered by other computers running Windows 2000 or Windows Server 2003,
including domain controllers). When installed on a domain controller, configure the DHCP
server with the credentials of the dedicated user account to prevent the server from inheriting,
and possibly misusing, the power of the domain controller.
Configure a dedicated user account and configure the DHCP Server service with the account
credentials under the following circumstances:
• A domain controller is configured to function as a DHCP server.

• The DHCP server is configured to perform DNS dynamic updates on behalf of

DHCP clients.

• The DNS zones to be updated by the DHCP server are configured to allow
only secure dynamic updates.

Once you have created a dedicated user account, you can configure DHCP servers with the user
account credentials by using the DHCP console or by using the Netsh command (netsh dhcp
server set dnscredentials).
Note
• If the supplied credentials belong to an object (such as a computer) that is a
member of the DnsUpdateProxy security group, the next object to register
the same name record in DNS will become the record owner.

• If you have specified credentials (user name, domain, and password) that the
DHCP server uses when registering DHCP client computers in DNS, these
credentials are not backed up with either synchronous or asynchronous
backup. After a DHCP database is restored, new credentials must be
configured.

Controlling Update Access to Zones and Names

Access to the DNS zones and resource records stored in Active Directory is controlled access
control lists (ACLs). ACLs can be specified for the DNS Server service, an entire zone or for
specific DNS names. By default, any authenticated Active Directory user can create the A or
PTR resource records in any zone. Once an owner name has been created for a zone (regardless
of the type of resource record), only the users or groups specified in the ACL for that name that
have write permission are enabled to modify records corresponding to that name. While this
approach is desirable in most scenarios, some special situations need to be considered separately.
DNSAdmins group
By default, the DNSAdmins group has full control of all zones and records in the Windows
Server 2003 domain in which it is specified. In order for a user to be able to enumerate zones in a
specific Windows Server 2003 domain, the user (or a group the user belongs to) must be enlisted
in the DNSAdmin group.
It is possible that a domain administrator may not want to grant full control to all users listed in
the DNSAdmins group. Typically, this would be the result if a domain administrator wanted to
grant full control for a specific zone and read only control for other zones in the domain to a set
of users. To accomplish this, the domain administrator can create a separate group for each of the
zones, and add specific users to each group. Then the ACL for each zone will contain a group
with full control for that zone only. At the same time, all of the groups will be included in the
DNSAdmins group, which can be configured to have read permissions only. As a result of the
fact that a zone’s ACL always contains the DNSAdmins group, all users enlisted in the zone-
specific groups will have read permission for all the zones in the domain.
Reserving names
The default DNS Server service configuration of allowing any authenticated user to create a new
name in a zone may not be sufficient for environments that require a high level of security. In
such cases, the default ACL can be changed to allow for the creation of objects in a zone by
certain groups or users only. Per-name administration of ACLs provides another solution to this
problem. An administrator may reserve a name in a zone leaving the rest of the zone open for the
creation of any new objects by all authenticated users. To accomplish this, an administrator
creates a record for the reserved name and sets the appropriate list of groups or users in the ACL.
As a result, only the users listed in the ACL will be able to register another record under the
reserved name.
Understanding Aging and Scavenging
DNS servers running Windows Server 2003 support aging and scavenging features. These
features are provided as a mechanism for performing cleanup and removal of stale resource
records (RRs), which can accumulate in zone data over time.
With dynamic update, RRs 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) RR at startup and is later
improperly disconnected from the network, its host (A) RR might not be deleted. If your network
has mobile users and computers, this situation can occur frequently.
If left unmanaged, the presence of stale RRs in zone data might cause some problems. The
following are examples:
• If a large number of stale RRs remain in server zones, they can eventually
take up server disk space and cause unnecessarily long zone transfers.

• DNS servers loading zones with stale RRs might use outdated information to
answer client queries, potentially causing the client’s to experience name
resolution problems on the network.

• The accumulation of stale RRs at the DNS server can degrade its performance
and responsiveness.

• In some cases, the presence of a stale RR in a zone could 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 set at the server
computer, for any RRs added dynamically to primary-type zones. In addition,
time stamps are recorded in standard primary zones where aging/scavenging
is enabled.

• For RRs that you add manually, a time stamp value of zero is used, indicating
that they are not affected by the aging process and can remain without
limitation in zone data unless you otherwise change their time stamp or
delete them.

• Aging of RRs 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 RRs that persist beyond the specified refresh period.
When a DNS server performs a scavenging operation, it can determine that
RRs have aged to the point of becoming stale and remove them from zone
data. Servers can be configured to perform recurring scavenging operations
automatically, or you can initiate an immediate scavenging operation at the
server.

Note

○ By default, the aging and scavenging mechanism for the DNS Server
service is disabled. It should only be enabled when all parameters are
 fully understood. Otherwise, the server could 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 the record and take ownership of it,
even on zones configured for secure dynamic update.

The server uses the contents of each RR-specific time stamp, along with other aging/scavenging
properties that you can adjust or configure, to determine when it scavenges records.
Prerequisites for Aging and Scavenging
Before the aging and scavenging features of DNS can be used, 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 added dynamically using the DNS dynamic update
protocol are subject to aging and scavenging.
You can, however, enable scavenging for other resource records added through non-dynamic
means. For records 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/scavenging operations.
In order to change this default, you can administer these records individually, to reset and permit
them to use a current (non-zero) time stamp value. This enables these records to become aged
and scavenged.
Note
• In the case of changing a zone from standard primary to Active Directory–
integrated, you might 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 list indicates new or revised terms that have been introduced to help specifically
when discussing aging and scavenging.
Current server time The current date and time on the DNS server. This number can be
expressed as an exact numeric value at any point in time.
No-refresh interval An interval of time, determined for each zone, as bounded by the following
two events:
• The date and time when the record was last refreshed and its time stamp set.

• 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.
Record refresh When a DNS dynamic update is processed for a resource record when only the
resource record time stamp, and no other characteristics of the record, are revised. Refreshes
generally occur for the following reasons:
• 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 prior to being shut down, it sends a refresh to renew its
associated resource records for this information.

• A periodic refresh is sent by the computer while it is running.

• The Windows XP and Windows Server 2003 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, then it is considered to be a refresh and not a resource
record update.

• 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 used by Active Directory domain controllers.

Record update When a DNS dynamic update is processed for a resource record where other
characteristics of the record in addition to its time stamp are revised. Updates generally occur for
the following reasons:
• 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.

• 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.

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

Refresh interval An interval of time, determined for each zone, as bounded by the following
two distinct events:
• The earliest date and time when the record becomes eligible to be refreshed
and have its time stamp reset.

• 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.
Resource record (RR) time stamp A date and time value used by the DNS server to determine
removal of the resource record when it performs aging and scavenging operations.
Scavenging period When automatic scavenging is enabled at the server, this period represents
the 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.
Scavenging servers An optional advanced zone parameter that enables you to specify a
restricted list 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 enabled to scavenge the zone in the ScavengingServers
parameter for the zone. This can be done using the dnscmd command, a command-line based
tool for administering Windows DNS servers.
Start scavenging time A specific time, expressed as a number. This time is used by the server to
determine when a zone becomes available for scavenging.
When Scavenging Can Start
Once all prerequisites for enabling the use of scavenging are met, scavenging 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 any 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 the DNS console to modify this setting at either an
applicable DNS server or one of its primary zones.

• The DNS server loads a primary zone 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.

When any of 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 of 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/scavenging is
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 prior to 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.

Once 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 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
for the directory-integrated “example.microsoft.com” zone.
Unicode Character Support
Originally, Internet host names were restricted to the character set specified in RFCs 952 and
1123. These restrictions include limiting names to using uppercase and lowercase letters (A-“Z”,
a-z), numbers (0-9) and hyphens (-). In addition, the first character of the DNS name can be a
number and names must be encoded and represented using US-ASCII-based characters.
These requirements were maintained when DNS was introduced as part of RFC 1035, one of the
core DNS standards specifications. For use of DNS in international settings, this requirement has
significant limitations where extended character sets are used for local naming standards.
To remove these limitations, Microsoft expands DNS character support beyond the RFC 1035
specification. The DNS service now provides enhanced default support for UTF-8, a Unicode
transformation format.
What is UTF-8?
UTF-8 is the recommended character set for protocols evolving beyond the use of ASCII. The
UTF-8 protocol provides for support of extended ASCII characters and translation of UCS-2, a
16-bit Unicode character set that encompasses most of the world’s writing systems. UTF-8
enables a far greater range of names than can be achieved using ASCII or extended ASCII
encoding for character data.
Computers running Windows 2000, Windows XP, and Windows Server 2003 operating systems
are UTF-8 aware. This means that when UTF-8 encoded characters are received or used as data
by the server, the server can load and store this data in its zones. Although Windows-based DNS
servers are UTF-8 aware, they remain compatible with other DNS servers that use traditional
US-ASCII data encoding and current DNS standards.
How the DNS Service Implements UTF-8
To provide standards compatibility and interoperability with other DNS implementations, the
DNS service uses uniform downcasing of any received character data. In this process, the DNS
service converts all uppercase characters used in standard US-ASCII data to lowercase
equivalent data for the following reasons:
• To maintain compatibility with current and existing DNS standards.

• To provide interoperability with DNS server implementations that do not

recognize or support UTF-8 encoding.

To understand why uniform downcasing was chosen, several related points must first be
considered from the current revised Internet standards for DNS. Several key points in the
standards pertain directly to how character data is to be handled between DNS servers and other
servers and clients. These include the following:
• Any binary string can be used in a DNS name. (RFC 2181)

• DNS servers must be able to compare names in a case-insensitive way. (RFC

1035)

• The original case for character data should be preserved whenever possible
as the data is entered into the system. (RFC 1035)
Because case insensitivity is a required part of the core DNS standard and case preservation is an
optional recommendation, uniform downcasing was chosen to provide an effective standards-
compliant solution. By downcasing UTF-8 encoded names before transmission, other DNS
servers (which are not UTF-8 aware) are able to receive and perform successful binary
comparisons of the data and obtain the desired results.
Considerations for Interoperability With UTF-8
The DNS Server service can be configured to allow or disallow the use of UTF-8 characters on a
per-server basis. Although other DNS server implementations that are not UTF-8 aware might be
able to accept the transfer of a zone containing UTF-8 encoded names, these servers might not be
able to write back those names to a zone file or reload those names from a zone file.
Administrators should exercise caution when transferring a zone containing UTF-8 names to a
DNS server that is not UTF-8-aware.
Some protocols place restrictions on the characters allowed in a name. In addition, names that
are intended to be globally visible (RFC 1958) should contain ASCII-only characters, as
recommended in RFC 1123.
The use of UTF-8 for transformation of Unicode characters is not noticeable for general users.
Only where Network Monitor or another similar tool is used to analyze DNS-related traffic over
the physical network are UTF-8 encoded characters observable.
In addition to DNS server support for the UTF-8 encoding format, the client resolver defaults to
using the UTF-8 character encoding format.
Names encoded in UTF-8 format must not exceed the size limits clarified in RFC 2181, which
specifies a maximum of 63 octets per label and 255 octets per name. Character count is
insufficient to determine size because some UTF-8 characters exceed one octet in length.
The UTF-8 encoding protocol adapts to use with existing DNS protocol implementations that
expect US-ASCII characters because representation of US-ASCII characters in UTF-8 is
identical, byte for byte, to the US-ASCII representation. DNS client or server implementations
that do not recognize UTF-8 characters always encode names in the US-ASCII format. Those
names are correctly interpreted by the DNS Server service.
The DNS service provides the ability to configure name checking to allow or restrict the use of
UTF-8 characters in DNS data.
By default, multibyte UTF-8 name checking is used, allowing the greatest tolerance when the
DNS service processes characters. This is the preferred name-checking method for most
privately operated DNS servers that are not providing name service for Internet hosts.
WINS Lookup Integration
Support for using Windows Internet Name Service (WINS) is provided to look up DNS names
that cannot be resolved by querying the DNS domain namespace. To accomplish WINS lookup,
two specific resource record types are used and can be enabled for any zones loaded by the DNS
service:
• The WINS resource record, which can be enabled to integrate WINS lookup
into forward lookup zones

• The WINS-R resource record, which can be enabled to integrate node adapter
status request for reverse lookup zones
WINS Resource Record
The WINS and DNS services are used to provide name resolution for the NetBIOS namespace
and the DNS domain namespace, respectively. Although both DNS and WINS can provide a
separate and useful name service to clients, WINS is mainly needed to provide support for older
clients and programs that require support for NetBIOS naming.
However, the DNS service can work with WINS to provide combined name searches in both
namespaces when resolving a DNS domain name not found in zone information. To provide this
interoperability, a new record (the WINS record) was defined as part of the zone database file.
The WINS resource record is specific to computers running Windows NT 4.0 and earlier,
Windows 2000, and Windows Server 2003 operating systems and can be attached only to the
domain of origin for a zone. The presence of a WINS resource record can instruct the DNS
service to use WINS to look up any forward queries for host names or names that are not found
in the zone database. This functionality is particularly useful for name resolution required by
clients that are not WINS-aware (for example, UNIX) for the names of computers not registered
with DNS, such as Windows 95 or Windows 98 computers.
How WINS Lookup Works
The following is an example of a DNS client (host-b)querying its DNS server in an attempt to
look up the address for another computer named “host-a.example.microsoft.com.”
WINS Lookup

In Step 1, the client queries its preferred DNS server. In Steps 2 through 8, the normal process of
recursion proceeds as the preferred DNS server queries other DNS servers in succession on
behalf of the client. This process concludes at Step 8, when the DNS server for the
example.microsoft.com zone is located through the previous chain of referral answers. At this
point in the process, the server contacted is a DNS server either running Windows NT
Server 4.0, Windows 2000, or Windows Server 2003.
When the DNS server for the example.microsoft.com zone receives the query for host-a, it looks
in its configured zone to see if a matching address (A) resource record (RR) can be found. If no
A record is found and the zone is enabled to use WINS lookup, the server does the following:
• The DNS server separates the host part of the name (host-a) from the fully
qualified domain name contained in the DNS query.

The host part of the name is the first label in the queried DNS domain name
before a period is used in the name.

• The server then sends a NetBIOS name request to the WINS server using the
host name, host-a.

• If the WINS server can resolve the name, it returns the IP address to the DNS
server.
 • The DNS server then compiles an A resource record using the IP address
resolved through the WINS server and returns this record to the original
preferred DNS server that was queried by the requesting client, host-b.

• The preferred DNS server then passes the query answer back to the
requesting client.

How WINS Reverse Lookup Works

There is also a WINS-R record or WINS reverse lookup entry that can be enabled and added to
reverse lookup zones. However, because the WINS database is not indexed by IP address, the
DNS service cannot send a reverse name lookup to WINS to get the name of a computer given
its IP address.
Because WINS does not provide reverse lookup capability, the DNS service instead sends a node
adapter status request directly to the IP address implied in the DNS reverse query. When the
DNS server gets the NetBIOS name from the node status response, it appends the DNS domain
name back onto the NetBIOS name provided in the node status response and forwards the result
to the requesting client.
Note
• WINS and WINS-R resource records are proprietary to the DNS Server service
provided by Windows. You can prevent these resource records from being
included in zone transfers to other DNS server implementations. For more
information, see “How WINS Lookup Works” in this section.

Network Ports Used By DNS

During DNS resolution, DNS messages are sent from DNS clients to DNS servers or between
DNS servers. Messages are sent over UDP and DNS servers bind to UDP port 53. When the
message length exceeds the default message size for a User Datagram Protocol (UDP) datagram
(512 octets), the first response to the message is sent with as much data as the UDP datagram
will allow, and then the DNS server sets a flag indicating a truncated response. The message
sender can then choose to reissue the request to DNS server using TCP (over TCP port 53). The
benefit of this approach is that it takes advantage of the performance of UDP but also has a
backup failover solution for longer queries.
In general, all DNS queries are sent from a high-numbered source port (above 1023) to
destination port 53, and responses are sent from source port 53 to a high-numbered destination
port. The following table lists the UDP and TCP ports used for different DNS message types.
UDP and TCP Port Assignments for DNS Servers

Source of Destination of Destination

Traffic Type Source Port
Transmission Transmission Port

Queries from local Any port number Any remote DNS

Local DNS server 53
DNS server above 1023 server

Responses to local Any remote DNS 53 Local DNS server Any port number
DNS server server above 1023

Queries from remote Any remote DNS Any port number

Local DNS server 53
DNS server server above 1023

Responses to remote Any remote DNS Any port number

Local DNS server 53
DNS server server above 1023

Note
• The Windows Server 2003 DNS Server service supports Extension
Mechanisms for DNS (EDNS0 as defined in RFC 2671), which allow DNS
requestors to advertise the size of their UDP packets and facilitate the
transfer of packets larger than 512 bytes. When a DNS server receives a
request over UDP, it identifies the requestor’s UDP packet size from the
option (OPT) resource record and scales its response to contain as many
resource records as are allowed in the maximum UDP packet size specified
by the requestor.

• Windows Server 2003 DNS support for EDNS0 is enabled by default. It can be
disabled using the registry. Locate the following registry subkey:

• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

• Add the entry EnableEDNSProbes to the subkey. Give the entry a DWORD
value and set it to 0x0 to disable EDNS0.

• Use extreme caution when editing the registry Modifications to the registry
are not validated by the registry editor or by Windows before they are
applied, and as a result, incorrect values can be stored. This can result in
unrecoverable errors in the system.