Domain Name System (DNS) is the default name resolution
service used in a Microsoft Windows Server 2003 network. DNS is part of
the Windows Server 2003 TCP/IP protocol suite and all TCP/IP network
connections are, by default, configured with the IP address of at least
one DNS server in order to perform name resolution on the network.
Windows Server 2003 components that require name resolution will attempt
to use this DNS server before attempting to use the previous default
Windows name resolution service, Windows Internet Name Service (WINS).
Typically, Windows Server 2003 DNS is deployed in support of
Active Directory directory service. In this environment, DNS namespaces
mirror the Active Directory forests and domains used by an organization.
Network hosts and services are configured with DNS names so that they
can be located in the network, and they are also configured with DNS
servers that resolve the names of Active Directory domain controllers.
Windows Server 2003 DNS is also commonly deployed as a
non-Active Directory, or standard, Domain Name System solution, for the
purposes of hosting the Internet presence of an organization, for
example.
DNS architecture is a hierarchical distributed database and an associated set of protocols that define:
-
A mechanism for querying and updating the database.
-
A mechanism for replicating the information in the database among servers.
-
A schema of the database.
DNS originated in the early days of the Internet when the
Internet was a small network established by the United States Department
of Defense for research purposes. The host names of the computers in
this network were managed through the use of a single HOSTS file located
on a centrally administered server. Each site that needed to resolve
host names on the network downloaded this file. As the number of hosts
on the Internet grew, the traffic generated by the update process
increased, as well as the size of the HOSTS file. The need for a new
system, which would offer features such as scalability, decentralized
administration, support for various data types, became more and more
obvious.
The Domain Name System introduced in 1984 became this new
system. With DNS, the host names reside in a database that can be
distributed among multiple servers, decreasing the load on any one
server and providing the ability to administer this naming system on a
per-partition basis. DNS supports hierarchical names and allows
registration of various data types in addition to host name to IP
address mapping used in HOSTS files. Because the DNS database is
distributed, its potential size is unlimited and performance is not
degraded when more servers are added.
The original DNS was based on Request for Comment (RFC) 882
(“Domain Names: Concepts and Facilities”) and RFC 883 (Domain
Names–Implementation and Specification), which were superseded by RFC
1034 (“Domain Names–Concepts and Facilities”), and RFC 1035 (“Domain
Names–Implementation and Specification”). Additional RFCs that describe
DNS security, implementation, and administrative issues later augmented
the original design specifications.
The implementation of DNS — Berkeley Internet Name Domain
(BIND) — was originally developed for the 4.3 BSD UNIX Operating System.
The Microsoft implementation of DNS became a part of the operating
system in Microsoft Windows NT Server 4.0. The Windows NT 4.0 DNS
server, like most DNS implementations, has its roots in RFCs 1034 and
1035.
The RFCs used in Microsoft Windows 2000 and Windows
Server 2003 operating systems are 1034, 1035, 1886, 1996, 1995, 2136,
2308, and 2052.
DNS Domain Names
The Domain Name System is implemented as a hierarchical and
distributed database containing various types of data, including host
names and domain names. The names in a DNS database form a hierarchical
tree structure called the domain namespace. Domain names consist of
individual labels separated by dots, for example:
mydomain.microsoft.com.
A Fully Qualified Domain Name (FQDN) uniquely identifies
the hosts position within the DNS hierarchical tree by specifying a list
of names separated by dots in the path from the referenced host to the
root. The next figure shows an example of a DNS tree with a host called
mydomain within the microsoft.com. domain. The FQDN for the host would
be mydomain.microsoft.com
.
Understanding the DNS Domain Namespace
The DNS domain namespace, as shown in the following
figure, is based on the concept of a tree of named domains. Each level
of the tree can represent either a branch or a leaf of the tree. A
branch is a level where more than one name is used to identify a
collection of named resources. A leaf represents a single name used once
at that level to indicate a specific resource.
DNS Domain Name Hierarchy
The previous figure shows how Microsoft is assigned
authority by the Internet root servers for its own part of the DNS
domain namespace tree on the Internet. DNS clients and servers use
queries as the fundamental method of resolving names in the tree to
specific types of resource information. This information is provided by
DNS servers in query responses to DNS clients, who then extract the
information and pass it to a requesting program for resolving the
queried name. In the process of resolving a name, keep in mind that DNS
servers often function as DNS clients, querying other servers in order
to fully resolve a queried name.
How the DNS Domain Namespace Is Organized
Any DNS domain name used in the tree is technically a
domain. Most DNS discussions, however, identify names in one of five
ways, based on the level and the way a name is commonly used. For
example, the DNS domain name registered to Microsoft (microsoft.com.) is
known as a second-level domain. This is because the name has two parts
(known as labels) that indicate it is located two levels below the root
or top of the tree. Most DNS domain names have two or more labels, each
of which indicates a new level in the tree. Periods are used in names to
separate labels.
The five categories used to describe DNS domain names by
their function in the namespace are described in the following table,
along with an example of each name type.
Types of DNS Domain Names
|
Name Type
|
Description
|
Example
|
Root domain
|
This is the top of the tree, representing an
unnamed level; it is sometimes shown as two empty quotation marks (""),
indicating a null value. When used in a DNS domain name, it is stated by
a trailing period (.) to designate that the name is located at the root
or highest level of the domain hierarchy. In this instance, the DNS
domain name is considered to be complete and points to an exact location
in the tree of names. Names stated this way are called fully qualified
domain names (FQDNs).
|
A single period (.) or a period used at the end of a name, such as “example.microsoft.com.”
|
Top level domain
|
A name used to indicate a country/region or the type of organization using a name.
|
““.com”, which indicates a name registered to a business for commercial use on the Internet.
|
Second level domain
|
Variable-length names registered to an individual
or organization for use on the Internet. These names are always based
upon an appropriate top-level domain, depending on the type of
organization or geographic location where a name is used.
|
““microsoft.com. ”, which is the second-level domain name registered to Microsoft by the Internet DNS domain name registrar.
|
Subdomain
|
Additional names that an organization can create
that are derived from the registered second-level domain name. These
include names added to grow the DNS tree of names in an organization and
divide it into departments or geographic locations.
|
““example.microsoft.com. ”, which is a fictitious subdomain assigned by Microsoft for use in documentation example names.
|
Host or resource name
|
Names that represent a leaf in the DNS tree of
names and identify a specific resource. Typically, the leftmost label of
a DNS domain name identifies a specific computer on the network. For
example, if a name at this level is used in a host (A) RR, it is used to
look up the IP address of computer based on its host name.
|
““host-a.example.microsoft.com.”, where the first label (“host-a”) is the DNS host name for a specific computer on the network.
|
DNS and Internet Domains
The Internet Domain Name System is managed by a Name
Registration Authority on the Internet, responsible for maintaining
top-level domains that are assigned by organization and by
country/region. These domain names follow the International Standard
3166. Some of the many existing abbreviations, reserved for use by
organizations, as well as two-letter and three-letter abbreviations used
for countries/regions are shown in the following table:
Some DNS Top-level Domain Names (TLDs)
|
DNS Domain Name
|
Type of Organization
|
com
|
Commercial organizations
|
edu
|
Educational institutions
|
org
|
Non-profit organizations
|
net
|
Networks (the backbone of the Internet)
|
gov
|
Non-military government organizations
|
mil
|
Military government organizations
|
arpa
|
Reverse DNS
|
“xx”
|
Two-letter country code (i.e. us, au, ca, fr)
|
Resource Records
A DNS database consists of resource records (RRs). Each RR
identifies a particular resource within the database. There are various
types of RRs in DNS. This section provides information about the common
structure of resource records. RRs are discussed in greater detail in
“Resource Records in DNS” later in this document.
The following table provides detailed information about structure of common RRs.
Common DNS Resource Records
|
Description
|
Class
|
Time To Live (TTL)
|
Type
|
Data
|
Start of Authority
|
Internet (IN)
|
Default TTL is 60 minutes
|
SOA
|
Owner Name
Primary Name Server DNS Name, Serial Number
Refresh Interval
Retry Interval
Expire Time
Minimum TTL
|
Host
|
Internet (IN)
|
Record-specific TTL if present, or else zone (SOA) TTL
|
A
|
Owner Name (Host DNS Name)
Host IP Address
|
Name Server
|
Internet (IN)
|
Record-specific TTL if present, or else zone (SOA) TTL
|
NS
|
Owner Name
Name Server DNS Name
|
Mail Exchanger
|
Internet (IN)
|
Record-specific TTL if present, or else zone (SOA) TTL
|
MX
|
Owner Name
Mail Exchange Server DNS Name, Preference Number
|
Canonical Name
(an alias)
|
Internet (IN)
|
Record-specific TTL if present, or else zone (SOA) TTL
|
CNAME
|
Owner Name (Alias Name)
Host DNS Name
|
Distributing the DNS Database: Zone Files and Delegation
A DNS database can be partitioned into multiple zones
. A
zone is a portion of the DNS database that contains the resource
records with the owner names that belong to the contiguous portion of
the DNS namespace. Zone files are maintained on DNS servers. A single
DNS server can be configured to host zero, one or multiple zones.
Each zone is anchored at a specific domain name referred to
as the zone’s root domain. A zone contains information about all names
that end with the zone’s root domain name. A DNS server is considered
authoritative for a name if it loads the zone containing that name. The
first record in any zone file is a Start of Authority (SOA) RR. The SOA
RR identifies a primary DNS name server for the zone as the best source
of information for the data within that zone and as an entity processing
the updates for the zone.
A name within a zone can also be delegated to a different
zone that is hosted on a different DNS server. Delegation is a process
of assigning responsibility for a portion of a DNS namespace to a DNS
server owned by a separate entity. This separate entity could be another
organization, department or workgroup within your company. Such
delegation is represented by the NS resource record that specifies the
delegated zone and the DNS name of the server authoritative for that
zone. Delegating across multiple zones was part of the original design
goal of DNS.
The primary reasons to delegate a DNS namespace include:
-
A need to delegate management of a DNS domain to a number of organizations or departments within an organization.
-
A need to distribute the load of maintaining one large DNS database
among multiple DNS servers to improve the name resolution performance as
well as create a DNS fault tolerant environment.
-
A need to allow for a host’s organizational affiliation by including them in appropriate domains.
The name server (NS) RRs facilitate delegation by
identifying DNS servers for each zone and the NS RRs appear in all
zones. Whenever a DNS server needs to cross a delegation in order to
resolve a name, it will refer to the NS RRs for DNS servers in the
target zone.
In the figure below, the management of the microsoft.com. domain is delegated across two zones, microsoft.com
. and mydomain.microsoft.com.
DNS Delegation
Note
-
If multiple NS records exist for a delegated zone identifying multiple
DNS servers available for querying, the Windows Server 2003 DNS Server
service will be able to select the closest DNS server based on the round
trip intervals measured over time for every DNS server.
Replicating the DNS Database
There could be multiple zones representing the same portion of the namespace. Among these zones there are three types:
Primary is a zone to which all updates for the records that
belong to that zone are made. A secondary zone is a read-only copy of
the primary zone. A stub zone is a read-only copy of the primary zone
that contains only the resource records that identify the DNS servers
that are authoritative for a DNS domain name. Any changes made to the
primary zone file are replicated to the secondary zone file. DNS servers
hosting a primary, secondary or stub zone are said to be authoritative
for the DNS names in the zone.
As mentioned above, a DNS server can host multiple zones. A
DNS server can therefore host both a primary zone (which has the
writeable copy of a zone file) and a separate secondary zone (which
obtains a read-only copy of a zone file). A DNS server hosting a primary
zone is said to be the primary DNS server for that zone, and a DNS
server hosting a secondary zone is said to be the secondary DNS server
for that zone.
Note
-
A secondary or stub zone cannot be hosted on a DNS server that hosts a primary zone for the same domain name.
Zone Transfer
The process of replicating a zone file to multiple DNS
servers is called zone transfer.Zone transfer is achieved by copying the
zone file from one DNS server to a second DNS server. Zone transfers
can be made from both primary and secondary DNS servers.
A master DNS server is the source of the zone
information during a transfer. The master DNS server can be a primary or
secondary DNS server. If the master DNS server is a primary DNS server,
then the zone transfer comes directly from the DNS server hosting the
primary zone. If the master server is a secondary DNS server, then the
zone file received from the master DNS server by means of a zone
transfer is a copy of the read-only secondary zone file.
The zone transfer is initiated in one of the following ways:
-
The master DNS server sends a notification (RFC 1996) to one or more secondary DNS servers of a change in the zone file.
-
When the DNS Server service on the secondary DNS server starts, or the
refresh interval of the zone has expired (by default it is set to 15
minutes in the SOA RR of the zone), the secondary DNS server will query
the master DNS server for the changes.
Types of Zone File Replication
There are two types of zone file replication. The
first, a full zone transfer (AXFR), replicates the entire zone file. The
second, an incremental zone transfer (IXFR), replicates only records
that have been modified. Zone transfer is discussed in detail later in
this document.
BIND 4.9.3 and earlier DNS server software, as well as
Windows NT 4.0 DNS, support full zone transfer (AXFR) only. There are
two types of the AXFR: one requires single record per packet, the other
allows multiple records per packet. The Windows 2000 and Windows
Server 2003 DNS Server service supports both types of zone transfer, but
by default uses multiple records per packet. It can be configured
differently for compatibility with servers that do not allow multiple
records per packet, such as BIND servers versions 4.9.4 and earlier.
Querying the Database
DNS queries can be sent from a DNS client (resolver) to a DNS server, or between two DNS servers.
A DNS query is merely a request for DNS resource records of
a specified resource record type with a specified DNS name. For
example, a DNS query can request all resource records of type A (host)
with a specified DNS name.
There are two types of DNS queries that may be sent to a DNS server:
A recursivequery forces a DNS server to respond to a
request with either a failure or a successful response. DNS clients
(resolvers) typically make recursive queries. With a recursive query,
the DNS server must contact any other DNS servers it needs to resolve
the request. When it receives a successful response from the other DNS
server(s), it then sends a response to the DNS client. The recursive
query is the typical query type used by a resolver querying a DNS server
and by a DNS server querying its forwarder, which is another DNS server
configured to handle requests forwarded to it. For more information
about forwarders, see “Forwarding” later in this document.
When a DNS server processes a recursive query and the query
cannot be resolved from local data (local zone files or cache of
previous queries), the recursive query must be escalated to a root DNS
server. Each standards-based implementation of DNS includes a cache file
(or root server hints) that contains entries for the root DNS servers
of the Internet domains. (If the DNS server is configured with a
forwarder, the forwarder is used before a root server is used.)
An iterative query is one in which the DNS server is
expected to respond with the best local information it has, based on
what the DNS server knows from local zone files or from caching. This
response is also known as a referral if the DNS server is not
authoritative for the name. If a DNS server does not have any local
information that can answer the query, it simply sends a negative
response. A DNS server makes this type of query as it tries to find
names outside of its local domain(s) (when it is not configured with a
forwarder). It may have to query a number of outside DNS servers in an
attempt to resolve the name.
The following figure shows an example of both types of queries.
DNS Query Types
As shown in the graphic above, a number of queries were
used to determine the IP address for www.whitehouse.gov. The query
sequence is described below:
-
Recursive query for www.whitehouse.gov (A resource record)
-
Iterative query for www.whitehouse.gov (A resource record)
-
Referral to the .gov name server (NS resource records, for .gov); for
simplicity, iterative A queries by the DNS server (on the left) to
resolve the IP addresses of the Host names of the name server’s returned
by other DNS servers have been omitted.
-
Iterative query for www.whitehouse.gov (A resource record)
-
Referral to the whitehouse.gov name server (NS resource record, for whitehouse.gov)
-
Iterative query for www.whitehouse.gov (A resource record)
-
Answer to the interative query from whitehouse.gov server (www.whitehouse.gov’s IP address)
-
Answer to the original recursive query from local DNS server to Resolver (www.whitehouse.gov’s IP address)
Time to Live for Resource Records
The Time to Live (TTL) value in a resource record
indicates a length of time used by other DNS servers to determine how
long to cache information for a record before expiring and discarding
it. For example, most resource records created by the DNS Server service
inherit the minimum (default) TTL of one hour from the start of
authority (SOA) resource record, which prevents extended caching by
other DNS servers.
A DNS client resolver caches the responses it receives
when it resolves DNS queries. These cached responses can then be used to
answer later queries for the same information. The cached data,
however, has a limited lifetime specified in the TTL parameter returned
with the response data. TTL ensures that the DNS server does not keep
information for so long that it becomes out of date. TTL for the cache
can be set on the DNS database (for each individual resource record, by
specifying the TTL field of the record and per zone through the minimum
TTL field of the SOA record) as well as on the DNS client resolver side
by specifying the maximum TTL the resolver allows to cache the resource
records.
There are two competing factors to consider when setting
the TTL. The first is the accuracy of the cached information, and the
second is the utilization of the DNS servers and the amount of network
traffic. If the TTL is short, then the likelihood of having old
information is reduced considerably, but it increases utilization of DNS
servers and network traffic, because the DNS client must query DNS
servers for the expired data the next time it is requested. If the TTL
is long, the cached responses could become outdated, meaning the
resolver could give false answers to queries. At the same time, a long
TTL decreases utilization of DNS servers and reduces network traffic
because the DNS client answers queries using its cached data.
If a query is answered with an entry from cache, the TTL
of the entry is also passed with the response. This way the resolvers
that receive the response know how long the entry is valid. The
resolvers honor the TTL from the responding server; they do not reset it
based on their own TTL. Consequently, entries truly expire rather than
live in perpetuity as they move from DNS server to DNS server with an
updated TTL.
Note
-
In general, never configure the TTL to zero. The different between a
setting of 0 or 60 is minimal to the accuracy of the record, but when
the TTL is set to 0 there is a major impact on DNS server performance
because the DNS server is constantly querying for the expired data.
Updating the DNS Database
Since the resource records in the zone files are subjected
to changes, they must be updated. The implementation of DNS in
Windows 2000 and Windows Server 2003 supports both static and dynamic
updates of the DNS database. The details of the dynamic update are
discussed later in this document.
DNS Architecture Diagrams
The following diagrams illustrate how the DNS Client and
Server services work and provide additional information regarding name
resolution, update, and administration operations.
The first diagram illustrates the DNS Client service
architecture in its name resolution and update operations. In this
diagram, name resolution architecture is demonstrated using a Web
browser and Microsoft Outlook and updates are represented by the DHCP
client.
DNS Client Service Architecture
The following diagram illustrates the DNS Server service
architecture with its administration tools and the Windows Management
Instrumentation (WMI) interface.
DNS Server Service Architecture
The dynamic update response message follows the same
format as the DNS update message, with the exception of the DNS flags.
The dynamic update response message header flags indicate whether or not
the update is successful by including the successful response code or
one of the error codes described in DNS update message flags above.
The logical structure of Windows Server 2003 DNS involves DNS
namespace partitioning, which extends the DNS domain name hierarchy
into multiple subdomains. The physical structure of DNS involves
distributing the DNS database using DNS servers to host DNS zones for
the subdomains of the DNS domain name hierarchy. Both the DNS Client and
Server service applications manage the physical DNS data in the DNS
database.
DNS Client Service
The Windows Server 2003 operating system, as well as
Microsoft Windows XP and Windows 2000 include a DNS Client service. This
service performs all necessary DNS lookups and provides a local cache
for DNS queries that reduces DNS network traffic and speeds name
resolution.
This service can be stopped and started using the
Services console. Computers running Windows 2000, Windows XP and Windows Server 2003 enable the DNS Client service by default.
The Windows Server 2003 DNS Client service performs the following tasks:
-
Registers its names in DNS.
-
Name resolution.
-
Caching responses to name resolution queries.
-
Removes previously resolved names from the cache when it receives a negative response for the name.
-
Negative caching.
-
Keeps track of transitory (Plug and Play) network connections and the DNS server lists based on their IP configurations.
-
Maintains connection-specific domain name suffixes.
-
Prioritizes which DNS servers it uses according to whether they respond
to a query if multiple DNS server are configured on the client.
-
Prioritizes the multiple A resource records it receives from a DNS server based on their IP address.
-
Initiates a network failure timeout when all DNS Client service queries
time out, and does not submit any queries for 30 seconds. This feature
applies to every adapter separately.
Windows XP, Windows 2000 and Windows Server 2003 DNS client
configuration involves the following settings in the TCP/IP properties
for each computer:
-
Domain Names. Domain names are to form the fully qualified domain name (FQDN) for DNS clients.
-
Host names. A DNS computer or host name
for each computer. For example, in the fully qualified domain name
(FQDN) wkstn1.example.microsoft.com., the DNS computer name is the
leftmost label client1.
-
Primary DNS suffixes. A primary DNS
suffix for the computer, which is placed after the computer or host name
to form the FQDN. Using the previous example, the primary DNS suffix
would be example.microsoft.com.
-
Connection-specific names. Each network connections of a multihomed computer can be configured with a connection-specific DNS domain name
-
NetBIOS names. NetBIOS names are used to support legacy Microsoft networking technology.
-
DNS servers list. A list of DNS servers
for clients to use when resolving DNS names, such as a preferred DNS
server, and any alternate DNS servers to use if the preferred server is
not available.
-
DNS suffix search list. The DNS suffix
search list or search method to be used by the client when it performs
DNS query searches for short, unqualified domain names.
Domain Names
The domain name is used with the client computer name to
form the fully qualified domain name (FQDN), known also as the full
computer name. In general, the DNS domain name is the remainder of the
FQDN that is not used as the unique host name for the computer.
For example, the DNS domain name used for a client computer could be the following: If the FQDN, or Full computer name, is wkstn1.example.microsoft.com, the domain name is the example.microsoft.com portion of this name.
DNS domain names have two variations — a DNS name and a
NetBIOS name. The full computer name (a fully qualified DNS name) is
used during querying and location of named resources on your network.
For earlier version clients, the NetBIOS name is used to locate various
types of NetBIOS services that are shared on your network.
An example that shows the need for both NetBIOS and DNS
names is the Net Logon service. In Windows Server 2003 DNS, the Net
Logon service on a domain controller registers its service (SRV)
resource records on a DNS server. For Windows NT Server 4.0 and earlier
versions, domain controllers register a DomainName entry in Windows
Internet Name Service (WINS) to perform the same registration and to
advertise their availability for providing authentication service to the
network.
When a client computer is started on the network, it uses
the DNS resolver to query a DNS server for SRV records for its
configured domain name. This query is used to locate domain controllers
and provide logon authentication for accessing network resources. A
client or a domain controller on the network optionally uses the NetBIOS
resolver service to query WINS servers, attempting to locate
DomainName [1C] entries to complete the logon process.
Your DNS domain names should follow the same standards
and recommended practices that apply to DNS computer naming described in
the previous section. In general, acceptable naming conventions for
domain names include the use of letters A through Z, numerals 0 through
9, and the hyphen (-). The use of the period (.) in a domain name is
always used to separate the discrete parts of a domain name, commonly
known as labels. Each label corresponds to an additional level defined
in the DNS namespace tree.
For most computers, the primary DNS suffix configured for
the computer can be the same as its Active Directory domain name,
although the two values can be different.
Host Names
Computers using the underlying TCP/IP protocol of a
Windows-based network use an IP address, a 32-bit numeric value (in the
case of IPv4) or a 128-bit numeric value (in the case of IPv6), to
identify the computer network connection of network hosts. However,
network users prefer to use memorable, alphanumeric names. To support
this need, network resources in a Windows-based network are identified
by both alphanumeric names and IP addresses. DNS and WINS are two name
resolution mechanisms that enable the use of alphanumeric names, and
convert these names into their respective IP addresses.
NetBIOS vs. DNS Computer Names
In networks running Windows NT 4.0 and earlier, users
typically locate and access a computer on the network using a NetBIOS
(Network Basic Input Output System) name. In Windows 2000, Windows XP,
and Windows Server 2003 operating systems, users locate and access a
computer using DNS. In this implementation of DNS, a computer is
identified by its full computer name, which is a DNS fully qualified
domain name (FQDN).
Primary DNS Suffixes
The full computer name is a concatenation of the single-label host name, such as hostcompute
r, and a multilabel primary DNS suffix name, such as corp
.example.com,
which is the DNS name of the Active Directory domain to which the
computer is joined. Using the host and primary DNS suffix examples, the
full computer name is hostcomputer.corp.example.com.
The host name is the same as the computer name specified
during the installation of Windows Server 2003 and is listed in System
Properties. The primary DNS suffix name is the same as the domain name
specified during installation of Windows Server 2003 and is listed in
System Properties. The full computer name is also listed in System
Properties.
In addition, connection-specific DNS suffixes can be
applied to the separate network adapter connections used by a multihomed
computer. Connection-specific DNS suffixes identify the host when it is
connected to separate networks that use different domain names. When
using connection-specific DNS suffixes, a full computer name is also a
concatenation of the host name and a connection-specific DNS suffix.
Using its host name and DNS suffixes, a single computer can have its full computer name configured using two possible methods:
-
A primary full computer name, which applies as the default full computer
name for the computer and all of its configured network connections.
-
A connection-specific full computer name, which can be configured as an
alternate DNS domain name that applies only for a single network adapter
installed and configured on the computer.
Note that when using Active Directory, by default, the
primary DNS suffix portion of a computer’s full computer name must be
the same as the name of the Active Directory domain where the computer
is located. To allow different primary DNS suffixes, a domain
administrator may create a restricted list of allowed suffixes by
creating the
msDS-AllowedDNSSuffixes attribute in the
domain object container. This attribute is created and managed by the
domain administrator using Active Directory Service Interfaces (ADSI) or
the Lightweight Directory Access Protocol (LDAP).
Connection-specific Names
As shown in the following figure, a multihomed server
computer named “host-a” can be named according to both its primary and
connection-specific DNS domain names.
Connection-specific DNS Names
In this example, the server computer host-a attaches to
two separate subnets — Subnet 1 and Subnet 2 — which are also linked at
redundant points using two routers for additional paths between each
subnet. Given this configuration, host-a provides access as follows
through its separately named local area network (LAN) connections:
-
The name “host-a.public.example.microsoft.com” provides access using LAN
connection 1 over Subnet 1, a lower-speed (10 megabit) Ethernet LAN,
for normal access to users who have typical file and print service
needs.
-
The name “host-a.backup.example.microsoft.com” provides access using LAN
connection 2 over Subnet 2, a higher-speed (100 megabit) Ethernet LAN,
for reserved access by server applications and administrators who have
special needs, such as troubleshooting server networking problems,
performing network-based backup, or replicating zone data between
servers.
In addition to the connection-specific DNS names, the
computer can also be accessible using either of the two LAN connections
by specifying its primary DNS domain name,
“host-a.example.microsoft.com”.
When configured as shown, a computer can register
resource records in DNS according to its three distinct names and sets
of IP addresses, as shown in the following table:
DNS Names
|
DNS Name
|
IP Addresses
|
Description
|
host-a.example.microsoft.com
|
10.1.1.11, 10.2.2.22
|
Primary DNS name for computer. The computer
registers A and PTR resource records for all configured IP addresses
under this name in the “example.microsoft.com” zone.
|
host-a.public.example.microsoft.com
|
10.1.1.11
|
Connection-specific DNS name for LAN connection 1,
which registers A and PTR resource records for IP address 10.1.1.11 in
the “public.example.microsoft.com” zone.
|
host-a.backup.example.microsoft.com
|
10.2.2.22
|
Connection-specific DNS name for LAN connection 2,
which registers A and PTR resource records for IP address 10.2.2.22 in
the “backup.example.microsoft.com” zone.
|
When a computer changes between connections to different
networks hosting different DNS domains, the host name does not need to
be changed unless there is a host in the new DNS domain with the same
host name. The primary DNS suffix for the computer can be changed from
the old domain name to the new domain and the computer will register the
new full computer name in DNS.
Note
-
If you have any multihomed dynamic update clients and at least one
adapter is using DHCP, configure the DHCP server to update resource
records according to the request of the client. If the DHCP server is
configured to register both A and PTR resource records, the DHCP server
may replace all A resource records for the name it attempts to register.
As a result, A resource records that correspond to the computer’s other
IP addresses might be deleted.
In Windows XP and Windows Server 2003 operating systems, the full computer name is viewed and set in the
Computer Name tab of
System Properties. Connection-specific DNS suffixes are configured in the
Advanced TCP/IP Settings dialog box of the
Internet Protocol (TCP/IP) Properties for a network connection.
NetBIOS Names
The NetBIOS name is created using the first 16 bytes of
the host name, which is the maximum number of characters for NetBIOS
names. The NetBIOS name is a 16-byte string that uniquely identifies a
computer or service for network communication. If the DNS host name is
15 or fewer bytes, the NetBIOS name is the host name plus enough spaces
to form a 15-byte name, followed by a 1-byte unique identifier. The
sixteenth byte specifies the network service associated with the
computer. When the computer name exceeds the maximum length for NetBIOS,
the NetBIOS computer name is created by truncating the host name to
form a 15-byte name, followed by a 1-byte unique identifier.
Note
-
Because host names are encoded in UTF-8 format, they do not necessarily
have only 1 byte per character. ASCII characters are 1 byte each, but
the size of extended characters is more than 1 byte. For details of
naming restrictions and a fuller description of UTF8, see “Naming
Restrictions for Hosts and Domains” later in this chapter.
If you have an investment in using NetBIOS names to
support legacy Microsoft networking technology, it is recommended that
you revise NetBIOS computer names used on your network to prepare for
migration to a standard DNS-only environment. This prepares your network
well for long term growth and compatibility with future naming
requirements. For example, if you use the same computer name for both
NetBIOS and DNS resolution, consider converting any special characters
in your current NetBIOS names that do not comply with DNS naming
standards, such as the underscore (
_). While these
characters are permitted in NetBIOS names, they are more often
incompatible with traditional DNS host naming requirements and most
existing DNS resolver client software.
Note
-
If WINS lookup is enabled for zones hosted by your Windows DNS servers,
you need to use the same name for both NetBIOS and DNS computer naming.
Otherwise, the results of clients attempting to query and resolve the
names of these computers will be inconsistent.
The following table summarizes the differences between DNS and NetBIOS names using the example FQDN client1.example.com.
DNS and NetBIOS Names
|
Name Type
|
Description
|
NetBIOS name
|
The NetBIOS name is used to uniquely identify the
computer’s NetBIOS services. This unique NetBIOS name is resolved to the
IP address of the computer through broadcast, WINS, or the LMHosts
file. By default, the computer’s NetBIOS name is the same as the host
name up to 15 bytes, plus any spaces necessary to make the name 15 bytes
long, plus the service identifier.
For example, a NetBIOS name might be Client1.
|
Host name
|
The host name is the first label of a FQDN.
For example, the first label of the FQDN client1.example.com is client1.
|
Primary DNS suffix
|
Every Windows XP and Windows Server 2003 computer
can be assigned a primary DNS suffix to be used in name resolution and
name registration. You can view the primary DNS suffix for your computer
from the Computer Name tab of SystemProperties.
The primary DNS suffix is also known as the primary domain name.
For example, the FQDN client1.example.com has the primary DNS suffix example.com.
|
Connection-specific DNS suffix
|
The connection-specific DNS suffix is a DNS suffix
that is assigned to a network connection. The connection-specific DNS
suffix is also known as an adapter-specific DNS suffix. For example, a
connection-specific DNS suffix might be acquired01-ext.com.
|
Fully Qualified Domain Name (FQDN)
|
The FQDN is a DNS name that uniquely identifies the
computer in the DNS namespace. By default, it is a concatenation of the
host name, the primary DNS suffix, and a period. For example, an FQDN
might be client1.example.com.
|
Full computer name
|
The full computer name is the FQDN for a
Windows XP, Windows 2000 or Windows Server 2003 computer. It is the
concatenation of the host name and primary DNS suffix (or host name and
connection-specific DNS suffix).
|
DNS Servers List
For DNS clients to operate effectively, a prioritized
list of DNS name servers must be configured for each computer to use
when processing queries and resolving DNS names. In most cases, the
client computer contacts and uses its preferred DNS server, which is the
first DNS server on its locally configured list. Listed alternate DNS
servers are contacted and used when the preferred server is not
available. For this reason, it is important that the preferred DNS
server be appropriate for continuous client use under normal conditions.
For computers running Windows XP, the DNS server list is
used by clients only to resolve DNS names. When clients send dynamic
updates, such as when they change their DNS domain name or a configured
IP address, they might contact these servers or other DNS servers as
needed to update their DNS resource records.
By default, the DNS client on Windows XP does not attempt
dynamic update over a Remote Access Service (RAS) or virtual private
network (VPN) connection. By default, the Windows XP and Windows
Server 2003 DNS Client service 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. When
DNS clients are configured dynamically using a DHCP server, it is
possible to have a larger list of provided DNS servers. To effectively
share the load when multiple DNS servers are provided in a DHCP
options-specified list, you can configure a separate DHCP scope that
rotates the listed order of DNS and WINS servers provided to clients.
DNS Suffix Search List
For DNS clients, you can configure a DNS domain suffix
search list that extends or revises their DNS search capabilities. By
adding additional suffixes to the list, you can search for short,
unqualified computer names in more than one specified DNS domain. Then,
if a DNS query fails, the DNS Client service can use this list to append
other name suffix endings to your original name and repeat DNS queries
to the DNS server for these alternate FQDNs.
For computers and servers, the following default DNS
search behavior is predetermined and used when completing and resolving
short, unqualified names.
When the suffix search list is empty or unspecified, the
primary DNS suffix of the computer is appended to short unqualified
names, and a DNS query is used to resolve the resultant FQDN. If this
query fails, the computer can try additional queries for alternate FQDNs
by appending any connection-specific DNS suffix configured for network
connections.
If no connection-specific suffixes are configured or
queries for these resultant connection-specific FQDNs fail, then the
client can then begin to retry queries based on systematic reduction of
the primary suffix (also known as devolution).
For example, if the primary suffix were
“example.microsoft.com”, the devolution process would be able to retry
queries for the short name by searching for it in the microsoft.“com”
and “com” domains.
When the suffix search list is not empty and has at least
one DNS suffix specified, attempts to qualify and resolve short DNS
names are limited to searching only those FQDNs made available by the
specified suffix list. If queries for all FQDNs that are formed as a
result of appending and trying each suffix in the list are not resolved,
the query process fails, producing a “name not found” result.
If the domain suffix list is used, clients continue to
send additional alternate queries based on different DNS domain names
when a query is not answered or resolved. Once a name is resolved using
an entry in the suffix list, unused list entries are not tried. For this
reason, it is most efficient to order the list with the most commonly
used domain suffixes first.
Domain name suffix searches are used only when a DNS name
entry is not fully qualified. To fully qualify a DNS name, a trailing
period (.) is entered at the end of the name.
Name Restrictions for Hosts and Domains
Different DNS implementations allow different characters
and lengths, and differ from NetBIOS naming restrictions. The following
table shows the restrictions for standard DNS names, DNS names in
Windows Server 2003 and NetBIOS Names.
|
Restriction
|
Standard DNS (Including Windows NT 4.0)
|
DNS in Windows Server 2003
|
NetBIOS
|
Characters
|
Supports RFC 1123, which permits “A” to Z, “a” to “z”, “0” to “9”, and the hyphen (-)
|
Several different configurations are possible, as described at the end of this section
|
Permits Unicode characters, numbers, white space, symbols: ! @ $ % ^ & ) ( . - _ { } ~
|
Fully qualified domain name length
|
Permits 63 bytes per label and 255 bytes for an FQDN
|
Permits 63 bytes per label and 255 bytes for an FQDN; the FQDN for an Active Directory domain name is limited to 64 bytes
|
Permits 16 bytes for a host name
|
Note
-
Although you can create long, complex DNS names, it is recommended that you create shorter, user-friendly names.
Adherence to DNS RFC 1123 can present a problem during an
upgrade from Windows NT 4 to Windows 2000 or Windows Server 2003
because the host name of a Windows 2000 or Windows Server 2003 computer
is set to the NetBIOS name that was set prior to the upgrade. NetBIOS
names can use characters that violate the RFC 1123 DNS name
restrictions, and converting NetBIOS names to strict DNS names can be
time consuming.
Windows 2000 and Windows Server 2003 support migration by
supporting a wider character set than RFC 1123. RFC 2181 enlarges the
character set allowed in DNS names. It states that a DNS label can be
any binary string, and it does not necessarily need to be interpreted as
ASCII. Based on this definition, Microsoft has proposed that the DNS
name specification be readjusted to accommodate a larger character set:
UTF-8 character encoding, as described in RFC 2044.
UTF-8 character encoding is a superset of ASCII and a
translation of the UCS-2 (also known as Unicode) character encoding. The
UTF-8 character set includes characters from most of the world’s
written languages; this enables a far greater range of possible names.
The Windows Server 2003 DNS service includes support for UTF-8 character
encoding. For more information about UTF-8, see “Unicode Character
Support” later in this document.
However, before using additional characters in DNS names, consider the following issues:
-
Some third-party DNS client software supports only the characters listed
in RFC 1123. Third-party DNS client software may not able to resolve
the DNS names of computers with names that use characters outside the
set supported by RFC 1123.
-
A DNS server that does not support UTF-8 encoding might accept a zone
transfer of a zone containing UTF-8 names, but it cannot write back
those names to a zone file or reload those names from a zone file.
Therefore, you must not transfer a zone that contains UTF-8 characters
to a DNS server that does not support them.
-
If you attempt to register a DNS name in Active Directory that contains
an extended character that cannot be rendered in an LDAP distinguished
name, Active Directory will respond with an invalid syntax error.
You can configure the Windows Server 2003 DNS server to allow or reject
the use of UTF-8 characters in DNS names. You can do this for each DNS
server administered using the DNS console.
Note
-
When you are modifying a host name or DNS suffix, or creating an Active
Directory domain, if you enter a DNS name that includes UTF-8
or underscore characters not listed in RFC 1123, a warning message
appears explaining that some DNS server implementations might not
support these characters.
Subnet Prioritization
DNS subnet prioritization returns local IP addresses to
the DNS Client service in preference to IP addresses on different
subnets. This feature reduces network traffic by encouraging client
computers to connect to network resources closer to them.
For example, suppose the three Web servers that host
www.example.com are located on different subnets. On the DNS server, you
can create the following resource records:
www.example.com. IN A 172.16.64.11
www.example.com. IN A 172.17.64.22
www.example.com. IN A 172.18.64.33
When a user queries for www.example.com, all three
resource records are returned. With subnet prioritization, the DNS
Client service reorders the list of records returned so that it begins
with the IP addresses from networks to which the computer is directly
connected. For example, if a user with the IP address 172.17.64.93
queries for www.example.com, the DNS Client service returns the resource
records in the following order:
www.example.com. IN A 172.17.64.22
www.example.com. IN A 172.16.64.11
www.example.com. IN A 172.18.64.33
Note
-
Subnet prioritization prevents the DNS Client service from using the
Round Robin feature on the DNS Server service. For more information, see
“Round Robin” later in this document.
Although subnet prioritization can reduce network traffic
across subnets, you might prefer to use round robin as described in
RFC 1794.
DNS Server Service
The DNS Server service is the component that provides the
server implementation of DNS. The settings discussed in this section
include:
-
Disabling the use of recursion.
-
Round robin use of resource records.
-
Subnet prioritization.
-
Advanced parameters.
Disabling Recursion
By default, recursion is enabled for the DNS Server
service, and clients typically request that the server use recursion to
resolve a name when sending a query. If recursion is disabled, the DNS
Server service always uses referral, regardless of the client request.
In general, DNS servers can answer queries for names outside of their authoritative zones in two ways:
-
Servers can send referral answers, which are an immediate response to
the requesting client with a list of resource records for other DNS
servers that it knows about that appear to be closer or more likely to
be of help in resolving the queried name.
-
Servers can use recursion to query other servers on behalf of the
requesting client, attempting to fully resolve the name. Recursive
lookups continue until the server receives an authoritative answer for
the queried name. The server then forwards this answer in response to
the original query from the requesting client.
In most cases, recursion is disabled on a DNS server when
DNS clients are limited to resolving names authoritatively managed on a
specific server. For example, this is the case when a DNS server has
only DNS names data for an internal network or when the DNS server is
incapable of resolving external DNS names (such as Internet DNS names)
and clients are expected to retry another DNS server to resolve these
names.
Note
-
If you disable recursion on the DNS server, you will not be able to use
forwarders on the same server. For more information about forwarders,
see “Forwarding” later in this document.
Round Robin
Round robin DNS is a method of managing server congestion
by distributing connection loads across multiple servers (containing
identical content). Round robin works on a rotating basis in that one
server IP address is handed out, then moves to the back of the list; the
next server IP address is handed out, then it moves to the end of the
list; and so on, depending on the number of servers being used. This
works in a looping fashion.
This local balancing mechanism is used by DNS servers to
share and distribute network resource loads. You can use round robin to
rotate all resource record types contained in a query answer if multiple
RRs are found.
By default, DNS uses round robin to rotate the order of
RR data returned in query answers where multiple RRs of the same type
exist for a queried DNS domain name. This feature provides a simple
method for load balancing client use of Web servers and other frequently
queried multihomed computers.
If round robin is disabled for a DNS server, the order of
the response for these queries is based on a static ordering of RRs in
the answer list as they are stored in the zone (either its zone file or
Active Directory).
Example: Round-robin rotation
A forward lookup-type query (for all Host Address [A]
RRs that match a DNS domain name) is made for a multihomed computer
(multihomed.example.microsoft.com) that has three IP addresses. Separate
A RRs are used to map the host’s name to each of these IP addresses in
the zone. In the stored example.microsoft.com zone, the RRs appear in
this fixed order:
multihomed IN A 10.0.0.1
multihomed IN A 10.0.0.2
multihomed IN A 10.0.0.3
The first DNS client that queries the server to resolve
this host’s name receives the list in default order. When a second
client sends a subsequent query to resolve this name, the list is
rotated as follows:
multihomed IN A 10.0.0.2
multihomed IN A 10.0.0.3
multihomed IN A 10.0.0.1
Restricting round robin rotation for selected RR types
By default, DNS will perform round robin rotation for
all RR types. You can now specify that certain RR types are not to be
round-robin rotated in the registry. These modifications can be made in
the registry.
Restricting round-robin rotation for all RR types
By default, all RR types are rotated, except those that have been specified as excluded from rotation in the registry.
Subnet Prioritization
By default, the DNS Server service uses local subnet
prioritizing as the method for giving preference to IP addresses on the
same network when a client query resolves to a host name that is mapped
to more than one IP address. This feature requires that the client
application attempt to connect to the host using its closest (and
typically fastest) IP address available for connection.
The DNS Server service uses local subnet priority as follows:
-
The DNS Server service determines if local subnet prioritization is needed to order the query response.
If more than one A resource record (RR) matches the queried host name,
the DNS Server service can reorder the records by their subnet location.
If the queried host name only matches a single A resource record, or if
the IP network address of the client does not match an IP network
address for any of the mapped addresses in an answer list of multiple
RRs, no prioritizing is necessary.
-
For each RR in the matched answer list, the DNS Server service
determines which records (if any) match the subnet location of the
requesting client.
-
The DNS Server service reorders the answer list so that A RRs which
match the local subnet of the requesting client are placed first in the
answer list.
-
Prioritized by subnet order, the answer list is returned to the requesting client.
Simple example: Local network prioritizing
A multihomed computer,
multihomed.example.microsoft.com, has three A RRs for its three separate
host IP addresses in the example.microsoft.com zone. A separate A RR is
used for each of the host’s addresses, which appear in this order in
the zone:
multihomed IN A 192.168.1.27
multihomed IN A 10.0.0.14
multihomed IN A 172.16.20.4
If a DNS client resolver at IP address 10.4.3.2 queries
the server for the IP addresses of host
multihomed.example.microsoft.com, the DNS Server service notes that the
originating IP network address (10.0.0.0) of the client matches the
network (class A) portion of the 10.0.0.4 address in the answer list of
RRs. The DNS Server service then reorders the addresses in the response
as follows:
multihomed IN A 10.0.0.14
multihomed IN A 192.168.1.27
multihomed IN A 172.16.20.4
If the IP address of the requesting client has no local
network match with any of the RRs in the answer list, then the list is
not prioritized.
Complex example: Local subnet prioritizing
In Windows Server 2003, addresses are prioritized by
matching the class C subnet by default, regardless of the subnet mask or
address class of the target address.
For example, a multihomed computer,
multihomed.example.microsoft.com, has four A RRs for four separate host
IP addresses in the example.microsoft.com zone. Two of these IP
addresses are for nonlocal networks. The other two IP addresses share a
common IP network address but, because IP subnetting is used, represent
different physical subnetted network connections based on their custom
(nondefault) subnet mask value of 255.255.248.0. These example RRs
appear in the following order in the zone:
multihomed IN A 192.168.1.27
multihomed IN A 172.16.22.4
multihomed IN A 10.0.0.14
multihomed IN A 172.16.31.5
If the IP address of the requesting client is
172.16.22.8, both of the IP addresses that match the same IP network as
the client, the 172.16.0.0 network, are returned at the top of the
answer list to the client. However, in this example, the 172.16.22.4
address is placed ahead of the 172.16.31.5 address because it matches
the client IP address down through the 172.16.20.0 subnet address.
The reordered answer list returned by the DNS Server service would be:
multihomed IN A 172.16.22.4
multihomed IN A 172.16.31.5
multihomed IN A 192.168.1.27
multihomed IN A 10.0.0.14
Note
-
IP subnetting is imposed by using a custom or nondefault subnet mask
value with all of the IP addresses on a network. Local subnet priority
supersedes the use of round robin rotation for multihomed names. When
round robin is enabled, however, RRs continue to be rotated using round
robin as the secondary method of sorting the response list.
Advanced DNS Server Service Parameters
When initialized for service, DNS servers use server
configuration settings taken from the parameters stated in a boot
information file, the registry, and possibly zone information provided
through Active Directory integration.
In most situations, the installation defaults are
acceptable and should not require modification. However, when needed,
you can use the DNS console to tune the following advanced parameters,
accommodating special deployment needs and situations.
DNS Server Service Advanced Parameters
|
Value
|
Description
|
Disable recursion
|
Determines whether or not the DNS server uses recursion. By default, the DNS Server service is enabled to use recursion.
|
BIND secondaries
|
Determines whether to use fast transfer format when
transferring a zone to DNS servers running legacy Berkeley Internet
Name Domain (BIND) implementations.
By default, all Windows-based DNS servers use a
fast zone transfer format, which uses compression and can include
multiple records per TCP message during a connected transfer. This
format is also compatible with more recent BIND-based DNS servers that
run versions 4.9.4 and later.
|
Fail on load if bad zone data
|
Sets the DNS server to parse files strictly.
By default, the DNS Server service logs data
errors, ignore any erred data in zone files, and continue to load a
zone. This option can be reconfigured using the DNS console so that the
DNS Server service logs errors and fails to load a zone file containing
records data that is determined to have errors.
|
Enable round robin
|
Determines whether the DNS server uses round robin
to rotate and reorder a list of resource records (RRs) if multiple RRs
exist of the same type exisit for a query answer.
|
Enable netmask ordering
|
Determines whether the DNS server reorders A
resource records within the same resource record set in its response to a
query based on the IP address of the source of the query.
|
Secure cache against pollution
|
Determines whether the server attempts to clean up responses to avoid cache pollution. This setting is enabled by default.
By default, DNS servers use a secure response
option that eliminates adding unrelated resource records included in a
referral answer to their cache. In most cases, any names added in
referral answers are typically cached and help expedite the speed of
resolving subsequent DNS queries.
With this feature, however, the server can
determine that referred names are potentially polluting or insecure and
discard them. The server determines whether to cache the name offered in
a referral on the basis of whether or not it is part of the exact
related DNS domain name tree for which the original queried name was
made.
For example, if a query was originally made for
“example.microsoft.com” and a referral answer provided a record for a
name outside of the “microsoft.com” domain name tree, such
as msn.com, then that name would not be cached where this feature is
enabled for use.
|
Resource Records in DNS
DNS resource records are the data that is associated with
DNS names in the DNS namespace. Each domain name of the DNS namespace
tree contains a set of resource records, and each resource record in the
set contains different types of information relating to the domain
name. A DNS query includes the DNS domain name that is to be resolved
and the type of information desired (the resource records that are
requested). Queries for the IP addresses of DNS hosts return A resource
records, and queries for the DNS servers authoritative for a DNS domain
name return name server (NS) resource records.
Resource records are typically discussed in two categories:
authority records and other records. Authority records identify the DNS
servers that are authoritative for the domain names in the DNS
namespace and how their zones should be managed, and all other DNS
records contain information about a domain name that is unrelated to
authority.
Authority Records
Zones are based on a concept of server authority. When a
DNS server is configured to load a zone, it uses two types of resource
records to determine the authoritative properties of the zone:
-
First, the start of authority (SOA) resource record indicates the name
of origin for the zone and contains the name of the server that is the
primary source for information about the zone. It also indicates other
basic properties of the zone.
-
Next, the name server (NS) resource record is used to notate which DNS
servers are designated as authoritative for the zone. By listing a
server in the NS RR, it becomes known to others as an authoritative
server for the zone. This means that any server specified in the NS RR
is to be considered an authoritative source by others, and is able to
answer with certainty any queries made for names included in the zone.
The SOA and NS resource records occupy a special role in
zone configuration. They are required records for any zone and are
typically the first resource records listed in files.
The SOA resource record
The start of authority (SOA) resource record is always
first in any standard zone. It indicates the DNS server that either
originally created it or is now the primary server for the zone. It is
also used to store other properties such as version information and
timings that affect zone renewal or expiration. These properties affect
how often transfers of the zone are done between servers authoritative
for the zone.
The SOA resource record contains the following information:
SOA Resource Record Fields
|
Field
|
Description
|
Primary server (owner)
|
The host name for the primary DNS server for the zone.
|
Responsible person
|
The e-mail address of the person responsible for administering the zone. A period (.) is used instead of an at sign (@) in this e-mail name.
|
Serial number
|
The revision number of the zone file. This number
increases each time a resource record in the zone changes. It is
important that this value increase each time the zone is changed, so
that either partial zone changes or the fully revised zone can be
replicated to other secondary servers during subsequent transfers.
|
Refresh interval
|
The time, in seconds, that a secondary DNS server
waits before querying its source for the zone to attempt renewal of the
zone. When the refresh interval expires, the secondary DNS server
requests a copy of the current SOA record for the zone from its source,
which answers this request. The secondary DNS server then compares the
serial number of the source server’s current SOA record (as indicated in
the response) with the serial number in its own local SOA record. If
they are different, the secondary DNS server requests a zone transfer
from the primary DNS server. The default for this field is 900 seconds
(15 minutes).
|
Retry interval
|
The time, in seconds, a secondary server waits
before retrying a failed zone transfer. Normally, this time is less than
the refresh interval. The default value is 600 seconds (10 minutes).
|
Expire interval
|
The time, in seconds, before a secondary server
stops responding to queries after a lapsed refresh interval where the
zone was not refreshed or updated. Expiration occurs because at this
point in time, the secondary server must consider its local data
unreliable. The default value is 86,400 seconds (24 hours).
|
Minimum (default) TTL
|
The default Time-To-Live (TTL) of the zone and
the maximum interval for caching negative answers to name queries. The
default value is 3,600 seconds (1 hour).
|
The following is an example of a default SOA resource record:
@ IN SOA nameserver.example.microsoft.com. postmaster.example.microsoft.com. (
1 ; serial number
3600 ; refresh [1h]
600 ; retry [10m]
86400 ; expire [1d]
3600 ) ; min TTL [1h]
In the example SOA record shown above, the primary or
originating server for the zone is shown as
nameserver.example.microsoft.com. The e-mail address for the person to
contact regarding questions about this zone is
postmaster.example.microsoft.com.
Periods are used to represent e-mail addresses when
writing and storing DNS domain names in a zone. In an e-mail
application, the previous example address would instead likely appear as
postmaster@example.microsoft.com. The parentheses used in the SOA
resource record as it appears in a zone file are used to enable wrapping
of the record over multiple lines of text. If an individual TTL value
is assigned and applied to a specified resource record used in the zone,
it overrides the minimum (default) TTL set in the SOA record.
The NS resource record
Name server (NS) resource records can be used to assign authority to specified servers for a DNS domain name in two ways:
-
By establishing a list of authoritative servers for the domain so that
those servers can be made known to others that request information about
this domain (zone).
-
By indicating authoritative DNS servers for any subdomains that are delegated away from the zone.
In the case of assigning servers with host names in the
same zone, corresponding address (A) resource records are normally used
in the zone to resolve the names of specified servers to their IP
addresses. For servers that are specified using this RR as part of a
zone delegation to a subdomain, the NS resource record usually contains
out-of-zone names. For the out-of-zone names to be resolved, A resource
records for the specified out-of-zone server’s might be needed. When
these out-of-zone NS and A records are needed to provide delegation,
they are known as glue records.
The following table shows the basic syntax of how a NS RR is used.
Basic Syntax of a Name Server Resource Record
Description: Used to map a DNS domain name as specified in owner to the name of hosts operating DNS servers specified in the name_server_domain_name field.
|
Syntax:
owner ttl
IN
NS
name_server_domain_name.
|
Example:
example.microsoft.com. IN NS nameserver1.example.microsoft.com
|
Other Important Records
After a zone is created, additional resource records need
to be added to it. The following table lists the most common resource
records (RRs) to be added.
Common DNS Resource Records
|
Resource Record
|
Description
|
Host (A)
|
For mapping a DNS domain name to an IP address used by a computer.
|
Alias (CNAME)
|
For mapping an alias DNS domain name to another primary or canonical name.
|
Mail Exchanger (MX)
|
For mapping a DNS domain name to the name of a computer that exchanges or forwards mail.
|
Pointer (PTR)
|
For mapping a reverse DNS domain name based on the
IP address of a computer that points to the forward DNS domain name of
that computer.
|
Service location (SRV)
|
For mapping a DNS domain name to a specified list
of DNS host computers that offer a specific type of service, such as
Active Directory domain controllers.
|
Host (A) resource records
Host (A) resource records are used in a zone to
associate DNS domain names of computers (or hosts) to their IP
addresses, and can be added manually, Windows clients and servers can
also use the DHCP Client service to dynamically register and update
their own A resource records in DNS when an IP configuration change
occurs. DHCP-enabled client computers running earlier versions of
Microsoft operating systems can have their A resource records registered
and updated by proxy if they obtain their IP lease from a qualified
DHCP server (only the Windows 2000 and Windows Server 2003 DHCP Server
service currently supports this feature).
The host (A) resource record is not required for all
computers, but is needed by computers that share resources on a network.
Any computer that shares resources and needs to be identified by its
DNS domain name, needs to use A resource records to provide DNS name
resolution to the IP address for the computer.
Most A RRs that are required in a zone can include
other workstations or servers that share resources, other DNS servers,
mail servers, and Web servers. These resource records comprise the
majority of resource records in a zone database.
Alias (CNAME) resource records
Alias (CNAME) resource records are also sometimes
called canonical names. These records allow you to use more than one
name to point to a single host, making it easy to do such things as host
both an FTP server and a Web server on the same computer. For example,
the well-known server names (ftp, www) are registered using CNAME RRs
that map to the DNS host name, such as “server-1” for the server
computer that hosts these services.
CNAME RRs are recommended for use in the following scenarios:
-
When a host specified in an A RR in the same zone needs to be renamed.
-
When a generic name for a well-known server such as www needs to resolve
to a group of individual computers (each with individual A RRs) that
provide the same service. An example would be a group of redundant Web
servers.
When renaming a computer with an existing A RR in the
zone, you can use a CNAME RR temporarily, to allow a grace period for
users and programs to switch from specifying the old computer name to
using the new one. To do this, you need the following:
-
For the new DNS domain name of the computer, a new A RR is added to the zone.
-
For the old DNS domain name, a CNAME RR is added that points to the new A RR.
-
The original A RR for the old DNS domain name (and its associated PTR RR if applicable) is removed from the zone.
When using a CNAME RR for aliasing or renaming a
computer, set a temporary limit on how long the record is used in the
zone before removing it from DNS. If you forget to delete the CNAME RR
and later its associated A RR is deleted, the CNAME RR can waste server
resources by trying to resolve queries for a name no longer used on the
network.
The most common or popular use of a CNAME RR is to
provide a permanent DNS aliased domain name for generic name resolution
of a service-based name, such as www.example.microsoft.com to more than
one computer or one IP address used in a Web server. For example, the
following shows the basic syntax of how a CNAME RR is used.
alias_name IN CNAME primary_canonical_name
In this example, a computer named
host-a.example.microsoft.com needs to function as both a Web server
named “www.example.microsoft.com.”; and an FTP server named
“ftp.example.microsoft.com.”; To achieve the intended use for naming
this computer, you can add and use the following CNAME entries in the
example.microsoft.com zone:
host-a IN A 10.0.0.20
ftp IN CNAME host-a
www IN CNAME host-a
If you later decide to move the FTP server to another
computer, separate from the Web server on “host-a”, simply change the
CNAME RR in the zone for ftp.example.“microsoft.com” and add an
additional A RR to the zone for the new computer hosting the FTP server.
Based on the earlier example, if the new computer were
named “host-b.example.microsoft.com”, the new and revised A and CNAME
RRs would be as follows:
host-a IN A 10.0.0.20
host-b IN A 10.0.0.21
ftp IN CNAME host-b
www IN CNAME host-a
Mail exchanger (MX) resource records
The mail exchanger (MX) RR is used by e-mail
applications to locate a mail server based on a DNS domain name used in
the destination address for the e-mail recipient of a message. For
example, a DNS query for the name example.microsoft.com; could be used
to find an MX RR, enabling an e-mail application to forward or exchange
mail to a user with the e-mail address user@microsoft.com.
The MX RR shows the DNS domain name for the computer or
computers that process mail for a domain. If multiple MX RRs exist, the
DNS Client service attempts to contact mail servers in the order of
preference from lowest value (highest priority) to highest value (lowest
priority). The following shows the basic syntax for use of an MX RR.
mail_domain_name IN MX preference mailserver_host
By using the MX RRs shown below in the
example.microsoft.com zone, mail addressed to user@example.microsoft.com
is delivered to user@mailserver0.example.microsoft.com first if
possible. If this server is unavailable, the resolver client can then
use user@mailserver1.example.microsoft.com instead.
@ IN MX 1 mailserver0
@ IN MX 2 mailserver1
Note that the use of the at sign (
@)
in the records indicates that the mailer DNS domain name is the same as
the name of origin (example.microsoft.com) for the zone.
Pointer (PTR) resource records
Pointer (PTR) RRs are used to support the reverse
lookup process, based on zones created and rooted in the in-addr.arpa
domain. These records are used to locate a computer by its IP address
and resolve this information to the DNS domain name for that computer.
PTR RRs can be added to a zone in several ways:
-
You can manually create a PTR RR for a static TCP/IP client computer
using the DNS , either as a separate procedure or as part of the
procedure for creating an A RR.
-
Computers use the DHCP Client service to dynamically register and update
their PTR RR in DNS when an IP configuration change occurs.
-
All other DHCP-enabled client computers can have their PTR RRs
registered and updated by the DHCP server if they obtain their IP lease
from a qualified server. The Windows 2000 and Windows Server 2003 DHCP
Server service provides this capability.
The pointer (PTR) resource record is used only in reverse lookup zones to support reverse lookup.
Service location (SRV) resource records
To locate Active Directory domain controllers, service
location (SRV) RRs are required. Typically, you can avoid manual
administration of the SRV RR when installing Active Directory.
By default, the Active Directory installation wizard
attempts to locate a DNS server based on the list of preferred or
alternate DNS servers, configured in any of its TCP/IP client
properties, for any of its active network connections. If a DNS server
that can accept dynamic update of the SRV RR (and other RRs related to
registering Active Directory as a service in DNS) is contacted, the
configuration process is complete.
If, during the installation, a DNS server that can
accept updates for the DNS domain name used to name your Active
Directory is not found, the wizard can install a DNS server locally and
automatically configure it with a zone to support the Active Directory
domain.
For example, if the Active Directory domain that you
chose for your first domain in the forest was example.microsoft.com, a
zone rooted at the DNS domain name of example.microsoft.com would be
added and configured to use with the DNS server running on the new
domain controller.
Whether or not you install the DNS Server service
locally, a file (Netlogon.dns) is written and created during the Active
Directory installation process that contains the SRV RRs and other RRs
needed to support the use of Active Directory. This file is created in
the systemroot\System32\Config folder.
If you are using a DNS server that fits one of the
following descriptions, you should use the records in Netlogon.dns to
manually configure the primary zone on that server to support Active
Directory.
-
The computer operating your DNS server is running on another platform,
such as UNIX, and cannot accept or recognize dynamic updates.
-
A DNS server at this computer that is not the DNS Server service
provided with the Windows Server 2003 operating system is authoritative
for the primary zone corresponding to the DNS domain name for your
Active Directory domain.
-
The DNS server supports the SRV RR, as defined in the Internet draft, “A
DNS RR specifying the location of services (DNS SRV)”, but does not
support dynamic updates.
-
For example, the DNS Server service provided with Windows NT Server 4.0,
when updated to Service Pack 4 or later, fits this description.
In the future, the SRV RR might also be used to
register and lookup other well-known TCP/IP services on your network if
applications implement and support DNS name queries that specify this
record type.
Other additional resource records are supported by
Windows Server 2003 DNS and are used less frequently in most zones.
These additional types of resource records can be added as needed using
the DNS console. For more information about supported resource records,
see “
Related Information” later in this document.
DNS-related Files
The following files relate to using and configuring DNS servers and clients.
|
File
|
Description
|
Boot
|
BIND boot configuration file. This file is not
created by the DNS console. However, as an optional configuration for
the DNS Server service, it can be copied from another DNS server running
the Berkeley Internet Name Domain (BIND) server implementation of DNS.
To use this file with the DNS Server service, you need to click From
file in Server properties. On BIND servers, this file is often called
the “named.boot” file.
|
Cache.dns
|
Used to preload resource records into the DNS server
names cache. DNS servers use this file to help locate root servers on
either your network or the Internet.
By default, this file contains DNS resource records
that prime the local cache of the server with the addresses of
authoritative root servers for the Internet. If you are setting up a DNS
server to resolve Internet DNS names, the information in this file is
required unless you enable the use of another DNS server as a forwarder
to resolve these names.
Traffic to the Internet root servers is heavy, but
because host names are not usually resolved at this level, the load can
be reasonably handled. Instead, the root hints file provides referral
information that can be useful during DNS name resolution to redirect a
query to other servers that are authoritative for names located beneath
the root.
For DNS servers operating privately on your internal
network, the DNS console can learn and replace the contents of this file
with internal root servers on your network, provided they are reachable
through the network when you are setting up and configuring new DNS
servers. It can be updated using the DNS console from the Root Hints tab
located under the applicable server properties.
This file preloads the server names cache when it is started.
|
Root.dns
|
Root zone file. This file can appear at a DNS server if it is configured as a root server for your network.
|
zone_name.dns
|
Used when a standard zone (either primary or
secondary) is added and configured for the server. Files of this type
are not created or used for primary type zones that are
directory-integrated, which are stored in the Active Directory database.
|
These files can be found in the systemroot\System32\Dns folder on the server computer.
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
-
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.
-
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.
-
When the refresh interval expires, an SOA query is used by the
destination server to request renewal of the zone from the source
server.
-
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.
-
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.
-
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
|
Name
|
Value
|
Description
|
FORMERR
|
1
|
Format Error. The name server did not interpret the OPT resource record.
|
SERVFAIL
|
2
|
Server Failure. The name server did not process the query because of a problem with the name server.
|
NOTIMPL
|
4
|
Not Implemented. The name server does not support the kind of query 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
|
Task
|
Load Data On Startup Set To: From File
|
Load Data On Startup Set To: From Registry
|
Load Data On Startup Set To: From Active Directory and Registry
|
Read root hints from:
|
Root hints file
|
If available, the root hints file. Otherwise, if the Directory is available and contains root hints, the directory
|
If the directory is available and contains root hints, from the directory. Otherwise, from the root hints file
|
Write root hints to:
|
Root hints file
|
Root hints file
|
If the directory is available, the directory
|
Read zones from:
|
Boot file, to get list of zones, then from zone files
|
Registry
|
The directory (for Active Directory–integrated zones) and the registry
|
Write zones to:
|
Boot file and the registry
|
Registry and, if the zone is Active Directory–integrated, the directory
|
Registry and, if the zone is Active Directory–integrated, the directory
|
Read server and zones parameters from:
|
Boot file and the registry
|
Registry and (for Active Directory–integrated zones) the directory
|
The directory (for Active Directory–integrated zones) and the registry
|
Write server and zones parameters to:
|
Boot file and the registry
|
Registry (for all zones) and (for Active Directory–integrated zones) the directory
|
The directory (for Active Directory–integrated zones) 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 Storage Option
|
Description
|
Domain partition
|
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. This is the only Active Directory
storage option for DNS zones that are replicated to domain controllers
running Windows 2000 Server.
|
Forest-wide DNS application directory partition
|
DNS application directory partition for the entire
forest. DNS zones stored in this application directory partition are
replicated to all DNS servers running on domain controllers in the
forest.
This DNS application directory partition is created when you install the DNS Server service on the first Windows Server 2003
domain controller in the forest.
|
Domain-wide DNS application directory partition
|
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 DNS application directory
partition is created when you first install the DNS Server service on a
Windows Server 2003 domain 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 domain
controller for the new domain.
|
Custom DNS application directory partition
|
DNS application directory partition for any domain
controller that is enlisted in its replication scope. This type of DNS
application directory partition does not exist by default and must be
created. DNS zones stored in this application 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.
|
DnsRecord
|
Multivalued attribute of a dnsNode object used to store the resource records associated with the named node object.
|
DnsProperty
|
Multivalued attribute of a dnsZone object used to store zone configuration 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 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:
-
A specified DNS domain name, stated as a fully qualified domain name.
-
A specified query type, which can either specify a resource record by type or a specialized type of query operation.
-
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:
-
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.
-
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.
-
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.
-
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.
-
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:
-
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.
-
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:
-
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.
-
If the query cannot be resolved using this local data, then it will
forward the query to the DNS server designated as a forwarder.
-
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:
-
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.
-
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.
-
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.
-
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).
|
Flags
|
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.
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.
|
RCODE1 and RCODE 2
|
The DHCP server uses these fields to specify the
response code from the A and PTR resource records registrations
performed on the client’s behalf and to 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:
-
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.
-
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.
-
The DNS client and DNS server begin TKEY negotiation.
-
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.
-
Next, by using the security mechanism, the DNS client and DNS server
verify their respective identities and establish the security context.
-
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.
-
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.
-
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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
I
believe there is an error on the description of the behavior of server
hosting an Active Directory Integrated Zone on that appears on this
article under the section "DNS Notify".
"DNS
servers that load a zone from Active Directory automatically poll the
directory (as specified by the SOA resource record’s Refresh Interval)"
DNS
servers that load a zone from Active Directory automatically poll the
directory (as specified by the dwDSPollingInterval setting on the
registry)"
