Domain Name Service (DNS)
By Thomas Lee and Joseph Davies
Chapter 16 from Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference, published by Microsoft Press
For the Windows Server 2003 version of this book, see Microsoft® Windows® Server 2003 TCP/IP Protocols and Services Technical Reference.
Every host that runs TCP/IP must have a unique IP address that's used when communicating with other computers in a network. Computers operate easily with IP addresses, but people don't; users would rather identify systems by a name. To facilitate effective and efficient communication, users need to be able to refer to computers by name, and still have their computer use IP addresses transparently.
In the early days of the ARPANET, the forerunner to today's Internet, there were only a small number of computers attached to the network. The Network Information Center (NIC), located at Stanford Research Institute (SRI), was responsible for compiling a single file, HOSTS.TXT, which contained the names and addresses of every computer. Administrators would email SRI, which would then update the HOSTS.TXT file. Next, ARPANET users would download the new version of HOSTS.TXT using File Transfer Protocol (FTP).
As the ARPANET grew, it became obvious that this approach wouldn't scale, for the following three key reasons:
The bandwidth consumed in transmitting updated versions of an ARPANET-wide host file was proportional to the square of the number of hosts in the ARPANET. With the number of hosts growing at an exponential rate, the long-term impact was likely to be a load that no one host was going to be able to sustain.
The static flat host file also meant that no two computers on the ARPANET could have the same name. As the number of hosts grew, the risk of adding a duplicate name grew, as did the difficulty of trying to control this centrally.
The nature of the underlying network was changing—the large, timesharing computers that had once made up the ARPANET were being superseded by networks of workstation—seach of which needed to have a unique host name. This would be difficult, if not impossible, to control centrally.
As the ARPANET continued to grow, it became clear that ARPANET needed a better solution. Several proposals were generated based on the concept of a distributed naming service, which was based on a hierarchical name space. RFCs 882 and 883 emerged, which described the design for a domain name system, based on a distributed database containing generalized resource information. This design evolved, and RFCs 1034 and 1035 were issued to describe the Domain Name System (DNS) service used in today's Internet. This design continues to evolve, and a number of proposed updates and refinements are being discussed as this chapter is being written.
On This Page
.gif){kind=icon}
Chapter Contents
Overview to DNS in Microsoft Windows 2000
How DNS Works
DNS Resource Records
DNS Messages
Summary
Chapter Contents
This chapter describes Microsoft Windows 2000's implementation of the DNS protocol. Additionally, there are Network Monitor traces on the companion CD-ROM that demonstrate the DNS protocol in operation.
This chapter contains the following sections:
Overview to DNS in Windows 2000 A description of the DNS protocol as implemented in Windows 2000
How DNS Works A description of how DNS works, illustrated by various Network Monitor traces
DNS Messages Describes the format of the messages sent between DNS clients and DNS servers, and the functions provided
Server-Server DNS Messages Describes the format of messages sent between DNS servers
This chapter doesn't discuss the administration of a DNS system, however. The care and feeding of a DNS service could, and does, fill complete books, and we won't duplicate that effort here. See the bibliography for details of recommended books covering DNS administration considerations.
Overview to DNS in Microsoft Windows 2000
To facilitate communications between computers, computers can be given names within a name space. The specific name space defines the rules for naming a computer, and for how names are resolved into IP addresses. When one computer communicates with other computers, it must resolve, or convert, a computer name into an IP address based on the rules of the name space being used. This resolution will be done by a name-resolution service.
There are two main name spaces, and name-resolution methods, used within Windows 2000: NetBIOS, implemented by Windows Internet Naming Service (WINS) (described in Chapter 17), and the DNS, described in this chapter. Windows 2000 also provides support for other name spaces, such as Novell Netware and Banyan Vines, although discussion of these is outside the scope of this book.
In this section, we'll describe DNS and the protocol used to provide name resolution.
What Is DNS?
The DNS is an IETF-standard name service. The DNS service enables client computers on your network to register and resolve DNS domain names. These names are used to find and access resources offered by other computers on your network or other networks, such as the Internet. The following are the three main components of DNS:
Domain name space and associated resource records (RRs) A distributed database of name-related information.
DNS Name Servers Servers that hold the domain name space and RRs, and that answer queries from DNS clients.
DNS Resolvers The facility within a DNS client that contacts DNS name servers and issues name queries to obtain resource record information.
Key DNS Terms
This section describes the key components of the DNS and defines key DNS terms.
Domain Name Space
The domain name space is a hierarchical, tree-structured name space, starting at an unnamed root used for all DNS operations. In the DNS name space, each node and leaf in the domain name space tree represents a named domain. Each domain can have additional child domains. Figure 16-1 illustrates the structure of Internet domain name space.
.gif)
Figure 16-1: Domain name space for the Internet.
See full-sized image.
Domain Names
Each node in the DNS tree, as Figure 16-1 illustrates, has a separate name, referred to in RFC 1034 as a label. Each DNS label can be from 1 through 63 characters in length, with the root domain having a length of zero characters.
A specific node's domain name is the list of the labels in the path from the node being named to the DNS Tree root. DNS convention is that the labels that compose a domain name are read left to right—from the most specific to the root (for example, www.kapoho.com). This full name is also known as the fully qualified domain name (FQDN).
Domain names can be stored as upper case or lower case, but all domain comparisons and domain functions are defined, by RFC 1034, to be case insensitive. Thus, www.kapoho.com is identical to WWW.KAPOHO.COM for domain naming operations.
Top-Level Domains
A top-level domain is a DNS domain directly below the root. As Figure 16-1 illustrates, a number of top-level domains have been defined. Additional names (at least for the Internet) are difficult to create. The following are the three categories of top-level domains:
"ARPA" This is a special domain—used today for reverse-name lookups.
3-letter domains There are six 3-character, top-level domains noted below.
2-letter country-based domain names These country code domains are based on the International Organization for Standardization (ISO) country name, and are used principally by companies and organizations outside the US. The exception is the UK, which uses .uk as the top-level domain, even though the ISO country code is GB.
Table 16-1 shows the six top-level domains in use today, as defined by RFC 1591.
Table 16-1 3-Character Top-Level Domains in Use in the Internet
3-Character Domain Name |
Use |
|---|---|
com |
Commercial organizations, such as microsoft.com for the Microsoft Corporation |
edu |
Educational institutions, now mainly four-year colleges and universities, such as cmu.edu for Carnegie Mellon University |
gov |
Agencies of the US Federal Government, such as fbi.gov for the US Federal Bureau of Investigation |
int |
Organizations established by international treaties, such as nato.int for NATO |
mil |
US military, such as af.mil for the US Air Force |
net |
Computers of network providers, organizations dedicated to the Internet, Internet Service Providers (ISPs), and so forth, such as internic.net for the Internet Network Information Center (InterNIC) |
org |
A top-level domain for groups that don't fit anywhere else, such as non-government or non-profit organizations (for example, reiki.org for information about Reiki) |
Note: While these are the only 3-letter domains available today, there is pressure to expand this number; we may well end up with more in the future.
Resource Records (RR)
A resource record is a record containing information relating to a domain that the DNS database can hold and that a DNS client can retrieve and use. For example, the host RR for a specific domain holds the IP address of that domain (host); a DNS client will use this RR to obtain the IP address for the domain.
Each DNS server contains the RRs relating to those portions of the DNS namespace for which it's authoritative (or for which it can answer queries sent by a host). When a DNS server is authoritative for a portion of the DNS name space, those systems' administrators are responsible for ensuring that the information about that DNS name space portion is correct. To increase efficiency, a given DNS server can cache the RRs relating to a domain in any part of the domain tree.
There are numerous RR types defined in RFCs 1035 and 1036, and in later RFCs. Most of the RR types are no longer needed or used, although all are fully supported by Windows 2000. Table 16-2 lists the key RRs that might be used in a Windows 2000 network. (For more detail on the contents of specific RRs, see the "DNS Resource Records" section later in this chapter.)
Table 16-2 Key Resource Records as Used by a Windows 2000 Network
Resource Record Type |
Contents |
Use |
|---|---|---|
A |
Host Address |
Used to hold a specific host's IP address. |
CNAME |
Canonical Name (alias) |
Used to make an alias name for a host. |
MX |
Mail Exchanger |
Provides message routing to a mail server, plus backup server(s) in case the target server isn't active. |
NS |
Name Server |
Provides a list of authoritative servers for a domain or indicates authoritative DNS servers for any delegated sub-domains. |
PTR |
Pointer |
Used for reverse lookup—resolving an IP address into a domain name using the IN-ADDR.ARPA domain. |
SOA |
Start of Authority |
Used to determine the DNS server that's the primary server for a DNS zone and to store other zone property information. |
SRV |
Service Locator |
Provides the ability to find the server providing a specific service. Active Directory uses SRV records to locate domain controllers, global catalog servers, and Lightweight Directory Access Protocol (LDAP) servers. |
RRs can be attached to any node in the DNS tree, although RRs won't be provided in some domains (for example, Pointer (PTR) RRs are found only in domains below the in-addr.arpa domain). Thus, higher-level domains, such as microsoft.com, can have individual RRs (for example, Mail Exchange (MX) record for mail to be sent to the Microsoft Corporation) as well as having sub-domains that also might have individual RRs (for instance, eu.microsoft.com, which has a host record www.eu.microsoft.com).
Canonical Names
The Canonical Name (CNAME) RR enables the administrator to create an alias to another domain name. The use of 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. For example, if you need to rename kona.kapoho.com to hilo.kapoho.com, you could create a CNAME entry for kona.kapoho.com to point to hilo.kapoho.com.
When a generic name for a well-known service, such as ftp or www, needs to resolve to a group of individual computers (each with an individual (A) RR). For example, you might want www.kapoho.com to be an alias for kona.kapoho.com and hilo.kapoho.com. A user will access www.kapoho.com and generally won't be aware of which computer is actually servicing this request.
DNS Query Operation
A DNS client issues a query operation against a DNS server to obtain some or all of the RR information relating to a specific domain, for instance, to determine which host (A) record or records are held for the domain named kapoho.com. If the domain exists and the requested RRs exist, the DNS server will return the requested information in a query reply message. The query reply message will return both the initial query and a reply containing the relevant records, assuming the DNS server can obtain the required RRs.
A DNS query, referred to in RFC 1034 as a standard query, contains a target domain name, a query type, and a query class. The query will contain a request for the specific RR(s) that the resolver wished to obtain (or a request to return all RRs relating to the domain).
DNS Update Operation
A DNS update operation is issued by a DNS client against a DNS server to update, add, or delete some or all of the RR information relating to a specific domain, for instance, to update the host record for the computer named kona.kapoho.com to point to 10.10.1.100. The update operation is also referred to as a dynamic update.
DNS Zones
A DNS server that has complete information for part of the DNS name space is said to be the authority for that part of the name space. This authoritative information is organized into units called zones, which are the main units of replication in DNS. A zone contains one or more RRs for one or more related DNS domains.
The following are the three DNS zone types implemented in Windows 2000:
Standard Primary Holds the master copy of a zone and can replicate it to secondary zones. All changes to a zone are made on the standard primary.
Standard Secondary Contains a read-only copy of zone information that can provide increased performance and resilience. Information in a primary zone is replicated to the secondary by use of the zone transfer mechanism.
Active Directory-integrated A Microsoft proprietary zone type, where the zone information is held in the Windows 2000 Active Directory (AD) and replicated using AD replication.
Traditionally, the master copy of each zone is held in a primary zone on a single DNS server. On that server, the zone has a Start Of Authority (SOA) record that specifies it to be the primary zone. To improve performance and redundancy, a primary zone can be automatically distributed to one or more secondary zones held on other DNS servers. When changes are made to the zone, for instance, to add an (A) record, the changes are made to the primary zone and are transferred to the secondary zone. The transfer of zone information is handled by the zone replication process, which is described later in the "Zone Transfer" section.
When a zone is first created in Windows 2000, the zone will only hold information about a single DNS domain name, for example, kapoho.com. After the zone is created, the administrator can then add RRs to the zone, or can set the domain to be dynamically updated. For example, the administrator could add (A) records (host records) for hosts in the domain, such as kona.kapoho.com. If dynamic updates are enabled for the zone, a Windows 2000 computer can then directly update the A and PTR records on the DNS server (if the DNS client is also a DHCP client, the administrator can configure a DHCP server to send the updates).
Once the administrator has created the zone, he can add additional sub-domains to the zone (for example, jh.kapoho.com). These might be added to provide DNS services to a new building that is managed separately from the parent domain. This sub-domain, which might reside in a separate zone, would have RRs added (for example, a host record for jasmine.jh.kapoho.com).
As Figure 16-2 illustrates, if other domains are added below the domain used initially to create the zone, these domains can either be part of the same zone or belong to another. For example, the sub-domain jh.kapoho.com, which is subordinate to kapoho.com, could be held in the same zone as kapoho.com, or in a separate zone. This allows the sub-domain to be managed and included as part of the original zone records, or to be delegated away to another zone created to support that sub-domain.
.gif)
Figure 16-2: Zones versus domains.
In this example, the domain kapoho.com has a sub-domain of jh.kapoho.com. Additionally, both domains contain a single host record. In this example, the domains jh.kapoho.com and kapoho.com are held in separate zones on different DNS servers. The kapoho.com zone holds one host record for kona.kapoho.com. The jh.kapoho.com domain holds the host record for the host jasmine.jh.kapoho.com.
Active Directory-Integrated Zones
A major new feature in the Windows 2000 DNS service is the ability to store DNS zones within the AD. An Active Directory-integrated zone is a primary DNS zone that's held within the AD and replicated to other AD primary zones, using AD replication (and not traditional zone transfer). Although this method of holding zones is a Microsoft proprietary approach, it can provide some useful benefits.
The main advantage of AD-integrated zones is that the zones become, in effect, multi-master, with the capability of updates being made to any DNS server. This can increase the fault tolerance of the DNS service. In addition, replication of zone information occurs using AD replication, which can be more efficient across slow links, because of the way that AD compresses replication data between sites.
Reverse-Lookup Zones
Most queries sent to a DNS server involve a search based on the DNS name of another computer as stored in an address (A) RR. This type of query expects an IP address as the resource data for the answered response. This type of query is generally referred to as a forward query. DNS also provides a reverse-lookup process, which enables a host to determine another host's name based on its IP address. For example, "What is the DNS domain name of the host at IP address 10.10.1.100?"
To allow for reverse queries, a special domain, in-addr.arpa, was defined and reserved in the Internet DNS name space. Sub-domains within the in-addr.arpa domain are named using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses. The reverse ordering of the domain name is needed because, unlike DNS names, IP addresses are read from left to right, but are interpreted in the opposite manner (that is, the left-most part is more generalized than the right-most part). For this reason, the order of IP address octets is reversed when building the in-addr.arpa domain tree; for example, the reverse-lookup zone for the subnet 192.168.100.0 is 100.168.192.in-addr.arpa.
This approach enables the administration of lower limbs of the DNS in-addr.arpa tree to be delegated to an organization when it obtains a set of IP addresses from an IP registry.
The in-addr.arpa domain tree makes use of the PTR RR. The PTR RR is used to associate the IP address to the owning domain name. This lookup should correspond to an Address RR for the host in a forward-lookup zone. The success of a PTR RR used in reverse query depends on the validity of its pointer data, the (A) RR, which must exist.
Note: The in-addr.arpa domain is used only for Internet Protocol version 4 (IPv4)-based networks. In the Windows 2000 DNS Microsoft Management Console (MMC) snap-in, the DNS server's New Zone wizard will use this domain when it creates a new reverse-lookup zone. Internet Protocol version 6 (IPv6)-based reverse-lookup zones are based on the domain ip6.arpa.
Reverse Queries
A reverse query is one in which the DNS server is requested to return the DNS domain name for a host at a particular IP address. Reverse-Lookup Query messages are, in effect, standard queries, but relating to the reverse-lookup zone. The reverse-lookup zone is based on the in-addr.arpa domain name and mainly holds PTR RRs.
Note: The creation of reverse-lookup zones and the use of PTR RRs for identifying hosts are optional parts of the DNS standard. Reverse-lookup zones aren't required in order to use Windows 2000, although some networked applications can be configured to use the reverse-lookup zones as a form of additional security.
Inverse Queries
Inverse queries originally were described in RFC 1032, but now are outdated. Inverse queries were meant to look up a host name based on its IP address and use a nonstandard DNS query operation. The use of inverse queries is limited to some of the earlier versions of NSLOOKUP.EXE, a utility used to test and troubleshoot a DNS service. The Windows 2000 DNS server recognizes and accepts inverse query messages and answers them with a "fake" inverse query response.
DNS Query Classes
DNS queries fall into one of two classes: recursive queries and iterative queries.
A recursive query is a DNS query sent to a DNS server in which the querying host asks the DNS server to provide a complete answer to the query, even if that means contacting other servers to provide the answer. When sent a recursive query, the DNS server will use separate iterative queries to other DNS servers on behalf of the querying host to obtain an answer for the query.
An iterative query is a DNS query sent to a DNS server in which the querying host requests it to return the best answer the DNS server can provide without seeking further assistance from other DNS servers.
In general, host computers issue recursive queries against DNS servers. The host assumes that the DNS server either knows the answer to the query, or can find the answer. On the other hand, a DNS server will generally issue iterative queries against other DNS servers if it is unable to answer a recursive query from cached information.
DNS Resolver
In Windows 2000, the DNS resolver is a system component that performs DNS queries against a DNS server (or servers). The Windows 2000 TCP/IP stack is usually configured with the IP address of at least one DNS server to which the resolver sends one or more queries for DNS information.
In Windows 2000, the resolver is part of the DNS Client service. This service is installed automatically when TCP/IP is installed, and runs as part of the Services.Exe process. Like most Windows 2000 services, the DNS Client service will log on using the Windows 2000 System account.
DNS Resolver Cache
An IP host might need to contact some other host on a regular basis, and therefore would need to resolve a particular DNS name many times (such as the name of the mail server). To avoid having to send queries to a DNS server each time the host wants to resolve the name, Windows 2000 hosts implement a special cache of DNS information.
The DNS Client service caches RRs from query responses that the DNS Client service receives. The information is held for a set Time-To-Live (TTL) and can be used to answer subsequent queries. By default, the cache TTL is based on the TTL value received in the DNS query response. When a query is resolved, the authoritative DNS server for the resolved domain defines the TTL for a given RR.
You can use the IPCONFIG command with the /DISPLAYDNS option to display the current resolver cache contents. The output looks like the following:
D:\2031AS>ipconfig /displaydns
Windows 2000 IP Configuration
localhost.
-------------------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 31523374
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1
kona.kapoho.com.
-------------------------------------------------
Record Name . . . . . : KONA.kapoho.com
Record Type . . . . . : 1
Time To Live . . . . : 2407
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 195.152.236.200
1.0.0.127.in-addr.arpa.
-------------------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa
Record Type . . . . . : 12
Time To Live . . . . : 31523373
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : localhost
Negative Caching
The DNS Client service further provides negative caching support. Negative caching occurs when an RR for a queried domain name doesn't exist or when the domain name itself doesn't exist, in which case, the lack of resolution is stored. Negative caching prevents the repetition of additional queries for RRs or domains that don't exist.
If a query is made to a DNS server and the response is negative, subsequent queries for the same domain name are answered negatively for a default time of 300 seconds. To avoid the continued negative caching of stale information, any query information negatively cached is held for a shorter period than is used for positive query responses. However, this negative caching time-out value can be changed in the registry using the following NegativeCacheTime registry value:
NegativeCacheTime
Location: HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\Dnscache\Parameters Data type: REG_DWORD—Time, in seconds Default value: 0x12c (300 decimal, or 5 minutes) Valid range: 00xFFFFFFFF (the suggested value is less one day, to prevent very stale records) Present by default: Yes
Negative caching reduces the load on DNS servers, but should the relevant RRs become available, later queries can be issued to obtain the information.
If all DNS servers are queried and none is available, for a default of 30 seconds, succeeding name queries will fail instantly, instead of timing out. This can save time for services that query the DNS during the boot process, especially when the client is booted from the network.
Zone Transfer
To improve the resilience and performance of the DNS service, it's normal to have at least one standard secondary zone for each standard primary zone, where the secondary zone is held on another DNS server. Depending on the exact nature of the organization, multiple standard secondary zones might be appropriate. When changes are made to the primary zone, it's important that the zone information is promptly replicated to all secondary zones. The process of transferring zone information from a primary to a secondary zone is called a zone transfer.
Zone transfers usually occur automatically, in intervals defined in the zone's SOA record. Zone transfers can also be performed manually by using the DNS MMC Snap-in, which might be done if the administrator suspects the secondary zone hasn't been properly updated.
When a standard secondary zone is created on a Windows 2000 DNS server, the DNS server will transfer all RRs from the standard primary zone to the new standard secondary. The DNS server does this to obtain and replicate a full copy of all RRs for the zone. In many of the early DNS server implementations, this same method of full transfer for a zone is used also when the secondary zone requires updating to align it with the primary zone, after changes are made to the primary zone. For large zones, this can be very time-consuming and wasteful of network resources. This can be an issue because a zone transfer will be needed each time the primary zone is updated, such as when a new host is added to the domain or if the IP address for a host is changed.
After the RRs have been replicated, the server on which the new standard secondary zone resides will check with the server on which the primary zone resides at regular intervals to determine if there are any changes to the primary zone. This is determined by polling the primary zone on a regular basis, the time period being defined by the Administrator in the Zone SOA record in the standard primary zone, and checking if the zone's version number has changed. If the version number has been incremented, a zone transfer is necessary. This process is shown in the following Network Monitor trace (Capture 16-01, included in the \Captures folder on the companion CD-ROM):
1 563.890835 Router Mahimahi DNS 0x6000:Std Qry for kapoho.com. of type SOA on class INET addr. 10.10.2.200 10.10.1.200 2 563.890835 Mahimahi Router DNS 0x6000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr. 10.10.1.200 10.10.2.200 3 563.890835 Router Mahimahi DNS 0x4000:Std Qry for kapoho.com. of type Req for incrmntl zn Xfer on class INET 10.10.2.200 10.10.1.200 4 563.890835 MahiMahi Router DNS 0x4000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr. 10.10.1.200 10.10.2.200
In this trace, the DNS server holding the secondary zone queries the primary zone. The SOA is then returned. The secondary zone discovers a higher version number on the primary DNS server and requests a zone transfer.
For manually maintained DNS servers, this traditionally has been a key troubleshooting issue—changes are made to a primary zone, but the version number is unchanged, and thus the changes are not replicated to the secondary. With Windows 2000, changes made to the zone, either via manual update using the DNS MMC Snap-in or via dynamic registration, trigger an update to the version number, thus enabling the secondary to carry out the zone transfer at the next poll interval.
Incremental Zone Transfers
For large zones, zone transfers can consume a significant amount of bandwidth, especially when a zone transfer is carried across slow WAN links. To improve the efficiency of zone transfers, Windows 2000 implements a new method of replicating DNS zones, incremental zone transfer, which involves transferring only the changes to the zone, rather than the entire zone. This can significantly reduce the traffic needed to keep a secondary zone current. Incremental zone transfer is defined in RFC 1995.
With incremental zone transfers, the differences between the source and replicated versions of the zone are first determined. If the zones are identified as the same version—as indicated by the serial number field in the SOA RR 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 zone version. For an incremental zone-transfer query to succeed and changes to be sent, the zone's source DNS server must keep a history of incremental zone changes to use when answering these queries. Windows 2000 holds the incremental zone transfer information for each zone in a text file \Winnt\system32\dns folder whose name is based on the name of the file holding the the zone data (which was specified when the zone was defined). Thus, if the zone information for the kapoho.com zone is held in the file kapoho.com.dns, the incremental update log is held in kapoho.com.dns.log.
Directory-Integrated Zone Replication
Standard zones use the traditional zone replication mechanisms to transfer zone information. Active Directory-integrated zones, however, use AD replication to replicate updates. This provides the following three key benefits:
DNS servers become multi-master. With standard DNS zones, all updates need to be made to a single DNS server—in other words, to the server containing the primary zone. With AD integration, any DNS server can accept the updates, which provide both improved performance and scaling, as well as better fault tolerance.
AD replication is both more efficient and quicker. AD replication transfers updated-only properties, and not the entire zone, which means only the changes are transmitted across the network. Additionally, replication between sites, typically involving slower links, is highly compressed.
The administrator only needs to plan and implement a single replication topology for AD. This will also replicate DNS changes.
For organizations using AD, Active Directory-integrated zones are generally recommended. If the organization is, however, using third-party DNS servers, these servers probably won't support AD-integrated zones.
Zone Delegation
DNS is a distributed database of information designed specifically to overcome the limitations of the earlier HOSTS.TXT approach to name resolution. The key to scaling DNS to handle large name spaces/networks, such as the Internet, is the ability to delegate the administration of domains. A zone delegation occurs when the responsibility of the RRs of a sub-domain is passed from the owner of the parent domain to the owner of the sub-domain.
At the heart of the Internet are 13 root servers, named A.ROOT-SERVERS.NET through M.ROOT-SERVERS.NET. The root servers are widely distributed. The root servers hold data for all the top-level domains, such as .com, .org, and .net, as well as for geographical domains, such as .uk, and .jp. These root-name servers enable Internet hosts to have access to the complete DNS database. Below the root and top-level domains are the domains and sub-domains belonging to individual organizations. In some top-level domains, additional hierarchy levels are provided. For example, in the .uk domain, there are sub-domains co.uk for UK-based companies (for instance, psp.co.uk) and ac.uk for academic institutions (for instance, ic.ac.uk for Imperial College), and so forth.
As illustrated in Figure 16-2, delegation occurs as a cut in the DNS with responsibility for the domain below the cut to be delegated from the domain above the cut. Within the kapoho.com domain is a sub-domain jh.kapoho.com. Responsibility for the subordinate domain has been delegated to a different server.
To implement a delegation, the parent zone must have both an A RR and a Name Service (NS) record—both pointing to the new delegated domain's root. In the kapoho.com zone, illustrated in Figure 16-2, there must be an A and an NS record that point to jh.kapoho.com. The Windows 2000 server has a delegation wizard to simplify the task of implementing a delegation.
Forwarder and Slave DNS Servers
If a resolver contacts a DNS server to resolve a domain name and return relevant RRs, the contacted DNS server will first attempt to perform the lookup using its own cache. If this fails, by default the DNS server will then start to issue iterative queries to resolve the domain. This will start at the root. If the DNS server is one of several at a site connected to the outside world by slow links, this default behavior might not be desirable.
As illustrated by Figure 16-3, a forwarder is a DNS server that other DNS servers contact before attempting to perform the necessary name resolution.
In this example, when any of the DNS clients send recursive queries to DNS servers A, B, and C, they'll attempt to answer the query from locally held zones or from their local cache. If this isn't successful, instead of these servers issuing iterative queries to external DNS servers, they'll send a recursive query to DNS server D, which has a better chance of answering the query from its own cache. This arrangement will reduce the external traffic needed to resolve host queries.
If the forwarder (server D in the example) is unable to answer the queries sent by DNS Servers A, B, or C, these servers will attempt to resolve the queries themselves by issuing iterative queries, which, again, might not be desirable. A Slave server is a forwarder that will only forward queries. This forces the DNS server to use only its configured forwarders for all name-resolution activities.
.gif)
Figure 16-3: DNS forwarder.
See full-sized image.
Round Robin Load Balancing
Round robin is an approach for performing load balancing. It's used to share and distribute the network resource load. With round robin, the answers contained in a query, for which multiple RRs exist, are rotated each time the query is answered. Round robin is a very simple method for load balancing a client's use of Web servers and other frequently queried multi-homed computers.
For round robin to work, multiple address (A) RRs for the queried name must exist in the zone being queried. For example, suppose there were three physical Web servers servicing www.kapoho.com, with the IP addresses of 10.1.1.151, 10.1.152, and 10.1.1.153. To invoke round robin, the administrator would need to define three (A) records for www.kapoho.com (pointing to the different servers). The first query for this domain would be returned in the order 10.1.1.151, 10.1.1.152, and 10.1.1.153. The following query would return 10.1.1.152, 10.1.1.153, and 10.1.1.151, and so on. Because the client usually will take the first IP address, the first query would use the IP address 10.1.1.151, while the second would use 10.1.1.152.
Dynamic Update DNS Client
For large networks, getting all the necessary RR information into the DNS and keeping it current can be a significant task. Maintenance of host records can be a full-time job for one or more people, in some environments. To simplify the task, Windows 2000 includes support for dynamic updates to DNS, as described in RFC 2136.
With Dynamic DNS, the client sends a DNS registration message to the DNS server, instructing the server to update the (A) record for the dynamic update host. Additionally, if the client is also a DHCP client, every time there's an address event (for instance, a new address or address renewal), as part of the DHCP lease-management process, the DHCP client sends DHCP Option 81 to the DHCP server along with its fully qualified name. Option 81 instructs the DHCP server to register a PTR RR on its behalf. Windows 2000 computers that are statically configured will register both the (A) RR and the PTR RR with the DNS server themselves.
If a Windows 2000 DHCP client talks to a lower-level DHCP server that doesn't handle Option 81, the client registers a PTR RR on its own. The Windows 2000 DNS server is capable of handling dynamic updates.
This approach (client updating the (A) record, DHCP server updating the PTR record) is taken because only the client knows which IP addresses on the host map to a given host name. The DHCP server might not be able to properly do the (A) RR registration because it has incomplete knowledge. If appropriate, the DHCP server also can be configured to register both records with the DNS.
IPv6 Support
IP version 6 (IPv6) is a new version of the Internet Protocol. Although Windows 2000 won't ship with a native IPv6 TCP/IP stack, the Windows 2000 DNS server does provide support for IPv6 by implementing several additional pieces of functionality, including the following:
AAAA RR This new record type is defined to store a host's IPv6 address. A multi-homed IPv6 host, for example, a host that has more than one IPv6 address, must have more than one AAAA record. The AAAA RR is similar to the (A) resource, using the larger IP address size. The 128-bit IPv6 address is encoded in the data portion of an AAAA RR in network byte order (high-order byte first).
AAAA query An AAAA query for a specified domain name in the Internet class returns all associated AAAA RRs in the answer section of a response. A type AAAA query doesn't perform additional section processing.
IP6.ARPA domain This domain is used to provide reverse-lookup faculties for IPv6 hosts (as the in-addr.arpa domain does for IPv4 addresses).
Similar to in-addr.arpa domain for IPv4, an IPv6 address is represented as a name in the IP6.ARPA domain by a sequence of nibbles separated by dots with the suffix ".IP6.ARPA." The sequence of nibbles is encoded in reverse order; for instance, the low-order nibble is encoded first, with the highest-order nibble last. Each nibble is represented by a hexadecimal digit. For example, the inverse-lookup domain name corresponding to the address 4321:0:1:2:3:4:567:89a:b would be b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.- 0.0.1.2.3.4.IP6.ARPA.
Finally, to support IPv6, all existing DNS query types that perform type A additional section processing, such as NS or mail exchange (MX) query types, must support both A and AAAA records and must do any processing associated with both of these record types. This means the DNS server will add any relevant IPv4 addresses and any relevant IPv6 addresses available locally to the additional section of a response when processing any one of these queries.
How DNS Works
Configuring DNS Client Functions
With Windows 2000, there's generally very little configuration to do for a client, with respect to DNS. Generally, it's only necessary to configure the host with the IP address of a primary (and a secondary) DNS server. This can be simplified by using DHCP to assign the IP address of the DNS server(s).
Usually, DNS default client behavior is adequate. However, in certain cases, some change to the default behavior might be appropriate. The registry keys described below can be used to change how the Windows 2000 DNS client works.
Specifying a Default TTL
By default, the TTL for the (A) and PTR RR updates sent by a DNS client is 20 minutes. To increase it, you can configure the following registry value:
DefaultRegistrationTTL
Key: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters Value type: REG_DWORD—seconds Default: 0x4B0 (1200 decimal, or 20 minutes) Valid range: 00xffffffff Present by default: No
Disabling Dynamic Updates
While the automatic updating of DNS zones by a host can be useful, in some environments this might not be desirable. The following registry key can disable dynamic DNS updates either for a Windows 2000 computer as a whole, or for just one interface on that computer.
DisableDynamicUpdate
Key: KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Tcpip\Parameters Or HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services Tcpip\Parameters\Interfaces\<interface> Value type: REG_DWORD—Boolean Valid range: 0, 1 (False, True) Default: 0 (False; dynamic DNS enabled) Present by default: No
Resolving Names
DNS name resolution occurs when a resolver, operating at a host, sends a DNS server a query message containing a domain name. The query message instructs the DNS to find the name and return certain RRs. The query message contains the domain name to search for, plus a code indicating the records that should be returned.
The following Network Monitor Trace (Capture 16-01, included in the \Captures folder on the companion CD-ROM) shows the process of issuing and resolving a name query.
1 4.866998 LOCAL 3COM 884403 DNS 0x1587:Std Qry for kona.kapoho.com. of type Host TALLGUY 10.10.2.200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xEEA8; Proto = UDP; Len: 61 + UDP: Src Port: Unknown, (4715); Dst Port: DNS (53); Length = 41 (0x29) DNS: 0x1587:Std Qry for kona.kapoho.com. of type Host Addr on class INET addr. DNS: Query Identifier = 5511 (0x1587) + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: kona.kapoho.com. of type Host Addr on class INET addr. DNS: Question Name: kona.kapoho.com. DNS: Question Type = Host Address DNS: Question Class = Internet address class 2 4.866998 3COM 884403 LOCAL DNS 0x1587:Std Qry Resp. for kona.kapoho.com. of type 10.10.2.200 TALLGUY IP + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x7BAA; Proto = UDP; Len: 77 + UDP: Src Port: DNS, (53); Dst Port: Unknown (4715); Length = 57 (0x39) DNS: 0x1587:Std Qry Resp. for kona.kapoho.com. of type Host Addr on class INET addr. DNS: Query Identifier = 5511 (0x1587) + DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: kona.kapoho.com. of type Host Addr on class INET addr. DNS: Question Name: kona.kapoho.com. DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: kona.kapoho.com. of type Host Addr on class INET addr. DNS: Resource Name: kona.kapoho.com. DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 1200 (0x4B0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 10.10.2.200
In the trace shown above, a client sends a DNS query to request the DNS server to return all A records for kona.kapoho.com. The query response contains the question entry and the answer RR(s). In this case, there's only one A record to return pointing to 10.10.2.200.
Network Monitor trace 16-2 (Capture 16-02, included in the \Captures folder on the companion CD-ROM) shows a Reverse-Lookup Query message. In this trace, the querying host tries to discover the host name for the host at 10.10.1.52. To determine this, the resolver queries for 52.1.10.10.in-addr.arpa and requests any PTR records. The DNS has the relevant PTR record, which shows the host to be kapoholt.kapoho.com.
Resolving Aliases
If the resolver is attempting to perform name resolution on a name that a user provided, it won't know in advance whether the name relates to a Host (A) RR or to a CNAME. If it relates to the CNAME, the server can return the CNAME. However, in this instance, the CNAME must still be resolved. To avoid extra DNS traffic, when a DNS server returns a CNAME in response to a Host record lookup, the DNS server will also return the A record relating to the CNAME.
The following Network Monitor Trace (Capture 16-03, included in the \Captures folder on the companion CD-ROM) shows the process of issuing and resolving a canonical name.
1 6.559432 DNS Server DNS Client DNS 0x1590:Std Qry for ns1.kapoho.com. of type Host A TALLGUY 10.10.2.200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xEFCD; Proto = UDP; Len: 60 + UDP: Src Port: Unknown, (4761); Dst Port: DNS (53); Length = 40 (0x28) DNS: 0x1590:Std Qry for ns1.kapoho.com. of type Host Addr on class INET addr. DNS: Query Identifier = 5520 (0x1590) + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: ns1.kapoho.com. of type Host Addr on class INET addr. DNS: Question Name: ns1.kapoho.com. DNS: Question Type = Host Address DNS: Question Class = Internet address class 2 6.569446 DNS Client DNS Server DNS 0x1590:Std Qry Resp. for ns1.kapoho.com. of type 10.10.2.200 TALLGUY IP + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x807B; Proto = UDP; Len: 95 + UDP: Src Port: DNS, (53); Dst Port: Unknown (4761); Length = 75 (0x4B) DNS: 0x1590:Std Qry Resp. for ns1.kapoho.com. of type Canonical name on class INET addr. DNS: Query Identifier = 5520 (0x1590) + DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 2 (0x2) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: ns1.kapoho.com. of type Host Addr on class INET addr. DNS: Question Name: ns1.kapoho.com. DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: ns1.kapoho.com. of type Canonical name on class INET addr.(2 records present) + DNS: Resource Record: ns1.kapoho.com. of type Canonical name on class INET addr. + DNS: Resource Record: kona.kapoho.com. of type Host Addr on class INET addr.
In this trace, the DNS client sends a DNS query to the DNS server requesting the Host record for ns1.kapoho.com, which is actually an alias for kona.kapoho.com. In the DNS reply, there are two answer RRs. The first is the CNAME RR for ns1.kapoho.com, and contains the canonical name. The second answer RR is the Host record for kona.kapoho.com, which will contain the IP address of this computer.
Dynamically Updating DNS
Dynamic updating of DNS zones, described in RFC 2136, is a mechanism that enables DNS clients to add or delete RRs or sets of RRs (RRSets) to a zone. In addition, update requests can state prerequisites (specified separately from update operations), which can be tested before an update can occur. Such updates are said to be atomic, that is, all prerequisites must be satisfied for the update operation to be carried out. The Windows 2000 TCP/IP client and the DHCP server issue dynamic update requests to update the DNS with host A and PTR records.
More Info Dynamic updating of DNS zones is described in RFC 2136, which can be found in the \RFC folder on the companion CD-ROM.
The following Network Monitor Trace (Capture 16-04, included in the \Captures folder on the companion CD-ROM) shows the process of dynamically registering an (A) RR.
1 6.270000 DNS Client DNS Server DNS 0x61:Dyn Upd PRE/UPD records to KAPOHOLT.kapoho.c 10.10.1.52 195.152.236.200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x1082; Proto = UDP; Len: 115 + UDP: Src Port: Unknown, (3276); Dst Port: DNS (53); Length = 95 (0x5F) DNS: 0x61:Dyn Upd PRE/UPD records to KAPOHOLT.kapoho.com. of type Canonical name DNS: Query Identifier = 97 (0x61) + DNS: DNS Flags = Query, OpCode - Dyn Upd, RCode - No error DNS: Zone Count = 1 (0x1) DNS: Prerequisite Section Entry Count = 2 (0x2) DNS: Update Section Entry Count = 1 (0x1) DNS: Additional Records Count = 0 (0x0) + DNS: Update Zone: kapoho.com. of type SOA on class INET addr. + DNS: Prerequisite: KAPOHOLT.kapoho.com. of type Canonical name on class Unknown Class(2 records present) DNS: Update: KAPOHOLT.kapoho.com. of type Host Addr on class INET addr. DNS: Resource Name: KAPOHOLT.kapoho.com. DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 1200 (0x4B0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 10.10.1.52 2 6.270000 DNS Server DNS Client DNS 0x61:Dyn Upd Resp. PRE/UPD records to KAPOHOLT.ka 195.152.236.200 10.10.1.52 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x86BD; Proto = UDP; Len: 115 + UDP: Src Port: DNS, (53); Dst Port: Unknown (3276); Length = 95 (0x5F) DNS: 0x61:Dyn Upd Resp. PRE/UPD records to KAPOHOLT.kapoho.com. of type Canonical name DNS: Query Identifier = 97 (0x61) + DNS: DNS Flags = Response, OpCode - Dyn Upd, RCode - No error DNS: Zone Count = 1 (0x1) DNS: Prerequisite Section Entry Count = 2 (0x2) DNS: Update Section Entry Count = 1 (0x1) DNS: Additional Records Count = 0 (0x0) + DNS: Update Zone: kapoho.com. of type SOA on class INET addr. + DNS: Prerequisite: KAPOHOLT.kapoho.com. of type Canonical name on class Unknown Class(2 records present) DNS: Update: KAPOHOLT.kapoho.com. of type Host Addr on class INET addr. DNS: Resource Name: KAPOHOLT.kapoho.com. DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 1200 (0x4B0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 10.10.1.52
In this trace, the dynamic update message is sent from the DNS client to the DNS server to update the (A) RR for the host kapoholt.kapoho.com, which is now at IP address 10.10.1.52.
Transferring Zone Information
There are three methods of performing zone transfer:
Traditional Zone Transfer This approach involves the secondary requesting a full copy of the zone from the primary.
Incremental Zone Transfer This approach, as defined in RFC 1995, requires the DNS server hosting the primary zone to keep a record of the changes that are made between each increment of the zone's sequence number. The secondary can thus request only the changes that occurred since the last time the secondary was updated.
AD Zone Transfer AD zones are replicated to all domain controllers in the Windows 2000 domain using AD replication.
More Info The Incremental Zone Transfer approach is defined in RFC 1995, and the traditional zone-transfer mechanism is defined in RFC 1034. These RFCs can be found in the \RFC folder on the companion CD-ROM.
The traditional zone-transfer mechanism, which RFC 1034 defines, can be wasteful of network resources if the change in the transferred RRs is small in relation to the overall zone. The following Network Monitor Trace (Capture 16-05, included in the \Captures folder on the companion CD-ROM) shows a zone transfer.
1 60.1765 Secondary Primary TCP ....S., len: 0, seq:3436924871-3436924871, ack
2 60.1765 Primary Secondary TCP .A..S., len: 0, seq:2396712099-2396712099, ack
3 60.1765 Secondary Primary TCP .A...., len: 0, seq:3436924872-3436924872, ack
4 60.1765 Secondary Primary DNS 0x0:Std Qry for kapoho.com. of type Req for
zn Xfer on
class INET addr.
5 60.1865 Primary Secondary DNS 0x0:Std Qry Resp. for kapoho.com. of
type SOA on class
INET addr.
6 60.1865 Primary Secondary DNS 0x636F:Rsrvd for _ of type Unknown Type on class
7 60.1865 Secondary Primary TCP .A...., len: 0, seq:3436924904-3436924904, ack
8 60.2366 Secondary Primary TCP .A...F, len: 0, seq:3436924904-3436924904, ack
9 60.2366 Primary Secondary TCP .A...., len: 0, seq:2396714217-2396714217, ack
10 60.2366 Primary Secondary TCP .A...F, len: 0, seq:2396714217-2396714217, ack
This Network Monitor trace 16-5 shows a zone transfer of the zone kapoho.com from the primary to a secondary server. In this trace, the secondary DNS server first initiates a TCP connection with the primary server and issues a zone-transfer message. The primary zone's DNS server then transfers the zone RRs. In a zone-transfer, the first and last record transferred is the SOA record. After all the records are transferred, the TCP connection is terminated.
Incremental zone transfers, described in RFC 1995, can be more efficient than traditional zone transfers for both large and dynamic zones. However, they place additional processing requirements on the DNS server, which needs to keep track of the zone differences and sends only the changed records. By default, standard zones will use incremental transfers where possible.
The following Network Monitor trace 16-6 (Capture 16-06, included in the \Captures folder on the companion CD-ROM) shows an incremental zone transfer.
1 563.890835 LOCAL 3COM 6B15C7 DNS 0x6000:Std Qry for kapoho.com. of type SOA on class INET addr. 2 563.890835 3COM 6B15C7 LOCAL DNS 0x6000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr. 3 563.890835 LOCAL 3COM 6B15C7 DNS 0x4000:Std Qry for kapoho.com. of type Req for incrmntl zn Xfer on class INET addr. 4 563.890835 3COM 6B15C7 LOCAL DNS 0x4000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr.
In this trace, the DNS server initiating the zone transfer first queries for the SOA record, then requests an incremental zone transfer. In this example, the reply, contained in the fourth packet, fully fits inside a single UDP datagram. Had this not been the case, the reply message would have indicated that the reply was truncated, and the requesting server would have created a TCP session to the other DNS server and requested the zone transfer via TCP.
Active Directory replication is a proprietary solution, which can be used only with Windows 2000 domain controllers. Standard and incremental zone transfers rely on the servers holding secondary zones to pull changes from the primary zone. AD replication, on the other hand, is push in nature. For zones that change little, AD replication will ensure that all DNS servers holding the zone are updated quickly, while for more dynamic zones, will tend to smooth the replication traffic. Active Directory replication is beyond the scope of this book.
DNS Resource Records
What Are Resource Records?
An RR is information related to a DNS domain; for example, the host record defining a host IP address. Each RR will contain a common set of information, as follows:
Owner Indicates the DNS domain in which the resource record is found.
TTL The length of time used by other DNS servers to determine how long to cache information for a record before discarding it. For most RRs, this field is optional. The TTL value is measured in seconds, with a TTL value of 0 indicating that the RR contains volatile data that's not to be cached. As an example, SOA records have a default TTL of 1 hour. This prevents these records from being cached by other DNS servers for a longer period, which would delay the propagation of changes.
Class For most RRs, this field is optional. Where it's used, it contains standard mnemonic text indicating the class of an RR. For example, a class setting of IN indicates the record belongs to the Internet (IN) class. At one time there were multiple classes (such as CH for Chaos Net), but today, only the IN class is used.
Type This required field holds a standard mnemonic text indicating the type for an RR. For example, a mnemonic of A indicates that the RR stores host address information.
Record-Specific Data This is a variable-length field containing information describing the resource. This information's format varies according to the type and class of the RR.
Note: With Windows 2000, nearly all of the DNS information is either automatically added to the server or can be left to a default value. For most organizations running Windows 2000, DNS will be self-maintaining once the DNS servers are installed and the relevant zones created. However, the details on RR types can be useful for those integrating Windows 2000 with a non-Windows 2000 DNS server, or for troubleshooting.
Standard DNS zone files contain the set of RRs for that zone as a text file. In this text file, each RR is on a separate line and contains all the above data items, as a set of text fields, separated by white space. In the zone file, each RR consists of the above data items, although different records will contain slightly differently formatted record-specific data.
Sample Zone Data
The zone data for the kapoho.com zone noted earlier in this chapter is as follows:
; Database file kapoho.com.dns for kapoho.com zone.
; Zone version: 22508
;
@ IN SOA kona.kapoho.com. administrator.kapoho.com. (
22508 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
; There are two DNS servers holding this domain
@ NS kona.kapoho.com.
@ NS kapoholt.kapoho.com.
;
; Zone records for Kapoho.com
;
@ 600 A 10.10.1.52
@ 600 A 10.10.2.200
@ 600 A 10.10.2.211
hilo 900 A 10.10.2.211
kapoholt A 10.10.1.52
kona A 10.10.2.200
tallguy 1200 A 10.10.1.100
1200 A 10.10.2.100
;
; Delegated sub-zone: jh.kapoho.com.
;
jh NS kapoholt.kapoho.com.
; End delegation
Zone data for AD-integrated zones are held as a series of AD objects representing this data. For more detail on how the AD holds DNS-integrated zones, see the Windows 2000 Server Help.
Where Are RRs Located?
RRs for standard zones are stored in the folder systemroot\system32\dns. The RRs for each zone are held in a separate text file, which is named after the zone with an extension of .dns; for example, kapoho.com.dns.
Active Directory-Integrated Zone RRs
RRs for AD-integrated DNS zones are stored within the AD itself. The AD uses the following two main object classes to hold this DNS information:
dnsZone Represents an AD-integrated zone that contains dnsNode objects. This object class is the AD equivalent of a Standard zone held as a text file. The dnsZone objects have a dnsProperty attribute that defines key details about the zone, such as whether this zone can be dynamically updated.
dnsNode Corresponds to the individual RRs in the zone. Each dnsNode object will have a dnsRecord attribute containing the resource information.
Resource Records Supported by Windows 2000
Windows 2000 supports all RFC-compliant RRs. Many of these aren't commonly, or ever, used. The following sections list the most commonly used RRs and contain tables that include the RR type, the syntax, and an example.
Host Address (A)
This RR contains a host address RR that maps a DNS domain name to an IPv4 32-bit address.
Type |
A |
|---|---|
Syntax |
Owner A IPv4_address |
Example |
kona A 10.10.2.200 |
IPv6 Host Record (AAAA)
This RR contains a host address RR that maps a DNS domain name to an IPv6 128-bit address.
Type |
AAAA |
|---|---|
Syntax |
Owner Class IPv6_address |
Example |
ipv6host AAAA 4321:0:1:2:3:4:567:89a:b |
Canonical Name (CNAME)
This RR maps an alias or alternate DNS domain name in the Owner field to a canonical or actual DNS domain name. There must also be an (A) RR for the canonical DNS domain name, which must resolve to a valid DNS domain name in the name space. The fully qualified canonical name should end with a full stop (".").
Type |
CNAME |
|---|---|
Syntax |
Alias_name CNAME Canonical_name |
Example |
ns1 CNAME kona.kapoho.com |
Mail Exchanger (MX)
The MX record provides message routing to a mail-exchanger host for any mail that's to be sent to the target domain. This RR also contains a 2-digit preference value to indicate the preferred ordering of hosts, if multiple exchanger hosts are specified. Each exchanger host specified in an MX record must have a corresponding host A address RR in the current zone.
Type |
MX |
|---|---|
Syntax |
Owner MX preference mail_exchanger_host_name |
Example |
kapoho MX 10 mail.kapoho.com |
Pointer (PTR)
This RR, used for Reverse Name Lookup message, points from the IP address in the Owner field to another location in the DNS name space as specified by the target_domain_name. Usually, this is used only in the in-addr.arpa domain tree to provide reverse lookups of address-to-name mappings. In most cases, each record provides information that points to another DNS domain-name location, such as a corresponding host (A) address RR in a forward-lookup zone:
Type |
PTR |
|---|---|
Syntax |
Owner PTR target_domain_name |
Example |
200 PTR kona.kapoho.com |
Service Locator (SRV)
The SRV RR enables a computer to locate a host providing specific service, such as a Windows 2000 Active Directory Domain Controller. This enables the administrator to have multiple servers, each providing a similar TCP/IP-based service to be located using a single DNS query operation. This record is mainly used to support the Windows 2000 AD, where all relevant DNS RRs can be automatically populated into the DNS.
Type |
SRV |
|---|---|
Syntax |
service.protocol.name SRV preference-weight port target |
Example |
_ldap._tcp.dc._msdcs 600 SRV 0 100 389 kona.kapoho.com |
|
600 SRV 0 100 389 kapoholt.kapoho.com |
|
600 SRV 0 100 389 hilo.kapoho.com |
DNS Messages
DNS messages are sent between a DNS client and a DNS server or between two DNS servers. These messages are usually transmitted using User Data Protocol (UDP) with the DNS server binding to UDP port 53. In some cases, the message length, particularly for responses, might exceed the maximum size of a UDP datagram. In such cases, an initial response is sent with as much data as will fit into the UDP datagram. The DNS server will turn on a flag to indicate a truncated response. The client can then contact the server using TCP (port 53), and reissue the request—taking advantage of TCP's capability to reliably handle longer streams of data. This approach uses UDP's performance for most queries while providing a simple mechanism to handle longer queries.
DNS Messages
DNS originally provided dynamic lookup for essentially static, manually updated data, such as host records manually added to a zone. The original DNS messages involved sending a query to a DNS server and getting a response. RFC 2165 defines the dynamic update facility, which makes use of update messages, whose format is similar to and derived from query messages. Both message types are described below.
DNS Query Message Format
All DNS query messages share a common basic format, as Figure 16-4 illustrates.
.gif)
Figure 16-4: Generic DNS query message format.
See full-sized image.
As can be seen from Figure 16-4, the DNS query message consists of a fixed-length 12-byte header, plus a variable portion holding questions and DNS RRs.
DNS Query Message Header
The DNS Message header consists of the following fields:
Transaction ID A 16-bit field used to identify a specific DNS transaction. The originator creates the transaction ID and the responder copies the transaction ID into a reply message. This enables the client to match responses received from a DNS server to the requests that were sent to the server.
Flags A 16-bit field containing various service flags, described in more detail below.
Question Count A 16-bit field indicating the number of entries in the question section of a name service packet.
Answer RR Count A 16-bit field indicating the number of entries in the answer RRs section of a DNS message.
Authority RR Count A 16-bit field indicating the number of authority RRs in the DNS message.
Additional RR Count A 16-bit field indicating the number of additional RRs in the DNS message.
The Flags field contains a number of status fields that are communicated between client and server. Figure 16-5 below displays the format of the Flags field.
.gif)
Figure 16-5: DNS message Flags field.
See full-sized image.
The individual fields in the flags field are as follows:
Request/Response This 1-bit field is set to 0x0 to indicate a name-service request, and 0x1 to indicate a name-service response.
Operation Code This 4-bit field indicates the specific name-service operation of the name-service packet, as the following table shows:
Operation CodeOperation0x0Query0x1Inverse Query0x2Server Status Request
Authoritative Answer Returned in a reply to indicate whether the responder is authoritative for the domain name in the question sections.
Truncation Set to 0x1 if the total number of responses couldn't fit into the UDP datagram (for instance, if the total number exceeds 512 bytes). In this case, only the first 512 bytes of the reply are returned.
Recursion Desired Set to 0x1 to indicate a recursive query. For queries, if this bit is not set and the name server contacted isn't authoritative for the query, the DNS server will return a list of other name servers that can be contacted for the answer. This is how delegations are handled during name resolution.
Recursion Available DNS servers set this field to 0x1 to indicate that they can handle recursive queries.
Reserved These 3 bits are reserved, and set to zero.
Return Code A 4-bit field holding the return code. A value of 0x0 indicates a successful response (for instance, for name queries, this means the answer is in the reply message). A value of 0x3 indicates a name error, which is returned from an authoritative DNS server to indicate that the domain name being queried for doesn't exist.
DNS Query Question Entries
In a DNS query, the question entry contains the domain name being queried. Figure 16-6 displays the Question field layout.
.gif)
Figure 16-6: Question field layout.
See full-sized image.
The question entry is made up of the following three fields:
Question Name The domain name being queried. The format of this field is discussed later.
Question Type Indicates the records that should be returned, expressed as a 16-bit integer, as shown in the following table.
Type ValueRecord(s) Returned0x01Host record0x02Name server (A) record0x05Alias (CNAME) record0x0C (12)Reverse-lookup (PTR) record0x0F (15)Mail exchanger (MX) record0x21 (33)Service (SRV) record0xFB (251)Incremental zone transfer (IXFR) record0xFC (252)Standard zone transfer (AXFR) record0xFF (255)All records
Question Class Normally set to 0x00-01. This represents the IN question class.
The Question Name field holds the name of the domain being queried. In DNS, these domain names are expressed as a sequence of labels. The domain kapoho.com, for example, consists of two labels (kapoho and com). In the Question Name field, the domain name has a sequence for each label, as 1-byte length fields followed by the label. The domain kapoho.com, therefore, would be expressed as 0x6kapoho0x3com0x0, where the hex digits represent the length of each label, the ASCII characters represent the individual labels, and the final hex 0 indicates the end of the name.
Resource Records (RRs)
When a DNS server sends a query reply back to a DNS host, the answer, authority, and additional information sections of the DNS message can contain RRs, which answer the question in the question section. Figure 16-7 illustrates the format of these RRs.
.gif)
Figure 16-7: DNS RR format.
See full-sized image.
The fields in an RR are as follows:
RR Name The DNS domain name held as a variable-length field. The format of this field is the same as the format of the Question Name field, described in the "DNS Query Question Entries" section of this chapter.
Record Type The RR type value, as noted above.
Record Class The RR class code; there's only one record class used currently: 0x00-01, Internet Class.
TTL RR Time to live, expressed in seconds held in a 32-bit unsigned field.
Resource Data Length A 2-byte field holding the length of the resource data.
Resource Data Variable-length data corresponding to the RR type.
In DNS, domain names are expressed as a sequence of labels. The DNS name kapoho.com, for example, would consist of two labels (kapoho and com). When DNS domain names are contained in an RR, they are formatted using a length-value format. With this format, each label in a DNS message is formatted with a 1-byte-length field followed by the label. The domain kapoho.com, therefore, would be expressed as 0x06kapoho0x03com0x00, where the hex digits represent the length of each label, the ASCII characters hold the individual labels, and the final hex zero indicates the end of the name.
DNS Update Message Format
The format of a DNS Update message is very similar to DNS query messages, and many of the fields are the same. The DNS Update message contains a header defining the update operation to be performed and a set of RRs, which contain the update. Figure 16-8 displays the general format of the DNS Update message.
.gif)
Figure 16-8: General Update message flags
See full-sized image.
DNS Update Message Flags
The DNS Update message has a flag section, similar to query messages but with a slightly different format. Figure 16-9 shows the format of the Flag field section for DNS Update messages.
.gif)
Figure 16-9: DNS Update message flags.
See full-sized image.
The DNS Update message flags are used as follows:
Request/Response A 1-bit field, set to 0x0 to indicate an update request, and 0x1 to indicate an update response.
Operation Code Set to 0x5 for DNS updates.
Return Code For update responses, indicates the result of the query. The defined result codes are shown in Table 16-3.
Table 16-3 Defined Result Return Code Flags for Update Responses
Result Code Value |
Meaning |
|---|---|
0x0 |
No errorupdate successful. |
0x1 |
Format errorthe DNS server was unable to understand the update request. |
0x2 |
The name server encountered an internal failure while processing this request. |
0x3 |
Some name that ought to exist doesn't exist. |
0x4 |
The operation code isn't supported. |
0x5 |
The name server refuses to perform the operation for policy for security reasons. |
0x6 |
Some name that ought not to exist does exist. |
0x7 |
Some RR set that ought not to exist does exist. |
0x8 |
Some RR set that ought to exist doesn't exist. |
0x9 |
The server isn't authoritative for the zone named in the Zone section. |
0xA |
A name used in the Prerequisite or Update section is not within the zone denoted by the Zone section. |
Name-Query Message
A Name Lookup message uses the DNS message format defined in RFC 1034 and described earlier in the "DNS Query Message Format" section of this chapter. Network Monitor trace 16-1 (Capture 16-01, included in the \Captures folder on the companion CD-ROM) shows an example name query. In this trace, the following fields are set:
Query Identifier Set to a unique number so that the resolver can match the response to the query
Flags Set to indicate a standard query, with recursion if necessary
Question Count Set to 1
Question Entry Set to the domain name to resolve (kona.kapoho.com) and the RR to return (the host A record)
Name-Query Response Message
A Name-Query Response message is sent in response to a Name Query and is sent using the same query message format as the query response. Network Monitor trace 16-1 (Capture 16-01, included in the \Captures folder on the companion CD-ROM) displays an example query response in which the following fields are set:
Query Identifier Set to the unique number set in the query, to allow the resolver to match the response to the original query
Flags Set to indicate a response and a successful lookup
Question Count Set to 1
Answer Count Set to 1
Question Entry Set to the question contained in the query message
Answer Entry The RR requested in the query (the host record, containing the IP address of the queried domain)
Network Monitor trace 16-3 (Capture 16-03, included in the \Captures folder on the companion CD-ROM) shows a slightly different response message. In this trace, a resolver is attempting to resolve the (A) RR for ns1.kapoho.com. There's no Host (A) RR for this name, but there's an alias (CNAME). In the response, the replying DNS server returns two RRs: the CNAME RR, as well as the A Record for the canonical name (kona.kapoho.com).
Reverse-Name Query Message
Reverse-Name Query messages use the same message format as normal queries. The only differences in the contents are as follows:
The domain name being queried is different. For a reverse lookup, the resolver will construct a domain name in the in-addr.arpa domain based on the IP address that's being queried.
The queried record will be a PTR record, rather than an (A) record.
The Reverse-Name Query Reply message is also the same as a Query Reply message, except that a PTR record, rather than a host record, is returned. A reverse lookup can be seen in Network Monitor trace 16-2 above. In the trace, the resolver is looking for the host name of the host at 10.10.1.52, and thus queries for the domain 52.1.10.10.in-addr.arpa. The Reverse-Name Query Reply returns the requested PTR record, which shows the host name at this IP address to be kapoholt.kapoho.com.
Name Update Message
Name Update messages use the Name Update message format defined in RFC 2136 and described earlier in the "DNS Update Message Format" section of this chapter. Network Monitor trace 16-4 shows an example Name Update message. In this update, the key update message fields are set as follows:
Query Identifier Like query messages, update messages contain an identifier to enable the sender to match the response to the original update.
Flags Set to indicate a request and a dynamic update.
Update Zone Set to 1, and the zone section contains the zone to be updated.
Prerequisites Zone Set to 2, with two prerequisite records specified.
Update Zone Contains the RR that's to be updated.
Name Update Response Message
A Name Update Response message is issued in response to a Name Update Request. Network Monitor trace 16-4 contains an example of this in which the response can be seen to be identical to the request, except that the DNS flags in the message header are set to indicate this is a successful response. If the response had been unsuccessful, the response message would have contained an error code.
Summary
DNS was once an option for most Windows NT networks that used WINS (NetBIOS) for most domain operations, and as the basis of file and print sharing. DNS is now a key component in Windows 2000 networks and is required in those networks that deploy Windows 2000 Active Directory. In this chapter we have examined what DNS is and how it works, including DNS message formats and how the message appears on the wire. The chapter also has shown a number of Network Monitor captures, which are also contained on the companion CD-ROM for deeper study.
About the Authors
Thomas Lee is an independent computer consultant who has been working with Windows NT since 1993.
Joseph Davies is a Microsoft employee and has been a technical writer and instructor of TCP/IP and networking technology topics since 1993.
Copyright 2000 by Thomas Lee and Joseph Davies
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.
International rights = English only.
.gif)
.gif){kind=link}
.gif){kind=link}
.gif){kind=link}
.gif){kind=link}
.gif){kind=link}
.gif){kind=link}
.gif){kind=link}
.gif){kind=link}