Networking

Understanding how DNS works, part 2

In this installment of his series of Daily Drill Downs on DNS, Jim Boyce explains reverse lookup, DNS delegation, and forwarders, cachers, and slaves.


In “Understanding how DNS works, part 1,” I explained forward lookup, which maps DNS names to IP addresses. Here’s a refresher: Forward looking occurs when your browser tries to connect to www.techrepublic.com and your client resolver communicates with one or more DNS servers to translate www.techrepublic.com into an IP address. The browser then connects to that IP address and the site appears on your screen.

In this Daily Drill Down, I’ll dig a little deeper into how DNS works. I’ll discuss reverse lookup, DNS delegation, and forwarders, cachers, and slaves.

Reverse lookup
Reverse lookup, also called a reverse query, maps a known IP address to its hostname. Reverse lookup is commonly used to provide security for connections based on the connecting client’s hostname. Reverse lookup is also sometimes used when gathering information about a range of IP addresses, such as building a database of hostnames in the range.

The mechanism that makes forward lookup possible just isn’t practical for reverse lookup. Imagine you know a phone number and need to look up who owns that number. You open a phone book with several hundred million listings—none of which are sorted—and start looking for the number to match it with a name. After several million years, you’ll probably give up and start looking for a better method.

Using the standard forward lookup zones for a reverse resolution simply wouldn’t work, because it would require a full search of the entire DNS name space. DNS resolves that problem by creating a name space of IP addresses, with the in-addr.arpa domain serving as the root for reverse lookup. Here’s how it works: Each IP address consists of four octets separated by periods, such as 205.219.128.93. Each octet is delegated as a subdomain in in-addr.arpa. At the first level is n.in-addr.arpa, where n is a number from 0 to 255 that represents the leftmost octet of the address. Directly below this domain are 256 domains, each representing the possible values for the second octet in the address. Under each of these domains are 256 other subdomains, each representing the third octet of the address. Using the IP address above as an example, the reverse lookup zone would be 128.219.205.in-addr.arpa. Figure A illustrates the in-addr.arpa domain structure.

Figure A
The in-addr.arpa domain provides a hierarchical structure for reverse lookup.


A hostname runs from least significant to most significant, right to left, with the hostname followed by the domain name. Forward name resolution works from right to left, or most significant to least significant. Let’s take an imaginary host, joe.support.techrepublic.com, as an example. A forward resolution of that hostname to its IP address starts in the com domain, moves through the techrepublic subdomain, and then to the support subdomain, where the hostname, joe, is resolved to its IP address.

Reverse lookup happens in much the same way, running from right to left, or most significant to least significant. Using the address 205.219.128.93 (whose reverse lookup domain is 128.219.205.in-addr.arpa) as an example, the reverse lookup starts in the in-addr.arpa root domain, moves to the 205 subdomain, then to 219, and then to 128, where the PTR record for .93 is used to identify the hostname.

In many cases, you won’t need to worry about who manages the reverse lookup zones, since most are handled by ISPs such as AT&T, Cable and Wireless, and so forth. Usually your only concern for reverse lookup zones is creating your subdomain zones on your local DNS servers. Creating reverse lookup zones is essentially the same as creating forward lookup zones. The only real difference is in how the zone gets populated with records. You’ll rely on the DNS service to add the records automatically rather than create them yourself.

DNS delegation
DNS delegation is another DNS twist you’ll likely run across if your network is a large one or you have offices located in different geographic areas that are all part of your enterprise network. Delegation is an integral part of DNS, and in fact, the feature that makes DNS a distributable name space. Through delegation, a domain can be divided into subdomains. Nearly every domain in the com domain, for example, is delegated. The records for techrepublic.com don’t reside with the com root servers, but instead reside on the techrepublic.com name servers. The techrepublic.com domain, in effect, has been delegated by the com domain to techrepublic.com’s name servers.

To the average administrator, however, delegation is more meaningful if you look at a large company domain that needs to be subdivided. For example, assume techrepublic.com includes the support domain name support.techrepublic.com, which is managed by the Support department. The support staff even maintains its own name server. The support subdomain is therefore delegated to that name server.

Another great example of delegation is the us domain, which comprises public entities in the United States, including municipalities, public schools, and so forth. For example, the k12.tx.us domain comprises public schools kindergarten through 12th grade in Texas. Each district’s domain is delegated either to the district or the district’s ISP to manage.

The first benefit delegation offers is load balancing and load reduction. If the root server for the com domain had to host every zone for every com subdomain, the root server would have to be a supercomputer with a massively fast Internet connection to service all the queries thrown its way. Would you want to be the system administrator responsible for managing that server?

The other benefit to delegation is that it makes possible the decentralization of the DNS name space. Each subdomain can manage its own portion of the name space and the records that go along with it. Figure B illustrates delegation.

Figure B
Delegation allows for decentralization of the DNS name space.


Caching, forwarders, and slaves
To improve performance and reduce the load on DNS servers, DNS provides for caching of resolution queries. Caching also helps reduce network traffic. A name server caches the results of a given query for a period of time specified by the server’s administrator. When a query comes in, the server checks its local cache for the name, and if a match is found, the server returns the results from the cache rather than performing a lookup again. If the name hasn’t been queried against that server before, or it has been flushed from the cache, the server takes the action necessary to resolve the name.

Servers can cache successful and unsuccessful queries, the latter being termed negative caching. As with successful queries, negative queries are cached with a specified timeout period. As long as the queried name exists in the cache, the server fails the lookup to the client resolver.

Caching-only servers help reduce network traffic in two ways. First, because they host no zones, caching-only servers help reduce zone transfers (the transfer of zone data from primary to secondary DNS servers). No zones equals no zone transfers to or from those servers. Second, the caching-only server reduces network traffic past the server, since (ideally) most queries can be handled from the cache rather than re-executed. The server’s cached is flushed when the server restarts, so the most effective caching-only server is one that has been running for an extended period.

Forwarders
A DNS server generally attempts to resolve a query against its local cache and zone files. Failing that, the DNS server queries one or more other name servers to resolve the query. In some cases, you might not want every name server in your organization to have free rein to query at will with the outside world. There might be security considerations, bandwidth restrictions, or other reasons. In such a situation, you might prefer to have one name server designated to communicate with the outside world and all other name servers forward their requests through the designated server.

For example, assume your network includes three name servers. Two, A and B, are internal to the network, and the third, C, resides outside a firewall and is connected to the Internet. A and B try to resolve queries against their local zone files and caches, and failing that, send all their queries for outside addresses through C, which acts as a forwarder. Server C sends out queries as needed and returns the results to the internal name servers, which cache the results for later use.

Slaves
A name server can interact with a forwarder in either non-exclusive or exclusive mode. In non-exclusive mode, the server attempts to resolve against its own zone files and cache. If that fails, the server sends a request to its designated forwarder. If the forwarder fails the lookup, the local server attempts to resolve the query on its own by communicating with other name servers.

When a server operates in exclusive mode with a forwarder, it’s called a slave. The slave receives a query from a client and tries to resolve it against its own zone files and cache. If that fails, it submits the query to the designated forwarder. If the forwarder fails the request, the slave fails the query to the client and doesn’t attempt to resolve the request in any other way. A caching-only slave works in much the same way, except it doesn’t host any of its own zone files. If it can’t handle a query from its cache, it passes the query on to the designated forwarder and takes no further action on the query, relying on the forwarder to either fail or resolve the query to the client.

Recursion, iteration, and referrals
If you’re tasked with setting up a DNS server, you should understand some more of the methods by which name resolution occurs. DNS employs two primary methods for name resolution: recursion and iteration (also known as non-recursive). Figure C shows a recursive query. The client resolver sends a recursive query to server A for joe.support.techrepublic.com. Server A queries the root server B. Server B responds with a referral to C, which hosts the primary zone for techrepublic.com. Server C responds with a referral to D, where the support subdomain is delegated. D responds with the requested host record. In this recursive query, the server continues to query others until it gets a definitive answer, doing most of the work to resolve the query.

Figure C
A recursive query puts most of the load on the name server.


An iterative query, on the other hand, results in the client doing most of the work. As Figure D shows, the client resolver sends the request to the name server. The server returns a result if it resides in the server’s cache, and if not, the server returns a referral, expecting the client resolver to use the information to resolve the query on its own through other name servers. The client sends a request to server B, gets a referral to C, submits to C, gets another referral, and ultimately gets a resolution from D.

Figure D
An iterative query puts most of the load on the client.


Iterative queries help reduce the load on any given name server, since the client handles the majority of the load. But this means the client resolver has to be designed to perform iterative queries, which takes a little more “smarts” than a dumb resolver. Recursive queries can put a heavy load on a name server, so you might decide to configure at least some of your name servers to disable recursive queries. If you have a name server that is meant only to handle resolution for the LAN or your WAN, you might consider disabling recursion to prevent it from attempting to resolve queries outside its area of responsibility.

Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and co-authored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota WebWorks, a Midwest-based Web development firm.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox