TCP/IP Fundamentals for Microsoft

Windows
Published: May 31, 2005 | Updated: April 18, 2006

Abstract

This chapter describes the details of the Domain Name System (DNS) and its use for private
intranets and the Internet. DNS is required to provide name resolution for domain names such as
www.example.com for all types of network applications from Internet browsers to the Active
Directory® directory service. A network administrator's understanding of DNS names, domains,
zones, name server roles, and replication is vital to the configuration and maintenance of a
properly functioning private intranet and the Internet.

On This Page

Chapter Objectives
The Domain Name System
Name Resolution
Name Server Roles
Resource Records and Zones
Zone Transfers
DNS Dynamic Update
Chapter Summary
Chapter Glossary

Chapter Objectives

After completing this chapter you will be able to:

 Define the components of DNS.

 Describe the structure and architecture of DNS as it is used on the Internet.
 Define the difference between domains and zones.
 Define recursive and iterative queries and how DNS forward and reverse lookups work.
 Define the various roles of DNS servers.
 Describe the common types of DNS resource records.
 Describe the different types of zone transfers.
 Define DNS dynamic update.

Top of page

The Domain Name System

The initial solution for name resolution on the Internet was a file named Hosts.txt that was used
on the now obsolete Advanced Research Projects Agency network (ARPANET), the predecessor
of the modern day Internet. When the number of hosts on the ARPANET was small, the
Hosts.txt file was easy to manage because it consisted of unstructured names and their
corresponding IPv4 addresses. Computers on the ARPANET periodically downloaded Hosts.txt
from a central location and used it for local name resolution. As the ARPANET grew into the
Internet, the number of hosts began to increase dramatically and the centralized administration
and manual distribution of a text file containing the names for computers on the Internet became
unwieldy.

The replacement for the Hosts.txt file needed to be distributed, to allow for a hierarchical name
space, and require minimal administrative overhead. The original design goal for DNS was to
replace the existing cumbersome, centrally administered text file with a lightweight, distributed
database that would allow for a hierarchical name space, delegation and distribution of
administration, extensible data types, virtually unlimited database size, and reasonable
performance.

DNS defines a namespace and a protocol for name resolution and database replication:

 The DNS namespace is based on a hierarchical and logical tree structure.

 The DNS protocol defines a set of messages sent over either User Datagram Protocol
(UDP) port 53 or Transmission Control Protocol (TCP) port 53. Hosts that originate DNS
queries send name resolution queries to servers over UDP first because it is faster. These
hosts, known as DNS clients, resort to TCP only if the returned data is truncated. Hosts
that store portions of the DNS database, known as DNS servers, use TCP when
replicating database information.

Historically, the most popular implementation of the DNS protocol is Berkeley Internet Name
Domain (BIND), which was originally developed at the University of California at Berkeley for
the 4.3 Berkeley Software Distribution release of the UNIX operating system.

DNS Components

Requests for Comments (RFCs) 974, 1034, and 1035 define the primary specifications for DNS.
From RFC 1034, DNS comprises the following three components:

1. The domain namespace and resource records

DNS defines a specification for a structured namespace as an inverted tree in which each
node and leaf of the tree names a set of information.

Resource records are records in the DNS database that can be used to configure the DNS
database server (such as the Start of Authority [SOA] record) or to contain information of
different types to process client queries (such as Address [A] records or Mail Exchanger
[MX] records). Typical resource records contain resources by name and their IP
addresses. Name queries to DNS database servers are attempts to extract information of a
 certain type from the namespace. The name query requests a name of interest and a
specific type of record. For example, a name query would provide a host name and ask
for the corresponding IPv4 or IPv6 address.

2. Name servers

Name servers store resource records and information about the domain tree structure and
attempt to resolve received client queries. DNS database servers, hereafter referred to as
name servers or DNS servers, either contain the requested information in their resource
records or have pointer records to other name servers that can help resolve the client
query. If the name server contains the resource records for a given part of the namespace,
the server is said to be authoritative for that part of the namespace. Authoritative
information is organized into units called zones.

3. Resolvers

Resolvers are programs that run on DNS clients and DNS servers and that create queries
to extract information from name servers. A DNS client uses a resolver to create a DNS
name query. A DNS server uses a resolver to contact other DNS servers to resolve a
name on a DNS client's behalf. Resolvers are usually built into utility programs or are
accessible through library functions, such as the Windows Sockets gethostbyname() or
getaddrinfo() functions.

DNS Names

DNS names have a very specific structure, which identifies the location of the name in the DNS
namespace. A fully qualified domain name (FQDN) is a DNS domain name that has been
constructed from its location relative to the root of the namespace (known as the root domain).
FQDNs have the following attributes:

 FQDNs consist of the series of names from the name of the host or computer to the root
domain.
 A period character separates each name.
 Each FQDN ends with the period character, which indicates the root domain.
 Each name within the FQDN can be no more than 63 characters long.
 The entire FQDN can be no more than 255 characters long.
 FQDNs are not case-sensitive.
 RFC 1034 requires the names that make up a FQDN to use only the characters a-z, A-Z,
0-9, and the dash or minus sign (-). RFC 2181 allows additional characters and is
supported by the DNS Server service in Microsoft® Windows Server™ 2003 operating
systems.

Domains and Subdomains

The DNS namespace is in the form of a logical inverted tree structure. Each branch point (or
node) in the tree is given a name that is no more than 63 characters long. Each node of the tree is
a portion of the namespace called a domain. A domain is a branch of the tree and can occur at
any point in the tree structure. Domains can be further partitioned at node points within the
domain into subdomains for the purposes of administration or load balancing. The domain name
identifies the domain's position in the DNS hierarchy. The FQDN identifies the domain relative
to the root. You create domain names and FQDNs by combining the names of the nodes from the
designated domain node back to the root and separating each node with a period (.). The root of
the tree has the special reserved name of "" (null), which you indicate by placing a final period at
the end of the domain name (such as www.sales.example.com.). Domains and subdomains are
grouped into zones to allow for distributed administration of the DNS namespace.

Figure 8-1 shows the DNS namespace as it exists for the Internet.

Figure 8-1 The DNS namespace

See full-sized image

Figure 8-1 shows a few of the top-level domains and example hosts in the "microsoft.com."
domain. A trailing period designates a domain name of a host relative to the root domain. To
connect to that host, a user would specify the name "www.microsoft.com." If the user does not
specify the final period, the DNS resolver automatically adds it to the specified name. Individual
organizations manage second-level domains (subdomains of the top level domains) and their
name servers. For example, Microsoft manages the "microsoft.com." domain.

DNS Servers and the Internet

Domains define different levels of authority in a hierarchical structure. The top of the hierarchy
is called the root domain. The DNS namespace on the Internet, as shown in Figure 8-1, has the
following structure:

 Root domain
 Top-level domains
 Second-level domains

The root domain uses a null label, which you write as a single period (.). In the United States, the
Internet Assigned Names Authority (IANA) manages several root domain name servers.
The next level in the hierarchy is divided into a series of nodes called the top-level domains. The
top-level domains are assigned by organization type and by country/region. Some of the more
common top-level domains are the following:

 com – Commercial organizations in the United States (for example, microsoft.com for the
Microsoft Corporation).
 edu – Educational organizations in the United States.
 gov – United States governmental organizations.
 int – International organizations.
 mil – United States military organizations.
 net - Networking organizations.
 org – Noncommercial organizations.
 xx – Two-letter country code names that follow the International Standard 3166. For
example, “.fr” is the country code for France.
 arpa – Used to store information for DNS reverse queries.

Each top-level domain has name servers that IANA administers. Top-level domains can contain
second-level domains and hosts.

Second-level domains contain the domains and names for organizations and countries/regions.
The names in second-level domains are administered by the organization or country/region either
directly (by placing its own DNS server on the Internet) or by using an Internet service provider
(ISP) who manages the names for an organization or country/region on its customer's behalf.

Zones

A zone is a contiguous portion of a domain of the DNS namespace whose database records exist
and are managed in a particular DNS database file stored on one or multiple DNS servers. You
can configure a single DNS server to manage one or multiple zones. Each zone is anchored at a
specific domain node, referred to as the zone's root domain. Zone files do not necessarily contain
the complete branch (that is, all subdomains) under the zone's root domain. For example, you can
partition a domain into several subdomains, which are controlled by separate DNS servers. You
might break up domains across multiple zone files if you want to distribute management of the
domain across different groups or make data replication more efficient.

Figure 8-2 shows the difference between domains and zones.

Figure 8-2 Domains and zones
See full-sized image

In the example, "microsoft.com" is a domain (the entire branch of the DNS namespace that starts
with the microsoft.com. node), but the entire domain is not controlled by one zone file. Part of
the domain is in a zone for "microsoft.com." and part of the domain is in a zone for the
"dev.microsoft.com." domain. These zones correspond to different DNS database files that can
reside on the same or different DNS servers.

Top of page

Name Resolution

The two types of queries that a DNS resolver (either a DNS client or another DNS server) can
make to a DNS server are the following:

 Recursive queries

In a recursive query, the queried name server is requested to respond with the requested
data or with an error stating that data of the requested type or the specified domain name
does not exist. The name server cannot just refer the DNS resolver to a different name
server. A DNS client typically sends this type of query.

 Iterative queries

In an iterative query, the queried name server can return the best answer it currently has
back to the DNS resolver. The best answer might be the resolved name or a referral to
another name server that is closer to fulfilling the DNS client's original request. DNS
servers typically send iterative queries to query other DNS servers.

DNS Name Resolution Example

To show how recursive and iterative queries are used for common DNS name resolutions,
consider a computer running a Microsoft Windows® XP operating system or Windows Server
2003 connected to the Internet. A user types http://www.example.com in the Address field of
their Internet browser. When the user presses the ENTER key, the browser makes a Windows
Sockets function call, either gethostbyname() or getaddrinfo(), to resolve the name
http://www.example.com to an IP address. For the DNS portion of the Windows host name
resolution process, the following occurs:

1. The DNS resolver on the DNS client sends a recursive query to its configured DNS
server, requesting the IP address corresponding to the name "www.example.com". The
DNS server for that client is responsible for resolving the name and cannot refer the DNS
client to another DNS server.
2. The DNS server that received the initial recursive query checks its zones and finds no
zones corresponding to the requested domain name; the DNS server is not authoritative
for the example.com domain. Because the DNS server has no information about the IP
addresses of DNS servers that are authoritative for example.com. or com., it sends an
iterative query for www.example.com. to a root name server.
3. The root name server is authoritative for the root domain and has information about name
servers that are authoritative for top-level domain names. It is not authoritative for the
example.com. domain. Therefore, the root name server replies with the IP address of a
name server for the com. top-level domain.
4. The DNS server of the DNS client sends an iterative query for www.example.com. to the
name server that is authoritative for the com. top-level domain.
5. The com. name server is authoritative for the com. domain and has information about the
IP addresses of name servers that are authoritative for second-level domain names of the
com. domain. It is not authoritative for the example.com. domain. Therefore, the com.
name server replies with the IP address of the name server that is authoritative for the
example.com. domain.
6. The DNS server of the DNS client sends an iterative query for www.example.com. to the
name server that is authoritative for the example.com. domain.
7. The example.com. name server replies with the IP address corresponding to the FQDN
www.example.com.
8. The DNS server of the DNS client sends the IP address of www.example.com to the DNS
client.

Figure 8-3 shows this process.

Figure 8-3 Example of recursive and iterative queries in DNS name resolution
See full-sized image

All DNS queries are DNS Name Query Request messages. All DNS replies are DNS Name
Query Response messages.

In practice, DNS servers cache the results of queries on an ongoing basis. If a DNS server finds
an entry matching the current request in its cache, it does not send an iterative DNS query. This
example assumes that no cache entries were in any of the DNS servers to prevent the sending of
the iterative name queries.

Forward lookups are queries in which a DNS client attempts to resolve an FQDN to its
corresponding IP address. Zones that contain FQDN-to-IP address mappings are known as
forward lookup zones.

Reverse Queries

In a reverse query, instead of supplying a name and asking for an IP address, the DNS client
provides the IP address and requests the corresponding host name. Reverse queries are also
known as reverse lookups, and zones that contain IP address-to-FQDN mappings are known as
reverse lookup zones.

Because you cannot derive the IP address from a domain name in the DNS namespace, only a
thorough search of all domains could guarantee a correct answer. To prevent an exhaustive
search of all domains for a reverse query, reverse name domains and pointer (PTR) resource
records were created.

An example of an application that uses reverse queries is the Tracert tool, which by default uses
reverse queries to display the names of the routers in a routing path. If you are going to use
reverse queries, you must create reverse lookup zones and PTR records when you administer a
DNS server so that reverse queries can be satisfied.

Reverse Queries for IPv4 Addresses

To support reverse lookups for IPv4 addresses, a special domain named in-addr.arpa. was
created. Nodes in the in-addr.arpa domain are named after the numbers in the dotted decimal
representation of IPv4 addresses. But because IPv4 addresses get more specific from left to right
and domain names get more specific from right to left, the order of IPv4 address octets must be
reversed when building the in-addr.arpa domain name corresponding to the IPv4 address. For
example, for the generalized IPv4 address w.x.y.z, the corresponding reverse query name is
z.y.x.w.in-addr.arpa. IANA delegates responsibility for administering the reverse query
namespace below the in-addr.arpa domain to organizations as they are assigned IPv4 address
prefixes.

Figure 8-4 shows an example of the reverse lookup portion of the DNS namespace.

Figure 8-4 An example of a reverse lookup portion of the DNS namespace

Within the in-addr.arpa domain, special pointer (PTR) resource records are added to associate
the IPv4 addresses to their corresponding host names. To find a host name for the IPv4 address
157.54.200.2, a DNS client sends a DNS query for a PTR record for the name 2.200.54.157.in-
addr.arpa. Reverse queries use the same name resolution process previously described for
forward lookups (a combination of recursive and iterative queries). The DNS server finds the
PTR record that contains the FQDN that corresponds to the IPv4 address 157.54.200.2 and sends
that FQDN back to the DNS client.

Reverse Queries for IPv6 Addresses

IPv6 reverse lookups use the ip6.arpa. domain. To create the domains for reverse queries, each
hexadecimal digit in the fully expressed 32-digit IPv6 address becomes a separate level in the
reverse domain hierarchy in inverse order.

For example, the reverse lookup domain name for the address 3ffe:ffff::1:2aa:ff:fe3f:2a1c (fully
expressed as 3ffe:ffff:0000:0001:02aa:00ff:fe3f:2a1c) is
c.1.a.2.f.3.e.f.f.f.0.0.a.a.2.0.1.0.0.0.0.0.0.0.f.f.f.f.e.f.f.3.ip6.arpa.

Just as in IPv4 addresses, PTR records in the reverse IPv6 domain map IPv6 addresses to
FQDNs.

Caching and TTL

For each resolved query (either recursive or iterative), the DNS resolver caches the returned
information for a time that is specified in each resource record in the DNS response. This is
known as positive caching. The amount of time in seconds to cache the record data is referred to
as the Time To Live (TTL). The network administrator of the zone that contains the record
decides on the default TTL for the data in the zone. Smaller TTL values help ensure that data
about the domain is more consistent across the network if the zone data changes often. However,
this practice also increases the load on name servers because positive cache entries time out more
quickly.

After a DNS resolver caches data, it must start counting down from the received TTL so that it
will know when to remove the data from its cache. For queries that can be satisfied by this
cached data, the TTL that is returned is the current amount of time left before the data is flushed
from the DNS cache. DNS client resolvers also have data caches and honor the TTL value so that
they know when to remove the data.

The DNS Client service in Windows XP and Windows Server 2003 and the DNS Server service
in Windows Server 2003 support positive caching.

Negative Caching

As originally defined in RFC 1034, negative caching is the caching of failed name resolutions. A
failed name resolution occurs when a DNS server returns a DNS Name Query Response message
with an indication that the name was not found. Negative caching can reduce response times for
names that DNS cannot resolve for both the DNS client and DNS servers during an iterative
query process. Like positive caching, negative cache entries eventually time out and are removed
from the cache based on the TTL in the received DNS Name Query Response message.

The DNS Client service in Windows XP and Windows Server 2003 and the DNS Server service
in Windows Server 2003 support negative caching.

Round Robin Load Balancing

DNS Name Query Response messages can contain multiple resource records. For example, for a
simple forward lookup, the DNS Name Query Response message can contain multiple Address
(A) records that contain the IPv4 addresses associated with the desired host. When multiple
resource records for the same resource record type exist, the following issues arise:

 For the DNS server, how to order the resource records in the DNS Name Query Response
message
 For the DNS client, how to choose a specific resource record in the DNS Name Query
Response message

To address these issues, RFC 1794 describes a mechanism named round robin or load sharing to
share and distribute loads for network resources. The central assumption of RFC 1794 is that
when multiple resource records for the same resource record type and the same name exist,
multiple servers are offering the same type of service to multiple users. For example, the
www.microsoft.com Web site is actually hosted by multiple Web servers with different IPv4
addresses. To attempt to distribute the load of servicing all the users who access
www.microsoft.com, the DNS servers that are authoritative for microsoft.com modify the order
of the resource records for the www.microsoft.com name in successive DNS Name Query
Response messages. The DNS client uses the data in the first resource record in the response.

For example, if there were three A records for www.microsoft.com with the IPv4 addresses of
131.107.0.99, 131.107.0.100, and 131.107.0.101, the round robin scheme works as follows:

 For the first request, the order of the resource records in the DNS Name Query Response
message is 131.107.0.99-131.107.0.100-131.107.0.101.
 For the second request, the order of the resource records in the DNS Name Query
Response message is 131.107.0.100-131.107.0.101-131.107.0.99.
 For the third request, the order of the resource records in the DNS Name Query Response
message is 131.107.0.101-131.107.0.99-131.107.0.100.

The pattern repeats for subsequent queries. For an arbitrary number of resource records, the
rotation process cycles through the list of resource records.

A DNS server running Windows Server 2003 that is responding to a recursive query by default
attempts to order the resource records according to the addresses that most closely match the IP
address of the originating DNS client, and you can configure that server for round robin
according to RFC 1794. To determine the addresses that are the closest match to the IPv4
address of the DNS client, the DNS Server service in Windows Server 2003 orders the addresses
by using a high-order bit-level comparison of the DNS client's IPv4 address and the IPv4
addresses associated with the queried host name. This comparison technique is similar to the
route determination process, in which IPv4 or IPv6 examines the IPv4 or IPv6 routing table to
determine the route that most closely matches the destination address of a packet being sent or
forwarded.

Top of page

Name Server Roles

DNS servers store information about portions of the domain namespace. When name servers
have one or more zones for which they are responsible, they are said to be authoritative servers
for those zones. Using the example in Figure 8-2, the name server containing the
dev.microsoft.com zone is an authoritative server for dev.microsoft.com.

Configuration of a DNS server includes adding name server (NS) resource records for all the
other name servers that are in the same domain. Using the example on the previous page, if the
two zones were on different name servers, each would be configured with an NS record about
the other. These NS records provide pointers to the other authoritative servers for the domain.

DNS defines two types of name servers, each with different functions:

 Primary

A primary name server gets the data for its zones from locally stored and maintained
files. To change a zone, such as adding subdomains or resource records, you change the
zone file at the primary name server.

 Secondary

A secondary name server gets the data for its zones across the network from another
name server (either a primary name server or another secondary name server). The
process of obtaining this zone information (that is, the database file) across the network is
referred to as a zone transfer. Zone transfers occur over TCP port 53.

The following are reasons to have secondary name servers within an enterprise network:

o Redundancy: At least two DNS servers, a primary and at least one secondary,
serving each zone are needed for fault tolerance.
o Remote locations: Secondary name servers (or other primary servers for
subdomains) are needed in remote locations that have a large number of DNS
clients. Clients should not have to communicate across slower wide area network
(WAN) links for DNS queries.
o Load distribution: Secondary name servers reduce the load on the primary name
server.
Because information for each zone is stored in separate files, the primary or secondary name
server designation is defined at a zone level. In other words, a specific name server may be a
primary name server for certain zones and a secondary name server for other zones.

When defining a zone on a secondary name server, you configure the zone with the name server
from which the zone information is to be obtained. The source of the zone information for a
secondary name server is referred to as a master name server. A master name server can be either
a primary or secondary name server for the requested zone. Figure 8-5 shows the relationship
between primary, secondary, and master name servers.

Figure 8-5 Primary, secondary, and master name servers

See full-sized image

When a secondary name server starts up, it contacts the master name server and initiates a zone
transfer for each zone for which it is acting as a secondary name server. Zone transfers also can
occur periodically (provided that data on the master name server has changed) as specified in the
SOA record of the zone file. The "Resource Records and Zones" section of this chapter describes
the SOA resource record.

Forwarders

When a DNS server receives a query, it attempts to locate the requested information within its
own zone files. If this attempt fails because the server is not authoritative for the domain of the
requested name and it does not have the record cached from a previous lookup, it must
communicate with other name servers to resolve the request. On a globally connected network
such as the Internet, DNS queries for names that do not use the second-level domain name of the
organization might require interaction with DNS servers across WAN links outside of the
organization. To prevent all the DNS servers in the organization from sending their queries over
the Internet, you can configure forwarders. A forwarder sends queries across the Internet. Other
DNS servers in the organization are configured to forward their queries to the forwarder.

Figure 8-6 shows an example of intranet servers using a forwarder to resolve Internet names.
Figure 8-6 Using a forwarder to resolve Internet names
See full-sized image

A name server can use a forwarder in non-exclusive or exclusive mode.

Forwarders in Non-exclusive Mode

In non-exclusive mode, when a name server receives a DNS query that it cannot resolve through
its own zone files, it sends a recursive query to its forwarder. The forwarder attempts to resolve
the query and returns the results to the requesting name server. If the forwarder is unable to
resolve the query, the name server that received the original query attempts to resolve the query
using iterative queries.

A name server using a forwarder in non-exclusive mode does the following when attempting to
resolve a name:

1. Checks its local cache.

2. Checks its zone files.
3. Sends a recursive query to a forwarder.
4. Attempts to resolve the name through iterative queries to other DNS servers.

Forwarders in Exclusive Mode

In exclusive mode, name servers rely on the name-resolving ability of the forwarders. When a
name server in exclusive mode receives a DNS query that it cannot resolve through its own zone
files, it sends a recursive query to its designated forwarder. The forwarder then carries out
whatever communication is necessary to resolve the query and returns the results to the
originating name server. If the forwarder is unable to resolve the request, the originating name
server returns a query failure to the original DNS client. Name servers in exclusive mode make
no attempt to resolve the query on their own if the forwarder is unable to satisfy the request.

A name server using a forwarder in exclusive mode does the following when attempting to
resolve a name:

1. Checks its local cache.

2. Checks its zone files.
3. Sends a recursive query to a forwarder.

Caching-Only Name Servers

Although all DNS servers cache queries that they have resolved, caching-only servers are DNS
servers that only perform queries, cache the answers, and return the results. Caching-only servers
are not authoritative for any domains and contain only the information that they have cached
while attempting to resolve queries.

When caching-only servers are started, they do not perform any zone transfers because they have
no zones and no entries exist in their caches. Initially, the caching-only server must forward
queries until the cache has been built up to a point where it can service commonly used queries
by just using its cache entries.

Top of page

Resource Records and Zones

If your organization is connected to the Internet, in many cases you do not need to maintain a
DNS infrastructure. For small networks, DNS name resolution is simpler and more efficient by
having the DNS client query a DNS server that is maintained by an ISP. Most ISPs will maintain
domain information for a fee. If your organization wants to have control over its domain or not
incur the costs of using an ISP, you can set up your organization's own DNS servers.

In both cases, either going through an ISP or setting up separate DNS servers, the IANA must be
informed of the domain name of the organization and the IP addresses of at least two DNS
servers on the Internet that service the domain. An organization can also set up DNS servers
within itself independent of the Internet.

At least two computers as DNS servers are recommended for reliability and redundancy—a
primary and a secondary name server. The primary name server maintains the database of
information, which is then replicated from the primary name server to the secondary name
server. This replication allows name queries to be serviced even if one of the name servers is
unavailable. Replication is scheduled based on how often names change in the domain.
Replication should be frequent enough so that changes are reflected on both servers. However,
excessive replication can have a negative impact on the performance of the network and name
servers.
Resource Record Format

Resource records have the following format:

owner TTL type class RDATA

 owner The domain name of the resource record.

 TTL (Time to Live) The length of time in seconds that a DNS resolver should wait before
it removes from its cache an entry that corresponds to the resource record.
 type The type of resource record.
 class The protocol family in use, which is typically IN for the Internet class.
 RDATA The resource data for the resource record type. For example, for an address (A)
resource record, RDATA is the 32-bit IPv4 address that corresponds to the FQDN in the
owner field.

Resource records are represented in binary form in DNS request and response messages. In text-
based DNS database files, most resource records are represented as a single line of text. For
readability, blank lines and comments are often inserted in the database files and are ignored by
the DNS server. Comments always start with a semicolon (;) and end with a carriage return.

The following is an example A resource record stored in a DNS database file:

srv1.dev.microsoft.com. 3600 A IN 157.60.221.205

Each resource record starts with the owner in the first column (srv1.dev.microsoft.com.). If the
first column is blank, then it is assumed that the owner for this record is the owner of the
previous record. The owner is followed by the TTL (3600 seconds = 1 hour), type (A = Address
record), class (IN = Internet), and then the RDATA (Resource Data = 157.60.221.205). If the
TTL value is not present, the DNS server sets the value to the TTL specified in the SOA (Start of
Authority) record of the zone.

Resource Record Types

The DNS standards define many types of resource records. The most commonly used resource
records are the following:

 SOA Identifies the start of a zone of authority. Every zone contains an SOA resource
record at the beginning of the zone file, which stores information about the zone,
configures replication behavior, and sets the default TTL for names in the zone.
 A Maps an FQDN to an IPv4 address.
 AAAA Maps an FQDN to an IPv6 address.
 NS Indicates the servers that are authoritative for a zone. NS records indicate primary
and secondary servers for the zone specified in the SOA resource record, and they
indicate the servers for any delegated zones. Every zone must contain at least one NS
record at the zone root.
 PTR Maps an IP address to an FQDN for reverse lookups.
  CNAME Specifies an alias (synonymous name).
 MX Specifies a mail exchange server for a DNS domain name. A mail exchange server is
a host that receives mail for the DNS domain name.
 SRV Specifies the IP addresses of servers for a specific service, protocol, and DNS
domain.

RFCs 1035, 1034, 1183, and others define less frequently used resource records. The DNS
Server service in Windows Server 2003 is fully compliant with RFCs 1034, 1035, and 1183.

The DNS Server service in Windows Server 2003 also supports the following resource record
types that are Microsoft-specific:

 WINS Indicates the IPv4 address of a Windows Internet Name Service (WINS) server
for WINS forward lookup. The DNS Server service in Windows Server 2003 can use a
WINS server for looking up the host portion of a DNS name.
 WINS-R Indicates the use of WINS reverse lookup, in which a DNS server uses a
NetBIOS Adapter Status message to find the host portion of the DNS name given its IPv4
address.
 ATMA Maps DNS domain names to Asynchronous Transfer Mode (ATM) addresses.

For detailed information about the structure and contents of various types of DNS resource
records, see the topic titled "Resource records reference" in Help and Support for Windows
Server 2003.

Delegation and Glue Records

You add delegation and glue records to a zone file to indicate the delegation of a subdomain to a
separate zone. For example, in Figure 8-2, the DNS server that is authoritative for the
microsoft.com zone must be configured so that, when resolving names for the
dev.microsoft.com, the DNS server can determine the following:

 That a separate zone for that domain exists.

A delegation is an NS record in the parent zone that lists the name server that is
authoritative for the delegated zone.

 Where the zone for that domain resides.

A glue record is an A record for the name server that is authoritative for the delegated
zone.

For example, in Figure 8-2, the name server for the microsoft.com. domain has delegated
authority for the dev.microsoft.com zone to the name server devdns.dev.microsoft.com at the
IPv4 address of 157.60.41.59. In the zone file for the microsoft.com. zone, the following records
must be added:

dev.microsoft.com. IN NS devdns.dev.microsoft.com.
devdns.dev.microsoft.com. IN A 157.60.41.59

Without the delegation record for dev.microsoft.com, queries for all names ending in
dev.microsoft.com would fail. Glue records are needed when the name of the name server that is
authoritative for the delegated zone is in the domain of the name server attempting name
resolution. In the example above, we need the A record for devdns.dev.microsoft.com. because
that FQDN is within the microsoft.com. portion of the DNS namespace. Without this A record,
the microsoft.com. DNS server would be unable to locate the name server for the
dev.microsoft.com. zone, and all name resolutions for names in the dev.microsoft.com domain
would fail. A glue record is not needed when the name of the authoritative name server for the
delegated zone is in a domain that is different than the domain of the zone file. In this case, the
DNS server would use normal iterative queries to resolve the name to an IP address.

The DNS Server service in Windows Server 2003 automatically adds delegation and glue
records when you delegate a subdomain.

The Root Hints File

The root hints file, also known as the cache file, contains the names and addresses of root name
servers. For resolving domain names on the Internet, the default file provided with the DNS
Server service in Windows Server 2003 has the records for the root servers of the Internet. For
installations not connected to the Internet, the file should be replaced to contain the name servers
authoritative for the root of the private network. This file is named Cache.dns and is stored in the
systemroot/System32/Dns folder.

For the current Internet cache file, see the FTP site for InterNIC.

Top of page

Zone Transfers

Secondary name servers obtain zone files from a master name server using a zone transfer. The
zone transfer replicates the set of records in the zone file from the master server to the secondary
server. Zone transfers occur for all zones for which a DNS server is a secondary name server
upon startup and on an ongoing basis to ensure that the most current information about the zone
is reflected in the local zone file. The two types of zone transfers are full and incremental.

Full Zone Transfer

The original DNS RFCs defined zone transfers as a transfer of the entire zone file, regardless of
how the file has changed since the last time it was transferred. In a full zone transfer, the
following process occurs:

1. The secondary server waits until the next refresh time (as specified in the SOA resource
record) and then queries the master server for the SOA resource record for the zone.
2. The master server responds with the SOA resource record.
 3. The secondary server checks the Serial Number field of the returned SOA resource
record. If the serial number in the SOA resource record is higher than the serial number
of the SOA resource record of the locally stored zone file, then there have been changes
to the zone file on the master server and a zone transfer is needed. Whenever a resource
record is changed on the master name server, the serial number in the SOA resource
record is updated.

The secondary server sends an AXFR request (a request for a full zone transfer) to the
master server.

4. The secondary server initiates a TCP connection with the master server and requests all
of the records in the zone database. After the zone transfer, the Serial Number field in the
SOA record of the local zone file matches the Serial Number field in the SOA record of
the master server.

Figure 8-7 shows a full zone transfer.

Figure 8-7 A full zone transfer

See full-sized image

If the secondary server does not receive a response to the SOA query, it retries SOA queries
using a retry time interval specified in the SOA resource record in the local zone file. The
secondary server continues to retry until the time elapsed since attempting to perform a zone
transfer reaches an expiration time specified in the SOA resource record in the local zone file.
After the expiration time, the secondary server closes the zone file and does not use it to answer
subsequent queries. The secondary server keeps attempting to perform the zone transfer. When
the zone transfer succeeds, the local zone file is opened and used for subsequent queries.

Incremental Zone Transfer

In a full zone transfer, the entire zone file is transferred. This can consume a substantial portion
of processing resources and network bandwidth when the zone files are large and when zone
records are frequently changed. To minimize the amount of information that is sent in a zone
transfer for changes to zone records, RFC 1995 specifies a standard method of performing
incremental zone transfers. In an incremental zone transfer, only the resource records that have
changed (been added, deleted, or modified) are sent during the zone transfer.

In an incremental zone transfer, the secondary server performs the same query for the SOA
record of the master server and comparison of the Serial Number field. If changes exist, the
secondary server sends an IXFR request (a request for an incremental zone transfer) to the
master server. The master server sends the records that have changed, and the secondary server
builds a new zone file from the records that have not changed and the records in the incremental
zone transfer.

Figure 8-8 shows an incremental zone transfer.

Figure 8-8 An incremental zone transfer

See full-sized image

For the master server to determine the records that have changed, it must maintain a history
database of changes made to its zone files. The zone file changes are linked to a serial number so
that the master server can determine which changes were made to the zone past the serial number
indicated in the IXFR request from the secondary server.

The DNS Server service in Windows Server 2003 supports incremental zone transfer.

DNS Notify

For both full and incremental zone transfers, the secondary server always initiates the zone
transfer based on periodically querying the master server for its SOA record. The original DNS
RFCs do not define a notification mechanism if the master server wanted to immediately
propagate a large number of changes to its secondary servers.

To improve the consistency of data among secondary servers, RFC 1996 specifies DNS Notify,
an extension of DNS that allows master servers to send notifications to secondary servers that a
zone transfer might be needed. Upon receipt of a DNS notification, secondary servers request the
SOA record of their master server and initiate a full or incremental zone transfer as needed.

Figure 8-9 shows the DNS notify process.

Figure 8-9 The DNS notify process
See full-sized image

To determine the secondary servers to which notifications should be sent, the master server
maintains a notify list (a list of IP addresses) for each zone. The master server sends notifications
to only the servers in the notify list when the zone is updated.

The DNS Server service in Windows Server 2003 supports the configuration of a notify list (a
list of IPv4 addresses) for each zone.

Top of page

DNS Dynamic Update

DNS was originally defined as a name resolution scheme for relatively static names and
addresses; DNS records contained information about servers, whose name and address
configuration did not change often. Therefore, the manual administration of resource records in
zone files was manageable. These original assumptions work well for an environment that is
based on server and client computers that are statically configured, in which the client computers
communicate only with the server computers and address configuration does not change. With
the advent of peer-to-peer communications and applications and the Dynamic Host
Configuration Protocol (DHCP), both of the assumptions of static DNS are challenged. In a
Windows-based environment, client computers often communicate directly with each other and
are automatically configured using DHCP. To communicate with each other, client computers
must be able to resolve each other's names; therefore they must have corresponding DNS
resource records. With DHCP, the address configuration of client computers could change every
time they start. Manually administering DNS records for this environment is obviously
impractical.

Therefore, RFC 2136 defines DNS dynamic update to provide an automated method to populate
the DNS namespace with the current names and addresses for client and server computers by
dynamically updating zone data on a zone's primary server. With DNS dynamic update, DNS
records are automatically created, modified, and removed by either host computers or DHCP
servers on their behalf. For example, a client computer that supports DNS dynamic update sends
UPDATE messages to its DNS server to automatically add A, AAAA, and PTR records. The
DNS server, which must also support DNS dynamic update, verifies that the sender is permitted
to make the updates and then updates its local zone files.

The DNS Client service in Windows XP and Windows Server 2003 and the DNS Server service
in Windows Server 2003 support DNS dynamic update.

Top of page

Chapter Summary

The chapter includes the following pieces of key information:

  DNS is a namespace and a protocol for replicating databases and resolving FQDNs used
on the Internet and intranets. DNS consists of the domain namespace, name servers that
store resource records, and DNS resolvers.
 A domain is a branch of the DNS namespace beginning at its root node. All of the
resource records in a domain are stored in zones on DNS servers. A zone is a contiguous
portion of a DNS domain whose information is stored in a file on a DNS server.
 On the Internet, DNS consists of the root domain, top-level domains, and second-level
domains. IANA manages the names and DNS servers of the root domain and the top-
level domains. Individual organizations are responsible for managing the names in their
second-level domains.
 DNS resolvers use either recursive or iterative queries. A recursive query is used to
request definitive information about a name, and DNS clients typically use them for
FQDN resolution. An iterative query is used to request best-effort information about a
name, and DNS servers typically use them to query other DNS servers.
 Forward lookups provide an IP address based on an FQDN. Reverse lookups provide an
FQDN based on an IP address.
 DNS servers can have the role of a primary server (in which the records are modified by
the DNS administrator) or a secondary server (in which the records are obtained from
another server) for each zone for which they are authoritative. A master server is a server
from which a secondary server obtains a zone transfer.
 DNS defines many types of resource records, the most common of which are SOA, A,
AAAA, NS, PTR, CNAME, MX, and SRV.
 Zone transfers can transfer either the entire zone file (known as a full zone transfer) or
just the records that have changed (known as an incremental zone transfer). DNS Notify
is a standard mechanism by which a master name server notifies secondary name servers
to check for changes in zone files.
 DNS dynamic update is a standard method for hosts, or DHCP servers on behalf of hosts,
to automatically update the zones of primary DNS servers with resource records that
correspond to current names and address configurations.

Top of page

Chapter Glossary

DNS – See Domain Name System (DNS).

DNS dynamic update - An update to the DNS standard that permits DNS clients to dynamically
register and update their resource records in the zones of the primary server.

DNS server – A server that maintains a database of mappings of FQDNs to various types of data,
such as IP addresses.

domain – Any branch of the DNS namespace.

Domain Name System (DNS) – A hierarchical, distributed database that contains mappings of
DNS domain names to various types of data, such as IP addresses. DNS enables the location of
computers and services by user-friendly names and the discovery of other information stored in
the database.

forward lookup – A DNS query that maps an FQDN to an IP address.

forwarder - A DNS server designated by other internal DNS servers to be used to forward
queries for resolving external or offsite DNS domain names, such as those used on the Internet.

FQDN – See fully qualified domain name.

fully qualified domain name (FQDN) - A DNS name that has been stated to indicate its absolute
location in the domain namespace tree. An FQDN has a trailing period (.) to qualify its position
relative to the root of the namespace. An example is host.example.microsoft.com.

host name – The DNS name of a host or interface on a network. For one computer to find
another, the name of the computer to locate must either appear in the Hosts file on the computer
that is looking, or the name must be known by a DNS server. For most Windows-based
computers, the host name and the computer name are the same.

Host name resolution – The process of resolving a host name to a destination IP address.

Hosts file – A local text file in the same format as the 4.3 BSD release of UNIX /etc/hosts file.
This file maps host names to IP addresses, and it is stored in the
systemroot\System32\Drivers\Etc folder.

iterative query - A query made to a DNS server for the best answer the server can provide.

master server – A DNS server that is authoritative for a zone and that is also a source of zone
information for other secondary servers. A master server can be either a primary or secondary
master server, depending on how the server obtains its zone data.

primary server – A DNS server that is authoritative for a zone and that can be used as a point of
update for the zone. Only primary servers can be updated directly to process zone updates, which
include adding, removing, or modifying resource records that are stored as zone data.

recursive query – A query made to a DNS server in which the requester asks the server to assume
the full workload and responsibility for providing a complete answer to the query. The DNS
server will then use separate iterative queries to other DNS servers on behalf of the requester to
assist in completing an answer for the recursive query.

reverse lookup – A DNS query that maps an IP address to an FQDN.

root domain - The beginning of the DNS namespace.

secondary server - A DNS server that is authoritative for a zone and that obtains its zone
information from a master server.
second-level domain – A DNS domain name that is rooted hierarchically at the second tier of the
domain namespace, directly beneath the top-level domain names. Top-level domain names
include .com and .org. When DNS is used on the Internet, second-level domains are names that
are registered and delegated to individual organizations and businesses.

subdomain - A DNS domain located directly beneath another domain (the parent domain) in the
namespace tree. For example, example.microsoft.com would be a subdomain of the domain
microsoft.com.

top-level domains – Domain names that are rooted hierarchically at the first tier of the domain
namespace directly beneath the root (.) of the DNS namespace. On the Internet, top-level domain
names such as .com and .org are used to classify and assign second-level domain names (such as
microsoft.com) to individual organizations and businesses according to their organizational
purpose.

zone – A manageable unit of the DNS database that is administered by a DNS server. A zone
stores the domain names and data of the domain with a corresponding name, except for domain
names stored in delegated subdomains.

zone transfer - The synchronization of authoritative DNS data between DNS servers. A DNS
server configured with a secondary zone periodically queries its master server to synchronize its
zone data.