Understanding DNS in Windows Server 2003 Networks

Exploring DNS

DNS allows people and programs to connect to IP hosts by specifying a name such as ftp.lucernepublishing.com. In doing so, DNS provides a standard both for naming hosts and for locating IP hosts specified by name.

DNS Namespace

The naming system on which DNS is based is a hierarchical and logical tree structure called the DNS namespace. The DNS namespace has a unique root that can have any number of subdomains. In turn, each subdomain can have more subdomains. For example, the root “” (empty string) in the Internet namespace has many top-level domain names, one of which is com. The domain com can, for example, have a subdomain for the Lucerne Publishing company, lucernepublishing.com, which in turn can have a further subdomain for manufacturing, called mfg.lucernepublishing.com. Organizations can also create private networks and use their own private DNS namespaces that are not visible on the Internet.

Domain Names

Every node in the DNS domain tree can be identified by an FQDN. The FQDN is a DNS domain name that has been stated unambiguously to indicate its location relative to the root of the DNS domain tree. For example, the FQDN for the manufacturing server in the lucernepublishing.com domain is constructed as mfgserver.lucernepublishing.com., which is the concatenation of the host name (mfgserver) with the primary DNS suffix (lucernepublishing.com), and the trailing dot (.). The trailing dot is a standard separator between the top-level domain label and the empty string label corresponding to the root. (In everyday usage, the trailing dot is usually dropped, but it is added by the DNS Client service during actual queries.)

Internet Domain Namespace

The DNS root (the topmost level) of the Internet domain namespace is managed by the Internet Corporation for Assigned Names and Numbers (ICANN). ICANN coordinates the assignment of identifiers that must be globally unique for the Internet to function, including Internet domain names, IP address numbers, and protocol parameter and port numbers.

Beneath the root DNS domain lie the top-level domains, also managed by ICANN. Three types of top-level domains exist:

• Organizational domains These domains are named using a three-character code that indicates the primary function or activity of the organizations contained within the DNS domain. Some organizational domains can be used globally, although others are used only for organizations within the United States. Most organizations located in the United States are contained within one of these organizational domains.

• Geographical domains These domains are named using the two-character country and region codes established by the International Organization for Standardization (ISO) 3166, such as uk (United Kingdom) or it (Italy). These domains are generally used by organizations outside the United States, but this is not a requirement.

• Reverse domains These are special domains, named in-addr.arpa, that are used for IP-address-to-name mappings (referred to as reverse lookups).

In November 2000, ICANN announced seven additional top-level domains:

• .aero

• .biz

• .coop

• .info

• .museum

• .name

• .pro

Beneath the top-level domains, ICANN and other Internet naming authorities, such as Network Solutions or Nominet (in the United Kingdom), delegate domains to various organizations such as Microsoft (microsoft.com) or Carnegie Mellon University (cmu.edu). These organizations connect to the Internet, assign names to hosts within their domains, and use DNS servers to manage the name-to-IP-address mappings within their portion of the namespace. These organizations can also delegate subdomains to other users or customers. ISPs, for example, receive a delegation from ICANN and can delegate subdomains to their customers.

Private Domain Namespace

In addition to the top-level domains on the Internet, organizations can also have a private namespace: a DNS namespace based on a private set of root servers independent of the Internet’s DNS namespace. Within a private namespace, you can name and create your own root server or servers and any subdomains as needed. Private names cannot be seen or resolved on the Internet. An example of a private domain name is mycompany.local.

DNS Components

DNS relies on the proper configuration of DNS servers, zones, resolvers, and resource records.

DNS Servers

A DNS server is a computer that runs a DNS server program, such as the DNS Server service or Berkeley Internet Name Domain (BIND). DNS servers contain DNS database information about some portion of the DNS domain tree structure and resolve name resolution queries issued by DNS clients. When queried, DNS servers can provide the requested information, provide a pointer to another server that can help resolve the query, or respond that the information is unavailable or does not exist.

A DNS server is authoritative for a zone if it hosts the zone, either as a primary or secondary DNS server. A server is authoritative for a domain when that server relies on locally configured resource records, as opposed to cached information, to answer queries about hosts within that domain. Such servers define their portion of the DNS namespace.

Servers can be authoritative for one or more levels of the domain hierarchy. For example, the root DNS servers on the Internet are authoritative only for the top-level domain names such as .com and not for subdomains such as lucernepublishing.com. The servers authoritative for .com are authoritative only for names such as lucernepublishing.com, and not for third-level domains such as example.lucernepublishing.com. However, within the Lucerne Publishing namespace, the server or servers authoritative for example.lucernepublishing.com can also be authoritative for widgets.example.lucernepublishing.com.

DNS Zones

A DNS zone is a contiguous portion of a namespace for which a server is authoritative. A server can be authoritative for one or more zones, and a zone can contain one or more contiguous domains. For example, one server can be authoritative for both microsoft.com and lucernepublishing.com zones, and each of these zones can include two or more domains.

Contiguous domains such as .com, lucernepublishing.com, and example.lucernepublishing.com can become separate zones through the process of delegation, by which the responsibility for a subdomain within the DNS namespace is assigned to a separate entity.

Zone files contain resource records for the zones for which a server is authoritative. In many DNS server implementations, zone data is stored in text files; however, DNS servers running on Windows 2000 or Windows Server 2003 domain controllers can also store zone information in Active Directory.

DNS Resolvers

A DNS resolver is a service that uses the DNS protocol to query for information from DNS servers. DNS resolvers communicate with either remote DNS servers or the DNS server program running on the local computer. In Windows Server 2003, the function of the DNS resolver is performed by the DNS Client service. Besides acting as a DNS resolver, the DNS Client service provides the added function of caching DNS mappings.

Resource Records

Resource records are DNS database entries that are used to answer DNS client queries. Each DNS server contains the resource records it needs to answer queries for its portion of the DNS namespace. Resource records are each described as a specific record type, such as host address (A), alias (CNAME), and mail exchanger (MX).

Understanding How a DNS Query Works

When a DNS client needs to look up a name used by an application, it queries DNS servers to resolve the name. Each query message the client sends contains the following three pieces of information:

• A DNS domain name, stated as an FQDN. (The DNS Client service adds the suffixes necessary to generate an FQDN if they are not provided by the original client program.)

• A specified query type, which can specify either a resource record by type or a specialized type of query operation.

• A specified class for the DNS domain name. (For the DNS Client service, this class is always specified as the Internet [IN] class.)

For example, the name could be specified as the FQDN for a particular host computer, such as host-a.example.microsoft.com., and the query type could be specified as a search for an A resource record by that name. You can think of a DNS query as a client asking a server a two-part question, such as, “Do you have any A resource records for a computer named hostname.example.microsoft.com?” When the client receives an answer from the server, the client reads the received A resource record and learns the IP address of the computer name originally queried for.

DNS Resolution Methods

DNS queries resolve in a number of different ways. In a basic scenario, the DNS client contacts a DNS server, which then uses its own database of resource records to answer a query. However, by referring to its cache first, a DNS client can sometimes answer a query without contacting a server at all. Another way that DNS queries are often resolved is through recursion. (See the section “Understanding Recursion” later in this lesson for more information.) Using this process, a DNS server can query other DNS servers on behalf of the requesting client in order to resolve the FQDN. When the DNS server receives the answer to the query, it then sends an answer back to the client. A final method by which DNS queries are resolved is through iteration (also explained in more detail in the “Understanding Recursion” section). Through this process, the client itself attempts to contact additional DNS servers to resolve a name. When a client does so, it uses separate and additional queries based on referral answers from DNS servers.

DNS Query Steps

In general, the DNS query process occurs in two parts:

• A name query begins at a client computer and is passed to the DNS Client service for resolution.

• When the query cannot be resolved locally, DNS servers can be queried as needed to resolve the name.

Both of these processes are explained in more detail in the following sections.

Part 1: The Local Resolver

Figure 1 presents an overview of the default DNS query process, in which a client is configured to make recursive queries to a server. In this scenario, if the DNS Client service cannot resolve the query from locally cached information, the client makes only a single query to a DNS server, which is then responsible for answering the query on behalf of the client.

In the figure, queries and answers are represented by Qs and As, respectively. The higher numbered queries are made only when the previous query is unsuccessful. For example, Q2 is performed only when Q1 is unsuccessful.

The query process begins when a DNS domain name is used in a program on the local computer. In the example shown in Figure 4-1, a Web browser calls the FQDN www.microsoft.com. The request is then passed to the DNS Client service (the DNS resolver cache) to resolve this name by using locally cached information. If the queried name can be resolved, the query is answered and the process is completed.

The local resolver cache can include name information obtained from two possible sources:

• If a Hosts file is configured locally, any host-name-to-address mappings from that file are loaded into the cache when the DNS Client service is started and after the Hosts file is updated.

• Resource records obtained in answered responses from previous DNS queries are added to the cache and kept for a period of time.

If the query does not match an entry in the cache, the resolution process continues with the client querying a DNS server to resolve the name.

Part 2: Querying a DNS Server

The DNS Client service uses a server search list ordered by preference. This list includes all preferred and alternate DNS servers configured for each of the active network connections on the system. The client first queries the DNS server specified as the preferred DNS server in the connection’s Internet Protocol (TCP/IP) Properties dialog box. If no preferred DNS servers are available, alternate DNS servers are used. Figure 2 shows a sample list of preferred and alternate DNS servers, as configured in Windows Server 2003.

When a DNS server receives a query, it first checks to see whether it can answer the query authoritatively—that is, on the basis of information contained in a locally configured zone on the server. If the queried name matches a corresponding resource record in local zone information, the server answers authoritatively, using this information to resolve the queried name.

If no zone information exists for the queried name, the server then checks to see whether it can resolve the name by using locally cached information from previous queries. If a match is found here, the server answers with this information. Again, if the preferred server can answer with a positive matched response from its cache to the requesting client, the query is completed.

Understanding Recursion

If the queried name does not find a matched answer at its preferred server—either from its cache or zone information—the query process continues in a manner dependent on the DNS server configuration. In the default configuration, the DNS server performs recursion to resolve the name. In general, recursion in DNS refers to the process of a DNS server querying other DNS servers on behalf of an original querying client. This process, in effect, turns the original DNS server into a DNS client.

If recursion is disabled on the DNS server, the client performs iterative queries by using root hint referrals from the DNS server. Iteration refers to the process of a DNS client making repeated queries to different DNS servers.

Root Hints

To perform recursion properly, the DNS server first needs to know where to begin searching for names in the DNS domain namespace. This information is provided in the form of root hints, a list of preliminary resource records used by the DNS service to locate servers authoritative for the root of the DNS domain namespace tree.

By default, DNS servers running Windows Server 2003 use a preconfigured root hints file, Cache.dns, that is stored in the WINDOWS\System32\Dns folder on the server computer. The contents of this file are preloaded into server memory when the service is started and contain pointer information to root servers for the DNS namespace. Figure 3 shows the default root hints file.

Figure 3. Root hints file

In Windows Server 2003, the root hints file already contains addresses of root servers in the Internet DNS namespace. Therefore, if you are using the DNS Server service in Windows Server 2003 to resolve Internet-based DNS names, the root hints file needs no manual configuration. If, however, you are using the DNS service on a private network, you can edit or replace this file with similar records that point to your own internal root DNS servers. Furthermore, for a computer that is hosting a root DNS server, you should not use root hints at all. In this scenario, Windows Server 2003 automatically deletes the Cache.dns file used for root hints.

Query Example

The following example illustrates default DNS query behavior. In the example, the client queries its preferred DNS server, which then performs recursion by querying hierarchically superior DNS servers. In the example, the DNS client and all DNS servers are assumed to have empty caches.

In the example shown in Figure 4, a client somewhere on the Internet needs to resolve the name example.lucernepublishing.com to an IP address.

When the DNS Client service on the client computer begins the query process, the following events take place:

Query Response Types

Queries can return a variety of answers to the client, including these, which are the most common:

• An authoritative answer

• A positive answer

• A referral answer

• A negative answer

An authoritative answer is a positive answer returned to the client and delivered with the authority bit set in the DNS message. This authority bit indicates that the answer was obtained from a server with direct authority for the queried name.

A positive answer contains the queried resource record matching the queried name and record type specified in the original query message.

A referral answer contains additional resource records not specified by name or type in the query. This type of answer is returned to the client if the recursion process is not supported by the DNS server. These records are meant to act as helpful reference answers that the client can use to continue the query by using iteration. For example, if the queried host name is “www” and no A resource record but only a CNAME resource record for this name is found in the zone, the DNS server can include this CNAME information when responding to the client. If the client is able to perform iteration, it can make additional queries using this referral information in an attempt to fully resolve the name for itself.

A negative answer from the server can indicate that one of two possible results was encountered while the server attempted to process and recursively resolve the query fully and authoritatively:

• An authoritative server reported that the queried name does not exist in the DNS namespace.

• An authoritative server reported that the queried name exists but no records of the specified type exist for that name.

After the response is made to the query, the resolver passes the results of the query, in the form of either a positive or negative response, back to the requesting program and caches the response.

Understanding How Caching Works

Both the DNS Client service and the DNS Server service maintain caches. Caching provides a way to improve DNS performance and to substantially reduce DNS-related query traffic on the network.

DNS Client Cache

The DNS client cache is also called the DNS resolver cache. Whenever the DNS Client service starts, all host-name-to-IP-address mappings contained in a static file named Hosts are preloaded into the DNS resolver cache. The Hosts file can be found in WINDOWS \System32\Drivers\Etc.

In addition to the entries in the Hosts file, the DNS resolver cache also includes entries the client has received in response to a query from DNS servers. The DNS resolver cache is emptied whenever the DNS Client service is stopped.

DNS Server Cache

As DNS servers make recursive queries on behalf of clients, they temporarily cache resource records. These cached records contain information acquired in the process of answering queries on behalf of a client. Later, when other clients place new queries that request information matching cached resource records, the DNS server can use the cached information to answer these queries.

The DNS server cache is cleared whenever the DNS Server service is stopped. In addition, you can clear the DNS server cache manually in the DNS console—the administrative tool used for DNS administration—by right-clicking the server icon in the console tree and then clicking Clear Cache. Finally, if you have installed Windows Support Tools, you can clear the server cache at the command line by entering the command Dnscmd /clearcache at a command prompt.

Time to Live Values

A Time to Live (TTL) value applies to all cached resource records, whether in the DNS resolver cache or the DNS server cache. As long as the TTL for a cached resource record does not expire, a DNS resolver or server can continue to use that record to answer queries. By default, the TTL is 3600 seconds (1 hour), but this parameter can be adjusted at both the zone and record level.

Note