For TCP/IP systems to use these friendly host names, they must have a way to discover the IP address associated with the name. In the early days of TCP/IP networking, each computer had a list of names and their equivalent IP addresses, called a host table. At that time, the small number of computers on the fledgling Internet made the maintenance and distribution of a single host table practical.
Today, there are millions of computers on the Internet, and the idea of maintaining and distributing a single file containing names for all of them is absurd. Instead of using the host table stored on every computer, TCP/IP networks today use DNS servers to convert host names into IP addresses. This conversion process is referred to as name resolution.
At its core, the DNS is still a list of names and their equivalent IP addresses, but the methods for creating, storing, and retrieving those names are very different from those in a host table. DNS consists of three elements:
– The DNS namespace The DNS standards define a tree-structured namespace in which each branch of the tree identifies a domain. Each domain contains a collection of resource records that contain host names, IP addresses, and other information. Query operations are attempts to retrieve specific resource records fr om a particular domain.
– Name servers A DNS server is a service running on a server computer that maintains information about the domain tree structure and (sometimes) contains authoritative information about one or more specific domains in that structure. The application is capable of responding to queries for information about the domains for which it is the authority and also of forwarding queries about other domains to other name servers. This enables any DNS server to access information about any domain in the tree.
– Resolvers A resolver is a client program that generates DNS queries and sends them to a DNS server for fulfillment. A resolver has direct access to at least one DNS server and can also process referrals to direct its queries to other servers when necessary.
In its most basic form, the DNS name resolution process consists of a resolver submitting a name resolution request to its designated DNS server. When the server does not possess information about the requested name, it forwards the request to another DNS server on the network. The second server generates a response containing the IP address of the requested name and returns it to the first server, which relays the information to the resolver, as shown in Figure 1. In practice, however, the DNS name resolution process can be considerably more complex, as you will learn in the following sections.
Although all Internet applications use DNS to resolve host names into IP addresses, this name resolution process is easiest to see when you’re using a web browser to access an Internet site. When you type a URL containing a DNS name (for example, www.microsoft.com) into the browser’s Address box and press the Enter key, if you look quickly enough, you might be able to see a message that says something like “Finding Site: www.microsoft.com.” Then, a few seconds later, you might see a message that says “Connecting to,” followed by an IP address.
It is during this interval that the DNS name resolution process occurs. From the client’s perspective, the procedure that occurs during these few seconds consists of the application using the built-in DNS resolver to send a query message to its designated DNS server that contains the name to be resolved. The server then replies with a message containing the IP address corresponding to that name. Using the supplied address, the application can then transmit a message to the intended destination. It is only when you examine the DNS server’s role in the process that you see how complex the procedure really is.
To better explain the relationships among the DNS servers for various domains in the namespace, the following procedure diagrams the Internet name resolution process.
1. A user on a client system specifies the DNS name of an Internet server in an application such as a web browser. The application generates an application programming interface (API) call to the resolver on the client system and the resolver creates a DNS recursive query message containing the server name, which it transmits to the DNS server identified in computer’s TCP/IP configuration, as shown in Figure 2.
2. The client’s DNS server, after receiving the query, checks its resource records to see if it is the authoritative source for the zone containing the requested server name. If it is not, which is typical, the DNS server generates an iterative query and submits it to one of the root name servers, as shown in Figure 3. The root name server examines the name requested by the client’s DNS server and consults its resource records to identify the authoritative servers for the name’s top-level domain. The root name server then transmits a reply to the client’s DNS server that contains a referral to the top-level domain server IP addresses.
3. The client’s DNS server, now in possession of the top-level domain server address for the requested name, generates a new iterative query and transmits it to the top-level domain server, as shown in Figure 4. The top-level domain server examines the second-level domain in the requested name and transmits a referral containing the addresses of authoritative servers for that second-level domain back to the client’s DNS server.
NOTE: COMBINING STEPS
In the DNS name resolution process just described, the process of resolving the top-level and second-level domain names is portrayed in separate steps. However, this is often not the case. The most commonly used top-level domains (such as com, net, and org) are actually hosted by the root name servers. This eliminates one referral from the name resolution process.
4. The client’s DNS server generates another iterative query and transmits it to the second-level domain server, as shown in Figure 5. If the second-level domain server is the authority for the zone containing the requested name, it consults its resource records to determine the IP address of the requested system and transmits it in a reply message back to that client’s DNS server.
5. The client’s DNS server receives the reply from the authoritative server and transmits the IP address back to the resolver on the client system, as shown in Figure 5. The resolver relays the address to the application, which can then initiate IP communications with the system specified by the user.
Depending on the name the client is trying to resolve, this process can be simpler or considerably more complex than the one shown here. On one hand, if the client’s DNS server is the authority for the domain in which the requested name is located, no other servers or iterative requests are necessary. On the other hand, if the requested name contains three or more levels of domains, additional iterative queries might be necessary.
This procedure also assumes a successful completion of the name resolution procedure. If any of the authoritative DNS servers queried returns an error message to the client’s DNS server stating, for example, that one of the domains in the name does not exist, then this error message is relayed back to the client and the name resolution process is said to have failed.
DNS server caching
The DNS name resolution process might seem long and complex, but in many cases it isn’t necessary for the client’s DNS server to send queries to the servers for each domain specified in the requested DNS name. This is because DNS servers are capable of retaining the information they learn about the DNS namespace in the course of their name resolution procedures and storing it in a cache on the local hard drive.
A DNS server that receives requests from clients, for example, caches the IP addresses of the requested systems and the addresses for authoritative servers of particular domains. The next time a client requests the resolution of a previously resolved name, the server can respond immediately with the cached information. In addition, if a client requests anothername in one of the same domains, the server can send a query directly to an authoritative server for that domain rather than to a root name server. Thus, the names in commonly
accessed domains generally resolve quickly because one of the servers along the line has information about the domain in its cache, whereas names in obscure domains take longer, because the entire request/referral process is needed.
Caching is a vital element of the DNS architecture because it reduces the number of requests sent to the root name and top-level domain servers, which, being at the top of the DNS tree, are the most likely to act as a bottleneck for the whole system. However, caches must be purged eventually, and there is a fine line between effective and ineffective caching.
Because DNS servers retain resource records in their caches, it can take hours or even days for changes made in an authoritative server to be propagated around the Internet. During this period, users might receive incorrect information in response to a query. If information remains in server caches too long, then the changes administrators make to the data in their DNS servers take too long to propagate around the Internet. If caches are purged too quickly, then the number of requests sent to the root name and top-level domain servers increases precipitously.
The amount of time that DNS data remains cached on a server is called its time to live (TTL). Unlike most data caches, the TTL is not specified by the administrator of the server where the cache is stored. Instead, the administrators of each authoritative DNS server specify how long the data for the resource records in their domains or zones should be retained in the servers where it is cached. This enables administrators to specify a TTL value based on the volatility of their server data. On a network where changes in IP addresses or the addition of new resource records is frequent, a lower TTL value increases the likelihood that clients
will receive current data. On a network that rarely changes, a longer TTL value minimizes the number of requests sent to the parent servers of your domain or zone.
To modify the TTL value for a zone on a Windows Server 2012 R2 DNS server, right-click the zone, open the Properties sheet, and click the Start Of Authority (SOA) tab, as shown in Figure 7. On this tab, you can modify the TTL for this record setting from its default value of one hour.
Client-side resolver caching
The client resolver on Windows systems also contains a caching mechanism, which stores resolved IP addresses and also HOSTS file information on a local drive. When a client enounters a name that needs to be resolved into an IP address, it checks its local cache first, before sending a request to its DNS server.
DNS referrals and queries
The process by which one DNS server sends a name resolution request to another DNS server is called a referral. Referrals are essential to the DNS name resolution process.
As you noticed in the process described earlier, the DNS client’s primary involvement in the name resolution process is sending one query and receiving one reply. The client’s DNS server might have to send referrals to several servers before it reaches the one that has the information it needs.
DNS servers recognize two types of name resolution requests, as follows:
– Recursive query In a recursive query, the DNS server receiving the name resolution request takes full responsibility for resolving the name. If the server possesses information about the requested name, it replies immediately to the requestor. If the server has no information about the name, it sends referrals to other DNS servers until it obtains the information it needs. TCP/IP client resolvers always send recursive queries
to their designated DNS servers.
– Iterative query In an iterative query, the server that receives the name resolution request immediately responds with the best information it possesses at the time. DNS servers use iterative queries when communicating with each other. In most cases, it would be improper to configure one DNS server to send a recursive query to another
DNS server. The only time a DNS server sends recursive queries to another server is in the case of a special type of server called a forwarder, which is specifically configured to interact with other servers in this way.
One of the scenarios in which DNS servers send recursive queries to other servers is when you configure a server to function as a forwarder. On a network running several DNS servers, you might not want all the servers sending queries to other DNS servers on the Internet. If the network has a relatively slow connection to the Internet, for example, several servers transmitting repeated queries might use too much of the available bandwidth.
To prevent this, the Windows Server 2012 R2 DNS server enables you to configure one server to function as the forwarder for all Internet queries generated by the other servers on the network. Any time a server has to resolve the DNS name of an Internet system and fails to find the needed information in its cache, it transmits a recursive query to the forwarder, which is then responsible for sending its own iterative queries over the Internet connection. Once the forwarder resolves the name, it sends a reply back to the original DNS server, which relays it to the client.
To configure forwarders on a Windows Server 2012 R2 DNS server, right-click the server node, open the Properties sheet, and click the Forwarders tab, as shown in Figure 8. On this tab, you can add the names and addresses of the servers that you want your server to use as forwarders.
The Windows Server 2012 R2 DNS server also supports conditional forwarding, which enables administrators to specify different server IP addresses for specific domain names. When the server receives a name resolution request, it checks the domain name in the request against its list of forwarders and passes the request to another server only if the domain appears in the list. By using this feature, organizations with multiple internal domains can resolve names throughout the enterprise without having to send requests to servers on
Reverse name resolution
The name resolution process described earlier is designed to convert DNS names into IP addresses. However, there are occasions when it is necessary for a computer to convert an IP address into a DNS name. This is called a reverse name resolution.
Because the domain hierarchy is organized according to domain names, there is no apparent way to resolve an IP address into a name by using iterative queries, except by forwarding the reverse name resolution request to every DNS server on the Internet in search of the requested address, which is obviously impractical.
To overcome this problem, the developers of the DNS created a special domain called in-addr.arpa, specifically designed for reverse name resolution. The in-addr.arpa secondlevel domain contains four additional levels of subdomains. Each of the four levels consists of subdomains that are named using the numerals 0 to 255. For example, beneath in-addr.arpa, there are 256 third-level domains, which have names ranging from 0.in-addr.arpa to 255.in-addr.arpa. Each of those 256 third-level domains has 256 fourth-level domains beneath it, also numbered from 0 to 255, and each fourth-level domain has 256 fifth-level domains,
as shown in Figure 9. Each of those fifth-level domains can have up to 256 hosts in it, also numbered from 0 to 255.
By using this hierarchy of subdomains, it is possible to express the first three bytes of an IP address as a DNS domain name and to create a resource record named for the fourth byte in the appropriate fifth-level domain. For example, to resolve the IP address 192.168.89.34 into a name, a DNS server would locate a domain called 89.168.192.in-addr.arpa in the usual manner and read the contents of a resource record named 34 in that domain.
NOTE: REVERSE LOOKUP ADDRESSES
In the in-addr.arpa domain, the IP address is reversed in the domain name because IP addresses have the least pertinent bit (that is, the host identifier) on the right, but DNS fully qualified domain names (FQDNs) have the host name on the left.