Domain Name System (DNS)

Overview

Every host that runs TCP/IP must have a unique IP address that is used when communicating with other computers in a network. Computers operate easily with IP addresses, but people do not; 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 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 the Stanford Research Institute (SRI), was responsible for compiling a single file named HOSTS.TXT that contained the names and addresses of every computer. Administrators would e-mail updates to SRI, which would then update the HOSTS.TXT file. ARPANET users would then download the new version of HOSTS.TXT using File Transfer Protocol (FTP) and convert it for local use (for example, copy HOSTS.TXT /Etc/Hosts on UNIX systems).

As ARPANET grew, it became obvious that this approach would not 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 would be able to sustain.
• The static flat host file also meant that no two computers on the entire 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, time-sharing computers that had once made up the ARPANET were being superseded by networks of workstations, each 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 a better solution was required. Several proposals were generated based on the concept of a distributed naming service, based on a hierarchical namespace. RFCs 882 and 883 emerged, which describe the design for a domain name system based on a distributed database containing generalized resource information. This design is described in RFCs 1034 and 1035. The service that is used in today's Internet has evolved beyond these early RFCs, and updates and refinements continue.

Overview of DNS

To facilitate communications between computers, computers can be given names within a namespace. The specific namespace 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 namespace being used. This resolution is done by a name-resolution service.

There are two main namespaces, and name-resolution methods, used within Microsoft Windows Server 2003: NetBIOS, implemented by Windows Internet Naming Service (WINS; described in Chapter 18), and the Domain Name System (DNS), described in this chapter. Windows Server 2003 also provides support for other namespaces, such as Novell NetWare and Banyan Vines, although discussion of these is outside the scope of this book.

This section describes DNS and the DNS protocol that is used to provide name resolution.

What Is DNS?

DNS is an Internet Engineering Task Force (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 namespace and associated resource records (RRs)A distributed database of name-related information.
• DNS name serversServers that store the domain namespace and RRs and answer queries from DNS clients.
• DNS resolversThe 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 DNS and defines important DNS terms.

Domain Namespace

The domain namespace is a hierarchical, tree-structured namespace, starting at an unnamed root used for all DNS operations. In the DNS namespace, each node and leaf in the domain namespace tree represents a named domain. Each domain can have additional child domains. Figure 17-1 illustrates the structure of an Internet domain namespace.

Figure 17-1: Domain namespace for the Internet.

Domain Names

Each node in the DNS tree, as illustrated in Figure 17-1, 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 namespace 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 uppercase or lowercase, 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

The domains directly below the root are called top-level domains (TLDs). Figure 17-1 illustrates some of the TLDs that have been defined for the Internet. Additional names (at least for the Internet) are difficult to create, although in 2000, the Internet Corporation for Assigned Names and Numbers (ICANN) did create an additional seven TLDs.

There are three categories of TLDs:

• ARPAThis is a special domain—it is only used today for reverse-name lookups.
• Generic TLDsThere are 14 TLDs, noted in Table 17-1. At one time the generic TLDs were all three characters long, but in November 2000, ICANN accepted seven new TLDs, some of which were longer (for example, .aero and .info).
• Two-letter country-based domain namesThese country code domains are based on the International Organization for Standardization (ISO) country name, and are used principally by companies and organizations outside the United States. The exception is the United Kingdom, which uses .uk as the TLD, even though its ISO country code is GB.

Table 17-1 shows the TLDs in use today, as defined by RFC 1591.

Resource Records

A resource record (RR) 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 uses this RR to obtain the IP address for the domain (host).

Each DNS server contains the RRs relating to those portions of the DNS namespace for which it is authoritative (or for which it can answer queries sent by a host). When a DNS server is authoritative for a portion of the DNS namespace, those systems' administrators are responsible for ensuring that the information about that DNS namespace 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 1034 and 1035, and in later RFCs. Most of the RR types are no longer needed or used, although all are fully supported by Windows Server 2003. Table 17-2 lists the key RRs that might be used in a Windows Server 2003 network. (For more detail on the contents of specific RRs, see the section entitled "DNS Resource Records," later in this chapter.)

RRs can be attached to any node in the DNS tree, although RRs are not 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 Exchanger [MX] records for mail to be sent to the Microsoft Corporation) as well as having subdomains 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 is recommended 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 accessing www.kapoho.com is generally unaware of which computer is actually servicing the 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 orrecords are held for the domain named kapoho.com. If the domain exists and the requested RRs exist, the DNS server returns the requested information in a query reply message. The query reply message returns 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 contains a request for the specific RR(s) that the resolver wishes 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. A DNS client kona.kapoho.com could, for instance, update the host record for 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 namespace is said to be the authority for that part of the namespace. 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 four DNS zone types implemented in the DNS Server service for Windows Server 2003:

• Standard primaryHolds 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 secondaryContains a read-only copy of zone information that can provide increased performance and resilience. Information in a primary zone is replicated to the secondary zone by use of the zone transfer mechanism.
• Active Directory–integratedA Microsoft proprietary zone type, where the zone information is held in the Windows Active Directory and replicated using Active Directory replication. Active Directory–integrated zones provide the administrator with considerable flexibility in terms of replication.
• StubA stub zone contains only the RRs needed to identify the authoritative DNS servers for the actual zone (SOA, NS, and Glue A records).

With traditional zones, the master copy of a zone is held in a primary zone on a single DNS server. On that server, the zone has a Start of Authority (SOA) RR that specifies it to be the primary zone. To improve performance and redundancy, the RRs contained in a primary zone can be automatically replicated to one or more secondary zones held on other (secondary) 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 section entitled "Zone Transfer." When a zone is first created in Windows Server 2003, two RRs are created:

• An SOA record, which provides some basic parameters for the zone, such as its name (for example, kapoho.com), as well as the IP address of the primary server, and so on.
• An NS record, which identifies the server as one that is authoritative for this zone.

After the zone is created, the administrator can then add RRs to the zone, or can set the domain to be dynamically updated so that suitably configured hosts can automatically update this zone. For example, the administrator could add A records (host records) for hosts in the domain, and a computer capable of performing its own DNS dynamic updates—such as a computer running Windows 2000, Windows XP, or Windows Server 2003—can then directly update the A and PTR records on the DNS server. If the DNS client is also a Dynamic Host Configuration Protocol (DHCP) client, the administrator can configure a DHCP server to send the updates.

Once administrators have created the zone, they can add additional subdomains to the zone (for example, jh.kapoho.com). These might be added to delegate DNS services to a new building that is managed separately from the parent domain. This subdomain, which might reside in a separate zone on a separate DNS server, would have RRs added (for example, a host record for rebecca.jh.kapoho.com).

As Figure 17-2 illustrates, if you create subdomains, they can either be part of the same zone or belong to another zone on the same or a different DNS server. For example, the subdomain 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 subdomain to be managed and included as part of the original zone records, or to be delegated away to another zone created to support that subdomain.

Figure 17-2: Zones versus domains.

In this example, the domain kapoho.com has a subdomain of jh.kapoho.com. In addition, 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.comzone holds one host record for kona.kapoho.com and the jh.kapoho.com domain holds the host record for the host rebecca.jh.kapoho.com.

Active Directory–Integrated Zones

An important feature of the DNS Server service for Windows Server 2003 is the ability to store DNS zones within Active Directory. An Active Directory–integrated zone is a primary DNS zone that is held within Active Directory and replicated to other domain controllers using Active Directory replication (and not traditional zone transfer). Although this method of storing zones is a Microsoft proprietary approach, it can provide some useful benefits.

The main advantage of Active Directory–integrated zones is that the zones become, in effect, multimaster, 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 Active Directory replication, which can be more efficient across slow links because of the way that Active Directory compresses replication data between sites.

In Microsoft Windows 2000, all Active Directory–integrated zones were held in the domain name context of the Active Directory. This meant that any updates to an Active Directory zone would automatically be replicated to all domain controllers in that domain, whether or not they were DNS servers. For enterprises that had a large number of domain controllers in a domain, but not many DNS servers, this approach generated unnecessary replication. In addition, it meant some extra DNS replication planning for those organizations with multiple zones. This extra planning was needed to ensure, at a minimum, that all domain controllers were able to resolve the forest side locator records kept in the _msdcs subdomain of the organization's forest root domain name (for example, the _msdcs.kapoho.com domain for the organization's kapoho.com forest root domain).

With Windows Server 2003, the Active Directory–integrated zones can be held in one of three places:

• All domain controllers in the domain (the Windows 2000 behavior).
• All domain controllers that are DNS servers in the current domain; this eliminates DNS information being replicated to domain controllers that are not also DNS servers.
• All domain controllers that are DNS servers in the entire forest; this simplifies DNS replication for larger organizations with multiple domains.

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 and it 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 namespace. Subdomains 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, which is used to associate the IP address with the owning domain name. This lookup should correspond to an A RR for the host in a forward-lookup zone.

Reverse DNS zones have the same SOA and NS records as forward lookup zones. You can also configure reverse lookup zones to be traditional primary or secondary zones or to be Active Directory–integrated. Active Directory–integrated reverse lookup zones replicate in the same manner as Active Directory–integrated forward lookup zones.

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.

Inverse Queries

Inverse queries, originally described in RFC 1034, look up a host name based on its IP address. Inverse queries use a nonstandard DNS query operation. Inverse queries are now outdated and are generally not used by modern applications and operating systems.

Some early versions of Nslookup.exe, a utility used to test and troubleshoot a DNS service, did attempt to issue inverse queries. A Windows Server 2003 DNS server recognizes and accepts inverse query messages and answers them with a "fake" inverse query response. The version of Nslookup.exe that ships with Windows Server 2003 does not support inverse queries.

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 issues 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 it 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 issues iterative queries against other DNS servers if it is unable to answer a recursive query from cached or locally stored information.

DNS Resolver

In Windows Server 2003, the DNS resolver is a system component on a DNS client that performs DNS queries against a DNS server (or servers). The administrator configures the Windows Server 2003 TCP/IP protocol with the IP address of at least one DNS server to which the resolver sends one or more queries for DNS information.

In Windows Server 2003, the resolver is part of the DNS Client service. This service is installed automatically when Windows Server 2003 is installed, and runs within one of the many SVCHOST processes. Like most Windows Server 2003 services, the DNS Client service logs on using the System account. You can see the DNS Client service named Dnscache in the SVCHOST process with PID 812, in the following output:

C:Documents and SettingsAdministrator>tasklist /svc Image Name PID Services ========================= ====== ============================================= System Idle Process 0 N/A System 4 N/A smss.exe 288 N/A csrss.exe 356 N/A winlogon.exe 380 N/A services.exe 424 Eventlog, PlugPlay lsass.exe 436 HTTPFilter, kdc, Netlogon, NtLmSsp, PolicyAgent, ProtectedStorage, SamSs svchost.exe 572 RpcSs svchost.exe 608 TermService svchost.exe 812 Dhcp, Dnscache svchost.exe 876 LmHosts svchost.exe 888 AppMgmt, BITS, Browser, CryptSvc, dmserver, ERSvc, EventSystem, helpsvc, lanmanserver, lanmanworkstation, Netman, Nla, RasMan, Schedule, seclogon, SENS, ShellHWDetection, uploadmgr, W32Time, winmgmt, wuauserv, WZCSV spoolsv.exe 1132 Spooler msdtc.exe 1212 MSDTC certsrv.exe 1304 CertSvc dfssvc.exe 1332 Dfs dns.exe 1364 DNS inetinfo.exe 1468 IISADMIN, NntpSvc, SMTPSVC InoRpc.exe 1504 InoRPC InoRT.exe 1676 InoRT InoTask.exe 1696 InoTask ismserv.exe 1784 IsmServ llssrv.exe 1812 LicenseService ntfrs.exe 1864 NtFrs svchost.exe 216 RemoteRegistry locator.exe 308 RpcLocator wins.exe 784 WINS svchost.exe 1360 W3SVC explorer.exe 3108 N/A svchost.exe 3220 TapiSrv Realmon.exe 3228 N/A cmd.exe 3240 N/A cmd.exe 3248 N/A mmc.exe 2520 N/A mmc.exe 3636 N/A notepad.exe 2604 N/A setiathome-3.03.i386-winn 3196 N/A setiathome-3.03.i386-winn 2004 N/A cmd.exe 3016 N/A wmiprvse.exe 2760 N/A tasklist.exe 3020 N/A

DNS Resolver Cache

An IP host that needs to contact another host on a regular basis needs to resolve a particular DNS name many times (for example, 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, the DNS Client service on Windows Server 2003 hosts implements a local 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, when present, is used to answer subsequent queries and avoid sending the query to a DNS server. By default, the TTL used for the local DNS cache is 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 DNS resolver cache contents. The following output shows an example:

C:>ipconfig /displaydns Windows IP Configuration 1.0.0.127.in-addr.arpa ———————————————————— Record Name . . . . . : 1.0.0.127.in-addr.arpa. Record Type . . . . . : 12 Time To Live . . . . : 0 Data Length . . . . . : 4 Section . . . . . . . : Answer PTR Record . . . . . : localhost 7c5fa925-791e-4aa3-b8d0-ea70ed74adc4._msdcs.kapoho.com ———————————————————— Record Name . . . . . : 7c5fa925-791e-4aa3-b8d0-ea70ed74adc4._msdcs.kapoho.com Record Type . . . . . : 5 Time To Live . . . . : 595 Data Length . . . . . : 4 Section . . . . . . . : Answer CNAME Record . . . . : kapoho10.kapoho.com maui ———————————————————— Record Name . . . . . : maui.kapoho.com Record Type . . . . . : 1 Time To Live . . . . : 1195 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 10.10.1.62 localhost ———————————————————— Record Name . . . . . : localhost Record Type . . . . . : 1 Time To Live . . . . : 0 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 127.0.0.11

Negative Caching

The DNS Client service for Windows Server 2003 provides negative caching support. Negative caching occurs when an RR for a queried domain name does not exist or when the domain name itself does not exist, in which case, the lack of resolution is stored. Negative caching prevents the repetition of additional queries for RRs or domains that do not 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, through the cache, for a default time of 300 seconds (5 minutes). To avoid the continued negative caching of stale information, any query information negatively cached is held for a shorter period than 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 SystemCurrentControlSetServicesDnscacheParameters Data type: REG_DWORD Default value: 0x12c (300 seconds, or 5 minutes) Valid range: 0–0xFFFFFFFF Present by default: No

Negative Cache Time sets the number of seconds for the negative caching time-out. The recommended time is less than 1 day, which prevents very stale records. Negative caching reduces the load on DNS servers, but should the relevant RRs become available, later queries can be issued to obtain the information.

Zone Transfer

To improve the resilience and performance of the DNS resolution, it is 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 is 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 at intervals defined in the zone's SOA record. Zone transfers can also be performed manually using the DNS MMC snap-in, which might be done if the administrator suspects the secondary zone has not been properly updated.

When a standard secondary zone is created on a Windows Server 2003 DNS server, the DNS server transfers all RRs from the standard primary zone to the new standard secondary zone. The DNS server does this to obtain 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 is needed each time the primary zone is updated, such as when a new host is added to the domain or the IP address for a host is changed.

After the RRs have been replicated, the server on which the new standard secondary zone resides checks at regular intervals with the server on which the primary zone resides to determine if there are any changes to the primary zone. This is determined by polling the primary zone on a regular basis, defined by the network 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 17-06, included in the Captures folder on the companion CD-ROM):

1 21.108471 Kapoho10 Mahimahi DNS 0x6000:Std Qry for kapoho.com. of type SOA on class INET addr. 10.10.1.74 10.10.1.200 2 21.108471 Mahimahi Kapoho10 DNS 0x6000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr. 10.10.1.200 10.10.1.74 3 21.108471 Kapoho10 Mahimahi DNS 0x4000:Std Qry for kapoho.com. of type Req for incrmntl zn Xfer on class INET addr. 10.10.1.74 10.10.1.200 4 21.108471 Mahimahi Kapoho10 DNS 0x4000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr. 10.10.1.200 10.10.1.74

In this trace, the DNS server holding the secondary zone (Kapoho10) queries the primary zone to obtain the primary's SOA record, which will tell the secondary zone the version number of the zone at the primary server. The secondary server discovers that the version number on the primary DNS server is higher and requests a zone transfer.

For manually maintained DNS servers, updating (or not) the SOA records version number 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 zone. With Windows Server 2003, changes made to the zone, either by manual update using the DNS snap-in or by dynamic registration, trigger an update to the version number, thus enabling the secondary server to carry out the server 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 wide area network (WAN) links. To improve the efficiency of zone transfers, the DNS Server service for Windows Server 2003 implements incremental zone transfer, as defined in RFC 1995. With incremental zone transfers, only the changes to the zone are transferred, rather than the entire zone. This can significantly reduce the traffic needed to keep a secondary zone current.

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 Server 2003 stores the incremental zone transfer information for each zone in a text file in the %Systemroot%System32Dns folder with a name based on the name of the file holding 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. A part of this log, which was used by the DNS server on kapoho10 to perform the preceding zone transfer, is shown here:

$SOURCE ADMIN $VERSION 84 $ADD rebecca A 10.10.1.199 $SOURCE ADMIN $VERSION 85 $DELETE @ IN SOA mahimahi.kapoho.net. hostmaster. ( 81 ; serial number 15 ; refresh 600 ; retry 86400 ; expire 3600 ) ; default TTL $ADD IN SOA mahimahi.kapoho.net. hostmaster. ( 85 ; serial number 15 ; refresh 600 ; retry 86400 ; expire 3600 ) ; default TTL

Active Directory–Integrated Zone Replication

Standard zones use traditional zone replication mechanisms to transfer zone information. Active Directory–integrated zones, however, use Active Directory replication to replicate updates. This provides the following three key benefits:

• DNS servers become multimaster. 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 Active Directory integration, any DNS server can accept the updates, which provide improved performance and scaling, as well as better fault tolerance.
• Active Directory replication is both more efficient and quicker. It transfers updated-only properties, not the entire zone, which means only the changes are transmitted across the network. In addition, replication between sites, typically involving slower links, can be highly compressed.
• The administrator only needs to plan and implement a single replication topology for Active Directory. This also replicates DNS changes but simplifies the planning and reduces bandwidth used.

For organizations using Active Directory, Active Directory–integrated zones are generally recommended. If the organization is, however, using third-party DNS servers, these servers are unlikely to support Active Directory–integrated zones.

Delegation of Domains

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 namespaces or networks, such as the Internet, is the ability to delegate the administration of domains. Domain delegation occurs when the responsibility of the RRs of a subdomain is passed from the owner of the parent domain to the owner of the subdomain.

At the heart of the Internet are 13 root servers, named A.ROOT-SERVERS.NET through M.ROOT-SERVERS.NET. These root servers are widely distributed around the world, although most are located in the United States. The root servers hold data for all the generic TLDs, such as .com, .org, .net, and .name, as well as for geographical domains, such as .uk and .jp.

Below the root and TLDs are the domains and subdomains belonging to individual organizations. In some TLDs, additional hierarchy levels are provided. For example, in the .uk domain, there are subdomains co.uk for U.K.-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 previously illustrated in Figure 17-2, there are boundaries between zones where responsibility for administration is delegated from zones closer to the TLDs to zones one degree farther from the TLDs. Within the kapoho.com domain there is a subdomain jh.kapoho.com. Responsibility for the subordinate domain can be delegated to a different set of DNS servers.

To implement a delegation, the parent zone must have both an A RR and a Name Service (NS) RR. Both should point to the new delegated domain's DNS servers. In the kapoho.com zone, illustrated in Figure 17-2, there must be an A and an NS record in the parent domain that point to a server authoritative for jh.kapoho.com. Windows Server 2003 has a Delegation Wizard to simplify the task of implementing a delegation.

Forwarder and Slave DNS Servers

When a resolver contacts a DNS server to resolve a domain name and return relevant RRs, the contacted DNS server first attempts to perform the lookup using zones defined on the server or information contained in its own cache. If this fails, by default the DNS server then starts to issue iterative queries to resolve the domain. This starts at the namespace 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 17-3, a forwarder is a DNS server that other DNS servers contact before attempting to perform the necessary name resolution.

Figure 17-3: DNS forwarder.

In this example, when any of the DNS clients send recursive queries to DNS servers A, B, and C, each DNS server attempts to answer the query from locally held zones or from its local cache. If this is unsuccessful, these servers issue a recursive query to DNS server D, which has a better chance of answering the query from its own cache. This arrangement can 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 attempt to resolve the queries themselves by issuing iterative queries, which, again, might not be desirable.

A slave server is a DNS server that attempts to resolve name queries by checking its cache and local zone files, and then it forwards the query to a DNS forwarder. A slave server does not attempt to perform iterative queries if the DNS forwarder is unable to answer the query.

Round Robin Load Balancing

Round robin is an approach for performing DNS load balancing. It is 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 multihomed services. For round robin to work, multiple 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 with three A records for www.kapoho.com pointing to the different servers. Round robin would need to be configured at the server. Round robin is enabled by default in Windows Server 2003. 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 takes the first IP address, the first query would use the IP address 10.1.1.151, and the second would use 10.1.1.152.

By default, the DNS Server service for Windows Server 2003 performs round robin for all RR types. You can specify that certain RR types do not have round robin rotation applied by setting the following registry entry:

DoNotRoundRobinTypes

Location: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDNSParameters Data type: REG_SZ Default value: none Present by default: No

The string for DoNotRoundRobinTypes is a comma-separated list of valid RR types. If you wanted to not round robin PTR, SRV, and NS records, the DoNotRoundRobinTypes value would be "ptr,srv,ns."

You can also turn off round robin entirely by using the DNS snap-in or by setting the following registry entry:

RoundRobin

Location: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDNSParameters Data type: REG_DWORD Default value: 1 Valid range: 0-1 (1 – Enable round robin, 0 – Disable round robin) Present by default: Yes

DNS Dynamic Updates

For large networks, getting all the necessary RR information into the DNS and keeping it current can be a significant task. To simplify the task, Windows Server 2003 includes support for dynamic updates to DNS, as described in RFC 2136.

With DNS dynamic updates, 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 of a Windows Server 2003 DHCP server, every time there is an address event (for instance, a new address or address renewal), as part of the DHCPlease-management process, the Windows 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 Server 2003 computers that are statically configured register both the A RR and the PTR RR with the DNS server themselves.

If a Windows DHCP client talks to a lower level DHCP server that does not handle Option 81, the client registers a PTR RR on its own. The DNS Server service for Windows Server 2003 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

IPv6 is a new version of IP. The DNS Server service for Windows Server 2003 provides support for IPv6 by implementing several additional pieces of functionality, including the following:

• AAAA RRThis new record type is defined to store a host's IPv6 address. A multihomed IPv6 host (for example, a host that has more than one IPv6 address) must have more than one AAAA record (known as a "quad A" record). The AAAA RR is similar to the A RR, 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 queryThe AAAA query for a specified domain name in the Internet class returns all associated AAAA RRs in the answer section of a response. The AAAA query does not perform additional section processing.
• IP6.ARPA domainThis domain is used to provide reverse-lookup faculties for IPv6 hosts (as the in-addr.arpa domain does for IPv4 addresses).

Similar to the in-addr.arpa domain for IPv4, an IPv6 address is represented as a name in the IP6.ARPA domain by a sequence of nibbles (hexadecimal digits) separated by periods 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. A hexadecimal digit represents each nibble. For example, the inverse-lookup domain name corresponding to the address 3ffe:ffff:1:2:3:4:567:89ab 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.f.f.f.f.e.f.f.3.IP6.ARPA.

Finally, to support IPv6, all existing DNS query types that perform type A additional section processing—such as NS or 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 adds 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.

DNS Extension Mechanism

The DNS protocol, on the wire, uses a number of fixed-length fields or fields with a set of possible values that is nearly used up. One example of this is the maximum allowable DNS packet size when using User Datagram Protocol (UDP), 512 bytes. To enable DNS clients and servers to use larger values, RFC 2671 defines a general extension model for DNS as well as the first extension (EDNS0). EDNS0 specifically provides a mechanism for clients and servers to use larger DNS messages over UDP. It is anticipated that further DNS extensions will be proposed and will be identified as EDNS1, EDNS2, and so forth.

EDNS0 enables DNS clients to advertise and support the transfer of DNS messages larger than 512 bytes. A DNS client that is capable of handling EDNS0 sends queries over UDP that contain a special pseudo-RR, the OPT resource record, to note the UDP packet size that the DNS client can support. This pseudo-RR enables servers that can also handle EDNS0 to increase the size of a DNS reply and send as many RRs as are allowed in the maximum UDP packet size (specified in the OPT RR).

The OPT RR is not an RR that you can add to the DNS database, but it is generated if and when a host can handle the DNS extensions. In addition, the OPT RR does not contain actual DNS data. Rather it contains the DNS client's maximum UDP payload size in its CLASS field, as well as the number of octets in the largest UDP payload that the client can deliver in the clients' network.

By default, the DNS server includes an OPT RR in the additional section of any query it sends if it is capable of supporting EDNS0. The OPT record gives the UDP maximum length of a DNS response. If a DNS server receives a DNS query that does not contain an OPT RR, the server assumes the querier's system does not support EDNS0 and all responses to this system are truncated if the maximum size is greater than 512 octets.

If the DNS Server service for Windows Server 2003 receives either a request or response from any host that has an OPT record, the DNS server caches this information, by default, for one week. In addition, if a request or a response does not contain an OPT record, this is also cached.

You can modify the EDNS cache time-out by modifying the following registry value:

EDNSCacheTimeout

Location: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDNSParameters Data type: REG_DWORD Default value: 25200 (7 days) Valid range: 3600 (1 hour) to 15724800 (182 days)

Present by default: NoIf a DNS server does not support ENDS0, then queries containing the OPT resource might not be handled and might return an error code. The error codes that could be encountered are as follows:

• FORMERR (1)The name server did not interpret the OPT RR.
• SERVFAIL(2)The name server did not process the query because of a problem with the name server.
• NOTIMPL(4)The name server does not support the kind of query requested.

DNS Security

RFC 2535 defines a set of facilities, known as DNS Security (DNSSEC), that provides authentication and data integrity of DNS data to resolvers. These extensions allow digital signatures to be encrypted using private keys. These signatures can then be sent as RRs from DNS servers hosting signed (DNSSEC-compliant) zones to resolvers. DNSSEC-aware revolvers can then authenticate these signatures using public keys. The digital signatures and public keys are added to a signed zone in the form of RRs.

With DNSSEC, a zone has a public and a private key. The private key, which is not loaded in the zone, is used to sign a zone or parts of a zone. The public key is used to validate this digital signature. The zone's private key can be used to sign each domain name in the zone (for example, rebecca.kapoho.com). These signatures can then be added to the zone and returned as part of a query to a DNSSEC-aware DNS resolver. Such a resolver can use the public key to authenticate the RRs.

With DNSSEC, a zone's public key is stored in a KEY RR. The digital signature is contained in a SIG RR. KEY RRs must be provided to the resolver before it can authenticate SIG RRs. DNSSEC introduces one further RR, the NXT record, which can be used to provide cryptographic assurance to a resolver that a particular RR does not exist.

DNSSEC is not fully supported in the DNS Server service for Windows Server 2003. The DNS Server service for Windows Server 2003 provides basic support of the DNSSEC protocol, as defined in RFC 2535. This would enable, for example, a Windows Server 2003 DNS server to operate as a secondary to a BIND server that fully supports DNSSEC. In particular, Windows Server 2003 provides no way to sign or verify the digital signatures. The Windows Server 2003 resolver does not validate any of the DNSSEC data returned as the result of a query.

How DNS Works

In this section, the DNS client and server functions are described in more detail.

Configuring DNS Client Functions

With Windows Server 2003, there is generally very little configuration to do for a client with respect to DNS. Generally, it is only necessary to configure the host with the IP address of a primary and secondary DNS server. This can be simplified by using DHCP to assign the IP address of the DNS servers.

Usually, DNS default client behavior is adequate. However, in certain cases, some change to the default behavior might be appropriate. The following registry keys can be used to change how the Windows Server 2003 family 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 change the TTL value, you can configure the following registry value:

DefaultRegistrationTTL

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Value type: REG_DWORD Default: 0x4B0 (1200 seconds, or 20 minutes) Valid range: 0–0xffffffff Present by default: No

After setting this registry key, you do not need to reboot your computer for the updated TTL to be used. All registration requests contain the new TTL set in the value entry.

Disabling Dynamic Updates

Although the automatic updating of DNS zones by a host can be useful, in some environments it might not be desirable. You can use the following registry key to disable DNS dynamic updates either for a computer running Windows Server 2003 as a whole, or for just one or more interfaces on that computer. This entry disables the DNS client from registering the A and PTR records for some or all interfaces on a computer running Windows Server 2003.

DisableDynamicUpdate

Key: KEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesTcpipParameters Or HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices TcpipParametersInterfaces<InterfaceGUID> Value type: REG_DWORD—Boolean Valid range: 0, 1 (False, True) Default: 0 Present by default: No

Resolving Names

DNS name resolution occurs when a DNS resolver sends a DNS server a query message containing a request 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 17-01, included in the Captures folder on the companion CD-ROM) shows the process of issuing and resolving a name query.

1 7.014382 0050564050E1 3COM 6B15C7 DNS 0x1C:Std Qry for kona.kapoho.com. of type Host Addr on class INET addr. 10.10.1.68 10.10.1.200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xCC5; Proto = UDP; Len: 61 + UDP: Src Port: Unknown, (1026); Dst Port: DNS (53); Length = 41 (0x29) DNS: 0x1C:Std Qry for kona.kapoho.com. of type Host Addr on class INET addr. DNS: Query Identifier = 28 (0x1C) DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: 0............... = Request DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........0....... = No recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (1) DNS: Answer Entry Count = 0 (0) DNS: Name Server Count = 0 (0) DNS: Additional Records Count = 0 (0) 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 7.024396 3COM 6B15C7 0050564050E1 DNS 0x1C:Std Qry Resp. for kona.kapoho.com. of type Host Addr on class INET addr. 10.10.1.200 10.10.1.68 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x43AE; Proto = UDP; Len: 77 + UDP: Src Port: DNS, (53); Dst Port: Unknown (1026); Length = 57 (0x39) DNS: 0x1C:Std Qry Resp. for kona.kapoho.com. of type Host Addr on class INET addr. DNS: Query Identifier = 28 (0x1C) DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode No error DNS: 1............... = Response DNS: .0000........... = Standard Query DNS: .....1.......... = Server authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........1....... = Recursive queries supported by server DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (1) DNS: Answer Entry Count = 1 (1) DNS: Name Server Count = 0 (0) DNS: Additional Records Count = 0 (0) 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 this trace, a client sends a DNS query to request the DNS server to return all A RRs for kona.kapoho.com. The query response contains the question entry and the answer RRs. In this case, there is only one A record to return pointing to 10.10.2.200.

Network Monitor trace 17-2 (Capture 17-02, included in the Captures folder on the companion CD-ROM) shows a Reverse-Lookup Query. In this trace, the querying host at 10.10.1.68 queries DNS for the host name for the host at 10.10.1.200. To determine this, the resolver queries for 200.1.10.10.in-addr.arpa and requests any PTR records. The DNS server then returns the PTR record, which shows the host to be mahimahi.kapoho.com.

Resolving Aliases

The CNAME RR allows you to create an alias for a host. For example, you could create an alias ns1.kapoho.com for the host mahimahi.kapoho.net. When a resolver performs forward name resolution, it does not know, in advance, whether the name relates to a Host Address (A) RR or to a CNAME. If it relates to the CNAME, the DNS server could just return the CNAME record. This would, however mean that the real host name still needs to be resolved. To avoid extra DNS traffic, when a DNS server returns a CNAME in response to an A RR lookup, a Windows Server 2003 DNS server also returns the A record relating to the CNAME.

The following Network Monitor trace (Capture 17-03, included in the Captures folder on the companion CD-ROM) shows the process of issuing and resolving a canonical name.

1 0.000000 0050564050E1 3COM 6B15C7 DNS 0x57:Std Qry for ns1.kapoho.com. of type Host Add 10.10.1.68 10.10.1.200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x9C66; Proto = UDP; Len: 60 + UDP: Src Port: Unknown, (1026); Dst Port: DNS (53); Length = 40 (0x28) DNS: 0x57:Std Qry for ns1.kapoho.com. of type Host Addr on class INET addr. DNS: Query Identifier = 87 (0x57) + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (1) DNS: Answer Entry Count = 0 (0) DNS: Name Server Count = 0 (0) DNS: Additional Records Count = 0 (0) 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 0.000000 3COM 6B15C7 0050564050E1 DNS 0x57:Std Qry Resp. for ns1.kapoho.com. of type Ca 10.10.1.200 10.10.1.68 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x4D06; Proto = UDP; Len: 99 + UDP: Src Port: DNS, (53); Dst Port: Unknown (1026); Length = 79 (0x4F) DNS: 0x57:Std Qry Resp. for ns1.kapoho.com. of type Canonical name on class INET addr. DNS: Query Identifier = 87 (0x57) + DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (1) DNS: Answer Entry Count = 2 (0x2) DNS: Name Server Count = 0 (0) DNS: Additional Records Count = 0 (0) 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 Name: ns1.kapoho.com. DNS: Resource Type = Canonical name for alias DNS: Resource Class = Internet address class DNS: Time To Live = 3600 (0xE10) DNS: Resource Data Length = 11 (0xB) DNS: Owner primary name: mahimahi.kapoho.com. DNS: Resource Record: mahimahi.kapoho.com. of type Host Addr on class INET addr. DNS: Resource Name: mahimahi.kapoho.com. DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 3600 (0xE10) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 10.10.1.200

In this trace, the DNS client sends a DNS query to the DNS server requesting the A (host) record for ns1.kapoho.com, which is actually an alias for mahimahi.kapoho.com. In the DNS reply, there are two answer RRs. The first is the CNAME RR for ns1.kapoho.com, which contains the canonical name. The second answer RR is the A record for mahimahi.kapoho.com, which contains the IP address of this computer (10.10.1.200).

Dynamically Updating DNS

DNS dynamic updates, described in RFC 2136, are a mechanism that enables DNS clients to add or delete a specific RR or sets of RRs, known as RRSets, to any zone. Dynamic updates can simplify the process of managing the contents of a DNS zone.

Dynamic update requests can also state prerequisites specified separately from update operations. These can be tested before an update can occur. When prerequisites are used with dynamic updates, the updates are said to be atomic; that is, all prerequisites must be satisfied for the update operation to be carried out.

Windows Server 2003 fully supports DNS dynamic updates. From the client side, the Windows Server 2003 TCP/IP client and the DHCP server both issue DNS dynamic update requests to register A and PTR records. On the server side, the DNS Server service for Windows Server 2003 accepts DNS dynamic updates. DNS dynamic updates for AAAA records are also supported by Windows XP and Windows Server 2003 for both DNS clients and servers.

The following Network Monitor trace (Capture 17-04, included in the Captures folder on the companion CD-ROM) shows the process of dynamically registering an A RR.

1 15.472248 KAPOHO11 MAHIMAHI DNS 0x62:Dyn Upd PRE/UPD records to kapoho11.kapoho.n KAPOHO11 MAHIMAHI IP + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xB1BD; Proto = UDP; Len: 115 + UDP: Src Port: Unknown, (1026); Dst Port: DNS (53); Length = 95 (0x5F) DNS: 0x62:Dyn Upd PRE/UPD records to kapoho11.kapoho.net. of type Canonical name DNS: Query Identifier = 98 (0x62) + DNS: DNS Flags = Query, OpCode - Dyn Upd, RCode - No error DNS: Zone Count = 1 (1) DNS: Prerequisite Section Entry Count = 1 (1) DNS: Update Section Entry Count = 2 (0x2) DNS: Additional Records Count = 0 (0) DNS: Update Zone: kapoho.net. of type SOA on class INET addr. DNS: Update Zone Name: kapoho.net. DNS: Update Zone Type = Start of zone of authority DNS: Update Zone Class = Internet address class DNS: Prerequisite: kapoho11.kapoho.net. of type Canonical name on class Unknown Class DNS: Resource Name: kapoho11.kapoho.net. DNS: Resource Type = Canonical name for alias DNS: Resource Class = 0x00FE DNS: Time To Live = 0 (0) DNS: Resource Data Length = 0 (0) DNS: Update: kapoho11.kapoho.net. of type Host Addr on class Req. for any(2 records present) + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class Req. for any + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class INET addr. 2 15.482263 MAHIMAHI KAPOHO11 DNS 0x62:Dyn Upd Resp. PRE/UPD records to kapoho11.ka MAHIMAHI KAPOHO11 IP + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x942B; Proto = UDP; Len: 115 + UDP: Src Port: DNS, (53); Dst Port: Unknown (1026); Length = 95 (0x5F) DNS: 0x62:Dyn Upd Resp. PRE/UPD records to kapoho11.kapoho.net. of type Canonical name DNS: Query Identifier = 98 (0x62) + DNS: DNS Flags = Response, OpCode - Dyn Upd, RCode - No error DNS: Zone Count = 1 (1) DNS: Prerequisite Section Entry Count = 1 (1) DNS: Update Section Entry Count = 2 (0x2) DNS: Additional Records Count = 0 (0) DNS: Update Zone: kapoho.net. of type SOA on class INET addr. DNS: Update Zone Name: kapoho.net. DNS: Update Zone Type = Start of zone of authority DNS: Update Zone Class = Internet address class DNS: Prerequisite: kapoho11.kapoho.net. of type Canonical name on class Unknown Class DNS: Resource Name: kapoho11.kapoho.net. DNS: Resource Type = Canonical name for alias DNS: Resource Class = 0x00FE DNS: Time To Live = 0 (0) DNS: Resource Data Length = 0 (0) DNS: Update: kapoho11.kapoho.net. of type Host Addr on class Req. for any(2 records present) + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class Req. for any + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class INET addr.

In this trace, the DNS 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 transferThis approach, described in RFC 1034, involves the secondary server requesting a full copy of the zone from the primary server.
• Incremental zone transferThis approach, 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 zone can thus request only the changes that occurred since the last time the secondary zone was updated.
• Active Directory zone transferActive Directory zones are replicated to all domain controllers in the Windows Server 2003 domain using Active Directory replication.

The traditional zone transfer mechanism can be wasteful of network resources if the change in the transferred RRs is small in relation to the overall zone. In such cases, incremental zone transfer is more efficient. The following Network Monitor trace (Capture 17-05, included in the Captures folder on the companion CD-ROM) shows a traditional zone transfer:

1 78.603025 Secondary Primary TCP ....S., len: 0, seq: 105565995- 105565995, ack 2 78.603025 Primary Secondary TCP .A..S., len: 0, seq:3198736198- 3198736198, ack 3 78.603025 Secondary Primary TCP .A...., len: 0, seq: 105565996- 105565996, ack 4 78.613040 Secondary Primary DNS 0x0:Std Qry for kapoho.com. of type Req for zn Xfer on class INET addr. 5 78.613040 Primary Secondary DNS 0x0:Std Qry Resp. for kapoho.com. of type SOA on class INET addr. 6 78.613040 Primary Secondary DNS 0x6574:Std Qry for _ of type Unknown Type on class Unknown Class 7 78.613040 Secondary Primary TCP .A...., len: 0, seq: 105566028- 105566028, ack: 8 78.613040 Primary Secondary DNS 0x7200:Std Qry for X of type Unknown Type on class Unknown Class 9 78.643083 Secondary Primary TCP .A...F, len: 0, seq: 105566028- 105566028, ack 10 78.643083 Primary Secondary TCP .A...., len: 0, seq:3198739143- 3198739143, ack 11 78.643083 Primary Secondary TCP .A...F, len: 0, seq:3198739143- 3198739143, ack 12 78.643083 Secondary Primary TCP .A...., len: 0, seq: 105566029- 105566029, ack

This trace 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 standard zone transfer, the first and last record transferred is always the zone's 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, the DNS Server service for Windows Server 2003 uses incremental transfers when possible.

The following Network Monitor trace (Capture 17-06, included in the Captures folder on the companion CD-ROM) shows an incremental zone transfer:

1 21.108471 Secondary Primary DNS 0x6000:Std Qry for kapoho.com. of type SOA on class INET addr. 2 21.108471 Primary Secondary DNS 0x6000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr. 3 21.108471 Secondary Primary DNS 0x4000:Std Qry for kapoho.com. of type Req for incrmntl zn Xfer on class INET addr. 4 21.108471 Primary Secondary 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 using TCP.

Active Directory replication is a proprietary solution that can be used only with Microsoft Windows 2000 or Windows Server 2003 domain controllers. Normal DNS zone transfers are pull in nature—the secondary DNS servers pull the zone or zone changes from the primary server. Active Directory replication, on the other hand, is push in nature—the directory changes are pushed from the domain controller on which the change occurred to the other domain controllers. For zones that change little, Active Directory replication ensures that all DNS servers storing the zone are updated quickly. For more dynamic zones this tends to smooth the replication traffic. Active Directory replication is beyond the scope of this book.

DNS Resource Records

This section describes the contents of the DNS RRs.

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 contains a common set of information, as follows:

• OwnerIndicates the DNS domain in which the RR is found.
• TTLThe 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 is not to be cached. As an example, SOA records have a default TTL of 3600 seconds (1 hour). This prevents these records from being cached by other DNS servers for a longer period, which would delay the propagation of changes.
• ClassFor most RRs, this field is optional. Where it is 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.
• TypeThis 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 DataThis 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 Server 2003, most DNS information is either automatically added to the server or can be left to a default value. For most organizations running Windows 2000, Windows XP, and Windows Server 2003, DNS is self-maintaining once the DNS servers are installed and the relevant zones are created. However, the details on RR types can be useful for those integrating Windows Server 2003 with a non–Windows 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 just-mentioned data items, as a set of text fields separated by white space. In the zone file, each RR consists of these data items, although different records 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: 93 @ IN SOA mahimahi.kapoho.com. hostmaster. ( 93 ; serial number 15 ; refresh 600 ; retry 86400 ; expire 3600 ) ; default TTL ; Zone NS records ; There are 2 DNS servers for this zone @ NS kapoho10.kapoho.com. @ NS mahimahi.kapoho.com. ; Zone records @ 600 A 10.10.1.74 @ 600 A 10.10.1.200 kapoho10 35 A 10.10.1.74 kona 1200 A 10.10.2.200 mahimahi A 10.10.1.200 maui 1200 A 10.10.1.62 tallguy 1200 A 10.10.2.100 1200 A 10.10.1.100 waimea 1200 A 10.10.1.67 ; Aliases news CNAME kona2.kapoho.com. ns1 CNAME mahimahi.kapoho.com.

Zone data for Active Directory–integrated zones are held as a series of Active Directory objects representing this data. For more detail on how Active Directory holds DNS-integrated zones, see Windows Server 2003 Help And Support.

Where Are RRs Located?

RRs for standard zones are stored in the folder %Systemroot%System32Dns. 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 Active Directory–integrated DNS zones are stored within Active Directory itself. Active Directory uses the following two main object classes to hold this DNS information:

• dnsZoneRepresents an Active Directory–integrated zone that contains dnsNode objects. This object class is the Active Directory 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 it can be dynamically updated.
• dnsNodeCorresponds to the individual RRs in the zone. Each dnsNode object has a dnsRecord attribute containing the resource information.

RRs Supported by Windows Server 2003

The DNS Server service for Windows Server 2003 supports all RFC-compliant RRs. Many of these are not commonly, or ever, used. The following sections list the most commonly used RRs. For the RR syntax and an example, see the topic entitled "Resource Records Reference" in Windows Server 2003 Help And Support.

• Host Address (A)This RR contains a host address RR that maps a DNS domain name to an IPv4 32-bit address.
• IPv6 Host Record (AAAA)This RR contains a host address RR that maps a DNS domain name to an IPv6 128-bit address.
• 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 namespace. The fully qualified canonical name should end with a full stop (".").
• KEY (KEY)The KEY record holds a public key for a DNSSEC-aware zone. KEY RRs are signed by the key from their parent zone.
• Mail Exchanger (MX)The MX record provides message routing to a mail-exchanger host for any mail that is to be sent to the target domain. This RR also contains a two-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.
• Next (NXT)This record is used as part of DNSSEC. The NXT record is used to indicate the next RR in the zone. In conjunction with a SIG record, this can provide cryptographic assurance of the nonexistence of a name in a zone. For a given domain name, such as puna.kapoho.com, the NXT record points to the next record in the zone, (for example, waimea.kapoho.com) and states which RRs exist at the domain name (for example, NS, SOA, and so on). If the DNS server receives a request for, say, sunshine.kapoho.com, the negative reply would contain the reply code NXDOMAIN. The authority section of the reply would include the NXT and SIG records for the domain name after and before the name that did not exist.
• Option (OPT)This is a pseudo-RR, used to provide the extended DNS functionality provided by EDNS0. An OPT RR can be in any DNS query response. The OPT record relates to the underlying transport-level message (that is, the UDP datagram's payload) and not to the DNS data.

  In an OPT pseudo-RR, the Name field is always empty (that is, the root domain), and the Class value holds the sender's maximum UDP payload size. This value signifies the largest UDP payload that can be delivered and reassembled in the sender's network stack. RFC 2671 suggests for Ethernet that a value of 1280 is considered reasonable; this is the default value used by Windows Server 2003.

• Pointer (PTR)The PTR record is used to store the FQDN for an IP address for reverse name queries. The PTR record is used only within the in-addr.arpa domain.
• Signature (SIG)The SIG record is used by DNSSEC to hold the digital signature for an RR or set of RRs.
• Service Locator (SRV)The SRV RR enables a computer to locate a host providing a specific service, such as a Windows Server 2003 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 Server 2003 Active Directory, where all relevant SRV RRs are automatically populated into the DNS.

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 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 fits into the UDP datagram. The DNS server sets 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. If the client and server support EDNS0, they can exchange larger UDP datagrams.

DNS Message Types

DNS originally provided dynamic name resolution 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 2136 defines the DNS dynamic update facility, which makes use of update messages, whose format is similar to and derived from query messages. Both message types are described next.

DNS Query Message Format

All DNS query messages share a common basic format, as Figure 17-4 illustrates.

Figure 17-4: Generic DNS query message format.

As can be seen from Figure 17-4, the DNS query message consists of a fixed-length 12-byte header, plus a variable portion holding question, answer, authority, and additional DNS RRs.

DNS Query Message Header

The DNS message header consists of the following fields:

• Transaction IDA 16-bit field used to identify a specific DNS transaction. The originator creates the transaction ID and the responder copies it 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.
• FlagsA 16-bit field containing various service flags, described in more detail later in this chapter.
• Question RR CountA 16-bit field indicating the number of entries in the question section in the DNS message.
• Answer RR CountA 16-bit field indicating the number of entries in the answer RRs section of the DNS message.
• Authority RR CountA 16-bit field indicating the number of authority RRs in the DNS message.
• Additional RR CountA 16-bit field indicating the number of additional RRs in the DNS message.

The DNS header is shown in Figure 17-5.

Figure 17-5: DNS message header.

The Flags field contains a number of status fields that are communicated between client and server. Figure 17-6 shows the format of the Flags field.

Figure 17-6: DNS message Flags field.

The individual fields in the Flags field are as follows:

• Request/ResponseThis 1-bit field is set to 0 indicate a name service request and 1 to indicate a name service response.
• Operation CodeThis 4-bit field indicates the specific name service operation of the name service packet, as listed in Table 17-3.

  Table 17-3: Operation Codes

  Operation Code	Operation
  0x0	Query
  1	Inverse Query
  0x2	Server Status Request

• Authoritative AnswerThis flag is set in a reply when the responder is authoritative for the domain name in the question section.
• TruncationThis flag is set to 1 if the total number of responses could not 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 unless EDNS0 and longer UDP datagrams are being used.
• Recursion DesiredThis flag is set to 1 to indicate a recursive query. For queries, if this bit is set to 0 and the name server contacted is not authoritative for the query, the DNS server returns a list of other name servers that can be contacted for the answer. This is how iterative queries are handled during name resolution.
• Recursion AvailableDNS servers set this flag to 1 to indicate that they can handle recursive queries.
• ReservedThese 3 bits are reserved, and set to 0.
• Return CodeA 4-bit field holding the return code. A value of 0 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 does not exist.

DNS Query Question Entries

In a DNS query, the question entry contains the domain name being queried. Figure 17-7 displays the format of a Question entry.

Figure 17-7: Question entry format.

The question entry is made up of the following three fields:

• Question NameThe domain name being queried. The format of this field is discussed below.
• Question TypeThis field indicates the records that should be returned, expressed as a 16-bit integer, as shown in Table 17-4.

  Table 17-4: Records Returned for Each Type Value

  Type Value	Record(s) Returned
  0x01	Host record
  0x02	Name server (A) record
  0x05	Alias (CNAME) record
  0x0C (12)	Reverse-lookup (PTR) record
  0x0F (15)	Mail exchanger (MX) record
  0x21 (33)	Service (SRV) record
  0xFB (251)	Incremental zone transfer (IXFR) record
  0xFC (252)	Standard zone transfer (AXFR) record
  0xFF (255)	All records

• Question ClassNormally set to 0x00-01. This represents the IN (Internet) 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 using a length-value format. The domain kapoho.com, for example, consists of two labels (kapoho and com). In the Question Name field, the domain name is encoded as a series of length-value pairs consisting of a 1-byte field that indicates the length of the value, followed by the value (the label). The domain kapoho.com, therefore, would be expressed as 0x06kapoho0x03com0x00, where the hexadecimal digits represent the length of each label, the ASCII characters represent the individual labels, and the final 0 indicates the end of the name.

RRs

When a DNS server sends a query response back to a DNS client, the answer, authority, and additional information sections of the DNS message can contain RRs, which answer the question in the question section. Figure 17-8 illustrates the format of these RRs.

Figure 17-8: DNS RR format.

The fields in an RR are as follows:

• RR NameThe 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 previous section.
• Record TypeThe RR type value, as previously noted.
• Record ClassThe RR class code; there is only one record class used currently: 0x00-01, Internet Class.
• Time-To-LiveTTL, expressed in seconds held in a 32-bit unsigned field.
• Resource Data LengthA 2-byte field that indicates the length of the resource data.
• Resource DataVariable-length data corresponding to the RR type.

The RR Name field is encoded in the same way as the Question Name field described earlier. However, if the name is already present elsewhere in the DNS message, then a 2-byte field that acts as a pointer to the name already present is used in place of a length-value encoded name. A pointer, instead of an encoded name, is indicated by setting the two high-order bits in the first byte of the RR Name field to 11. The RR Name field is then interpreted as a 16-bit field: the first 2 bits are fixed at 11, and the last 14 bits are used as a byte offset pointer (starting at 0) indicating where the previously stored name is located in the DNS message.

For a simple DNS Query Response message, the RR Name for an Answer RR is the same as the Resource Name for the Question entry, which begins in the 12th byte position (starting at 0) from the beginning of the DNS message. Therefore, the RR Name field is a 2-byte field containing 0xC0-0C. Figure 17-9 shows this relationship.

Figure 17-9: The RR Name as a pointer to a name stored elsewhere in the DNS message.

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 that contain the update. Figure 17-10 displays the general format of the DNS Update message.

Figure 17-10: General Update message format.

DNS Update Message Flags

The DNS Update message has a Flags field, similar to DNS Query messages but with a slightly different format. Figure 17-11 shows the format of the Flags field for DNS Update messages.

Figure 17-11: The Flags field of a DNS Update message.

The DNS Update message flags are used as follows:

• Request/ResponseA 1-bit field, set to 0 to indicate an update request and 1 to indicate an update response.
• Operation CodeSet to 0x5 for DNS updates.
• ReservedThese 7 bits are reserved and set to 0.
• Return CodeFor update responses, indicates the result of the query. The defined result codes are shown in Table 17-5.

  Table 17-5: Defined Result Return Code Flags for Update Responses

  Result Code Value	Meaning
  0	No error; the update was successful.
  1	Format error; the 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 should exist does not exist.
  0x4	The operation code is not supported.
  0x5	The name server refuses to perform the operation for policy or security reasons.
  0x6	Some name that should not exist does exist.
  0x7	Some RR set that should not exist does exist.
  0x8	Some RR set that should exist does not exist.
  0x9	The server is not 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 Query message uses the DNS message format defined in RFC 1034 and described in the section entitled "DNS Query Message Format," earlier in this chapter. Network Monitor trace 17-1 (Capture 17-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 IdentifierSet to a unique number so that the resolver can match the response to the query
• FlagsSet to indicate a standard query, with recursion if necessary
• Question CountSet to 1
• Question EntrySet 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 17-1 (Capture 17-01, included in the Captures folder on the companion CD-ROM) displays an example of a query response in which the following fields are set:

• Query IdentifierSet to the unique number set in the query, to allow the resolver to match the response to the original query
• FlagsSet to indicate a response and a successful lookup
• Question CountSet to 1
• Answer CountSet to 1
• Question EntrySet to the question contained in the query message
• Answer EntryThe RR requested in the query (the host record, containing the IP address of the queried domain)

Network Monitor trace 17-3 (Capture 17-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 is no host A RR for this name, but there is an alias (CNAME). In the response, the replying DNS server returns two RRs: the CNAME RR, as well as the A RR 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 constructs a domain name in the in-addr.arpa domain based on the IP address that is being queried.
• The queried record is a PTR record, rather than an A record.

The Reverse Name Query Response message is also the same as a Query Response message, except that a PTR record, rather than a host record, is returned. A reverse lookup can be seen in Network Monitor trace 17-2, shown earlier in this chapter. 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 Response 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 in the section entitled "DNS Update Message Format," earlier in this chapter. Network Monitor trace 17-4 shows an example of a Name Update message. In this update, the key update message fields are set as follows:

• Query IdentifierLike query messages, update messages contain an identifier to enable the sender to match the response to the original update.
• FlagsSet to indicate a request and a dynamic update.
• Update ZoneSet to 1, and the zone section contains the zone to be updated.
• Prerequisites ZoneSet to 2, with two prerequisite records specified.
• Update ZoneContains the RR that is to be updated.

Name Update Response Message

A Name Update Response message is issued in response to a Name Update Request. Network Monitor trace 17-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 Microsoft Windows NT networks that used NetBIOS names and WINS for most domain operations, and as the basis of file and print sharing. DNS is now a key component in Windows Server 2003 networks and is required in those networks that deploy Windows Server 2003 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 contained on the companion CD-ROM for further study.