Lesson 1: Name Resolution and DNS Files | MCSE Training Kit(c) Microsoft Windows 2000 Accelerated 2000

There are three types of queries that a client (resolver) can make to a DNS server: recursive, iterative, and inverse. Servers store their DNS information in four possible files: database, reverse lookup, cache, and boot.

After this lesson, you will be able to

Explain how recursive, iterative, and inverse queries work
Explain how queries are placed in a cache for future requests

Estimated lesson time: 10 minutes

Recursive Queries

In a recursive query, a client requests the DNS server for one of the following:

Data of some sort
An error stating that data of the requested type does not exist
A response stating that the domain name specified does not exist

In a recursive query, the name server cannot refer the request to a different DNS server (sometimes called a name server).

Iterative Queries

In an iterative query, the queried name server gives the best answer it currently has to the requester. This answer may be the resolved name or a referral to another name server that may be able to answer the client's original request.

Figure 10.1 shows recursive and iterative queries. In this example, a client within a corporation is querying its DNS server for the IP address for www.microsoft.com.

Figure 10.1 Recursive and iterative queries

The resolver sends a recursive DNS query to its local DNS server asking for the IP address of www.microsoft.com. The local name server is responsible for resolving the name and cannot refer the resolver to another name server.
The local name server checks its zones and finds no zones corresponding to the requested domain name. It then sends an iterative query for www.microsoft.com to a root name server.
The root name server has authority for the root domain and replies with the IP address of a name server for the .com top-level domain.
The local name server sends an iterative query for www.microsoft.com to the com name server.
The com name server replies with the IP address of the name server servicing the microsoft.com domain.
The local name server sends an iterative query for www.microsoft.com to the microsoft.com name server.
The microsoft.com name server replies with the IP address corresponding to www.microsoft.com.
The local name server sends the IP address of www.microsoft.com back to the original resolver.

Inverse Queries

In an inverse query, the resolver sends a request to a name server to resolve the host name associated with a known IP address. There is no correlation between host names and IP addresses in the DNS name space. Therefore, only a thorough search of all domains guarantees a correct answer.

To prevent an exhaustive search of all domains for an inverse query, a special domain called in-addr.arpa was created. Nodes in the in-addr.arpa domain are named after the numbers in the dotted-decimal representation of IP addresses. Because IP addresses get more specific from left to right and domain names get less specific from left to right, the order of IP address octets must be reversed when building the in-addr.arpa domain. With this arrangement, administration of lower levels of the in-addr.arpa domain can be delegated to organizations as they are assigned their class A, B, or C IP addresses.

Once the in-addr.arpa domain is built, special resource records called pointer (PTR) records are added to associate the IP addresses and the corresponding host name. For example, to find a host name for the IP address 157.55.200.51, the resolver queries the DNS server for a PTR record for 51.200.55.157.inaddr.arpa. The PTR record found contains the host name and corresponding IP address 157.55.200.51. This information is sent back to the resolver. Part of the administration of a DNS name server is ensuring that PTR records are created for hosts.

Caching and Time to Live

When a name server is processing a recursive query, it may be required to send out several queries to find the answer. The name server caches all of the information it receives during this process for a time that is specified in the returned data. This amount of time is referred to as the Time to Live (TTL). The name server administrator of the zone that contains the data decides on the TTL for the data. Smaller TTL values help ensure that data about the domain is more consistent across the network if this data changes often. However, this also increases the load on name servers.

Once data is cached by a DNS server, it must start decreasing the TTL from its original value so that it will know when to flush the data from its cache. If a query comes in that can be satisfied by this cached data, the TTL that is returned with the data is the current amount of time left before the data is flushed from the DNS server cache. Client resolvers also have data caches and honor the TTL value so that they know when to expire the data.

DNS Configuration Files

The DNS is a hierarchical, distributed database. The database itself consists of resource records, which primarily consist of a DNS name, a record type, and data values that are associated with that record type. For example, the most common records in the DNS database are address records, where the name of an address record is the name of a computer, and the data in the record is the TCP/IP address of that computer.

In a Domain Name System (DNS) database, a zone is a subtree of the DNS database that is administered as a single separate entity, a DNS server. This administrative unit can consist of a single domain or a domain with subdomains. A DNS zone administrator sets up one or more name servers for the zone.

To resolve names, servers consult their zones (also called DNS database files, or simply db files). The zones contain resource records (RRs) that make up the resource information associated with the DNS domain. For example, some RRs map friendly names to IP addresses, and others map IP addresses to friendly names.

Start of Authority Record

The first record in any database file must be the start of authority (SOA) record. The SOA defines the general parameters for the DNS zone. The following is an example of an SOA record:

 @   IN  SOA     nameserver.example.microsoft.com. postmaster.example.microsoft.com. (                          1            ; serial number                          3600         ; refresh   [1h]                          600          ; retry     [10m]                          86400        ; expire    [1d]                          3600 )       ; min TTL   [1h]

The following rules apply to all SOA records:

The at symbol (@) in a database file indicates "this server."
IN indicates an Internet record.
Any host name that does not end with a period (.) is appended with the root domain.
The @ symbol is replaced by a period (.) in the e-mail address of the administrator.
Parentheses ( () ) must enclose line breaks that span more than one line.

Name Server Record

The name server (NS) record lists the additional name servers. A database file may contain more than one NS record. The following is an example of an NS record:

 @ IN NS nameserver2.microsoft.com

Host Record

A host address (A) resource record statically associates a host name to its IP address. Host records comprises most of the database file and list all hosts within the zone. The following are examples of host records:

 rhino     IN A 157.55.200.143 localhost     IN A 127.0.0.1

CNAME Record

A canonical name (CNAME) record enables you to associate more than one host name with an IP address. This is sometimes referred to as aliasing. The following is an example of a CNAME record:

 FileServer1     CNAME rhino www     CNAME rhino ftp     CNAME rhino

The Reverse Lookup File

The reverse lookup file (z.y.x.w.in-addr.arpa) allows a resolver to provide an IP address and request a matching host name. A reverse lookup file is named like a zone file according to the in-addr.arpa zone for which it provides reverse lookups. For example, to provide reverse lookups for the IP network 157.57.28.0, a reverse lookup file is created with a file name 57.157.in-addr.arpa. This file contains SOA and NS records similar to other DNS database zone files, as well as PTR records.

This DNS reverse lookup capability is important because some applications provide the capabilities to implement security based on the connecting host names. For instance, if a browser sends a request to an Internet Information Server (IIS) Web server with this security arrangement, the Web server would contact the DNS server and do a reverse name lookup on the client's IP address. If the host name returned by the DNS server is not in the access list for the Web site or if the host name was not found by DNS, the request would be denied.

NOTE
Windows 2000 does not require reverse lookup zones to be configured. However, reverse lookup zones might be necessary for some applications that are installed later or for administrative convenience.

The PTR Record

PTR records provide address-to-name mapping within a reverse lookup zone. IP numbers are written in backward order and "in-addr.arpa" is appended to the end to create this PTR record. As an example, looking up the name for 157.55.200.51 requires a PTR query for the name 51.200.55.157.in-addr.arpa. An example might read

 51.200.55.157.in-addr.arpa. IN PTR  mailserver1.microsoft.com.

The Cache File

The CACHE.DNS file contains the records of the root domain servers. The cache file is essentially the same on all name servers and must be present. When the name server receives a query outside its zone, it starts resolution with these root domain servers. An example entry might read

 .     3600000     IN     NS     A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET.     3600000     A          198.41.0.4

The cache file contains host information that is needed to resolve names outside of authoritative domains, and also contains names and addresses of root name servers. The default file provided with the Windows 2000 DNS Server has the current records for all of the root servers on the Internet, and is stored in the %systemroot%\System32\Dns folder. For installations not connected to the Internet, the file should be replaced to contain the name server's authoritative domains for the root of the private network.

The Boot File

The boot file is the startup configuration file on the Berkeley Internet Name Daemon_specific implementation of DNS. This file contains host information needed to resolve names outside of authoritative domains. The file is not defined in a Request for Comments (RFC) and is not needed to be RFC-compliant. It is supported by Windows 2000 to improve compatibility with traditional, UNIX-based DNS services. The Berkeley Internet Name Daemon boot file controls the startup behavior of the DNS server. Commands must start at the beginning of a line and no spaces can precede commands. Table 10.1 provides descriptions of some of the boot file commands supported by Windows 2000.

Table 10.1 Windows 2000 Boot File Commands

Command	Description
Directory command	Specifies a directory where other files referred to in the boot file can be found.
Cache command	Specifies a file used to help the DNS service contact name servers for the root domain. This command and the file it refers to must be present. A cache file suitable for use on the Internet is provided with Windows 2000.
Primary command	Specifies a domain for which this name server is authoritative and a database file that contains the resource records for that domain (that is, the zone file). Multiple primary command records can exist in the boot file.
Secondary command	Specifies a domain for which this name server is authoritative and a list of master server IP addresses from which to attempt to download the zone information, rather than reading it from a file. It also defines the name of the local file for caching this zone. Multiple secondary command records could exist in the boot file.

Table 10.2 shows examples of the commands in a boot file.

Table 10.2 Examples of Boot File Commands

Syntax	Example
directory [directory]	directory c:\winnt\system32\dns
cache.[file_name]	cache.cache
primary [domain] [file_name]	primary microsoft.com.microsoft.dns primary dev.microsoft.com dev.dns
secondary [domain] [hostlist] [local_file_name]	secondary test.microsoft.com 157.55.200.100 test.dns

Lesson Summary

When clients need to resolve a host name or IP address, they can make one of three queries to DNS servers: recursive, iterative, or inverse. A DNS server only returns the information it has in cache. It may return information about the potential of an error when a client makes a recursive query. A more typical query is an iterative query. When a client makes an iterative query, the DNS server returns the requested information or provides the client with an alternative DNS server that provides the correct information. An inverse query requests reverse lookup information. If a DNS client needs a host name resolved from a known IP address, an inverse query is sent to the DNS server.

DNS servers store their name and configuration information in four files: database, reverse lookup, cache, and boot files.