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
Estimated lesson time: 10 minutes
In a recursive query, a client requests the DNS server for one of the following:
In a recursive query, the name server cannot refer the request to a different DNS server (sometimes called a name server).
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
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.
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.
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.
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 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
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
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 (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.
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.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 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 |
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.