Chapter 8 - Domain Name System Overview

Artikel
08/31/2011

Abstract

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

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this chapter that has been updated for Windows Vista and Windows Server 2008, click here.

Chapter Objectives

After completing this chapter you will be able to:

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

The Domain Name System

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

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

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

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

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

DNS Components

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

The domain namespace and resource records

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

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

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

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

DNS Names

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

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

Domains and Subdomains

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

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

Figure 8-1 The DNS namespace

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

DNS Servers and the Internet

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

Root domain
Top-level domains
Second-level domains

The root domain uses a null label, which you write as a single period (.). In the United States, the Internet Assigned Names Authority (IANA) manages several root domain name servers.

The next level in the hierarchy is divided into a series of nodes called the top-level domains. The top-level domains are assigned by organization type and by country/region. Some of the more common top-level domains are the following:

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

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

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

Zones

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

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

Figure 8-2 Domains and zones

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

Name Resolution

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

Recursive queries

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

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

DNS Name Resolution Example

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

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

Figure 8-3 shows this process.

Figure 8-3 Example of recursive and iterative queries in DNS name resolution

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

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

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

Reverse Queries

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

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

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

Reverse Queries for IPv4 Addresses

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

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

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

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

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

Reverse Queries for IPv6 Addresses

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

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

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

Caching and TTL

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

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

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

Negative Caching

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

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

Round Robin Load Balancing

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

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

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

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

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

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

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

Name Server Roles

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

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

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

Primary

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

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

The following are reasons to have secondary name servers within an enterprise network:
- Redundancy: At least two DNS servers, a primary and at least one secondary, serving each zone are needed for fault tolerance.
- Remote locations: Secondary name servers (or other primary servers for subdomains) are needed in remote locations that have a large number of DNS clients. Clients should not have to communicate across slower wide area network (WAN) links for DNS queries.
- Load distribution: Secondary name servers reduce the load on the primary name server.

Because information for each zone is stored in separate files, the primary or secondary name server designation is defined at a zone level. In other words, a specific name server may be a primary name server for certain zones and a secondary name server for other zones.

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

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

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

Forwarders

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

Figure 8-6 shows an example of intranet servers using a forwarder to resolve Internet names.

Figure 8-6 Using a forwarder to resolve Internet names

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

Forwarders in Non-exclusive Mode

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

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

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

Forwarders in Exclusive Mode

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

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

Checks its local cache.
Checks its zone files.
Sends a recursive query to a forwarder.

Caching-Only Name Servers

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

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

Resource Records and Zones

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

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

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

Resource Record Format

Resource records have the following format:

owner TTL type class RDATA

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

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

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

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

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

Resource Record Types

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

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

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

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

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

For detailed information about the structure and contents of various types of DNS resource records, including examples, see DNS Reference Information.

Delegation and Glue Records

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

That a separate zone for that domain exists.

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

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

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

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

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

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

The Root Hints File

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

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

Zone Transfers

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

Full Zone Transfer

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

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

The secondary server sends an AXFR request (a request for a full zone transfer) to the master server.
The secondary server initiates a TCP connection with the master server and requests all of the records in the zone database. After the zone transfer, the Serial Number field in the SOA record of the local zone file matches the Serial Number field in the SOA record of the master server.

Figure 8-7 shows a full zone transfer.

Figure 8-7 A full zone transfer

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

Incremental Zone Transfer

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

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

Figure 8-8 shows an incremental zone transfer.

Figure 8-8 An incremental zone transfer

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

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

DNS Notify

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

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

Figure 8-9 shows the DNS notify process.

Figure 8-9 The DNS notify process

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

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

DNS Dynamic Update

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

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

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

Chapter Summary

The chapter includes the following pieces of key information:

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

Chapter Glossary

DNS – See Domain Name System (DNS).

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

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

domain – Any branch of the DNS namespace.

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

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

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

FQDN – See fully qualified domain name.

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

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

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

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

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

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

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

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

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

root domain - The beginning of the DNS namespace.

secondary server - A DNS server that is authoritative for a zone and that obtains its zone information from a master server.

second-level domain – A DNS domain name that is rooted hierarchically at the second tier of the domain namespace, directly beneath the top-level domain names. Top-level domain names include .com and .org. When DNS is used on the Internet, second-level domains are names that are registered and delegated to individual organizations and businesses.

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

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

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

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

Freigeben über