Deconstructing DNS

My network recently developed an intermittent DNS name-resolution problem. I'd rather do about a dozen other things with my time than hunt down name-resolution bugs, and unfortunately my DNS troubleshooting skills had grown rusty over time. DNS is easy to forget about when it's working like it's supposed to: Everything just works—from your browser, to your email client, to your mail server, to your domain controllers (DCs). It had been years since I'd even needed to think about DNS troubleshooting, so I looked at my current problem as an opportunity to brush up on my skills.

Because DNS has become the cornerstone of a properly functioning Active Directory (AD) environment, and because DNS is the glue that holds the Internet together, the ability to quickly spot and solve DNS problems on your network is essential. Let's take a look at the intricacies of DNS troubleshooting outside of Active Directory (AD), then take a look at the complexities that AD adds to the mix.

Resolving Names
The entire DNS hierarchy is held together by a root domain, and this root domain is maintained by 13 separate servers around the world, managed by commercial, governmental, and educational organizations. Ultimately, these root servers are involved in the process of resolving all public Internet names. Suppose a workstation on your network is attempting to resolve the host name download.beta.example.com to an IP address. This process could take as many as 10 separate DNS messages to resolve, starting with the first message, which is the query from the workstation to the server configured as its DNS server. Figure 1 depicts a standard DNS name-resolution process.

As you can see in Figure 1, the local DNS server takes on the task of resolving the necessary IP address through recursive queries—one of the two types of DNS query messages, the other being iterative. Each public DNS server queried along the way will either give the final answer (if it knows it) or send a referral to the next best step in the recursion process. Because the root DNS servers obviously wouldn't know about an individual host within the beta. example.com domain, it responds that it doesn't know the answer to the query but advises checking with the server responsible for handling .com for a better answer. As the recursion process continues its steps, resolution will occur one way or another—either an IP address or a negative response will be returned.

Given this resolution process, you might think that the root domain servers must either be the largest computers known to man or must often crash because of the sheer load placed on them. In reality, the root servers are spared such torture thanks to the second key component in the name-resolution process: caching.

Understanding Caching
Consider Figure 1's resolution process again, but this time suppose the local DNS server had already looked up the mail server information for the example.com domain a few minutes before getting the query for download.beta.example.com. In this case, the local DNS server already knows where to find the authoritative DNS server for the example.com domain—at least, as of a few minutes earlier—so it can go directly to that server to attempt to resolve the name download.beta.example.com instead of starting at the root domain. Therefore, steps 2, 3, 4, and 5 of the resolution process are unnecessary, providing a 40 percent decrease in communication traffic.

Caching takes place throughout the entire hierarchy of the DNS infrastructure. Going a step further, if anyone else on the local network happens to query for the same host—download.beta. example.com—the local DNS server can serve up a response out of its local cache because it recently found that host, thereby leaving only steps 1 and 10 in Figure 1's communication process—an 80 percent reduction in communication traffic.

Not only DNS servers cache records. Clients also perform caching, so any workstation that has recently cached a record for a host name will keep that record in its cache for a period of time. If an application (e.g., Web browser, email client) on the host has occasion to request that DNS record again, Windows uses its locally cached copy instead of initiating a DNS query, resulting in zero network communication.

This caching hierarchy, which takes place on every server and client involved with DNS—keeps DNS alive on the Internet. However, caching can also throw a wrench into your troubleshooting techniques.

Troubleshooting Mechanics
Understanding how DNS communication and caching work when they're operating properly can reduce the time you spend troubleshooting problems. Let's look at how Windows' DNS resolver works when it attempts to resolve a DNS name to an IP address. As you can see in Figure 2, when tasked to resolve a host name into an IP address, the DNS resolver first checks its local cache to see if it already knows the answer to the query. If it has the answer in its cache, it returns the response and generates no traffic on the network; otherwise, it continues through the rest of the name-resolution process. That process sounds simple, but you need to understand a few things about what's actually going on with the cache.

First, the cache is populated by two main types of entries: entries that have been cached because they were resolved by querying the DNS server for the information, and entries that have been preloaded into the \%systemroot%\ system32\drivers\etc\hosts file. The first type of entries expire at an interval defined by the Time To Live (TTL) value that came embedded in the DNS response the first time the query occurred.

To view the contents of the cache and the time left before the records expire, you can use the Ipconfig /displaydns command at a command prompt. As an example, I issued a DNS query for www.google.com, then checked Ipconfig /displaydns. As you can see in Figure 3, the record has a TTL value of 248 seconds remaining. At the time of the DNS query, the google.com domain's domain information had a period of 5 minutes configured as the TTL for the record for "www"—not particularly surprising for an organization with a large and dynamically changing Web presence. However, more static organizations will typically use longer values, such as 1 day (86,400 seconds). Either way, it's important to understand that during the 5 minutes that this record is cached, if I query for www.google.com again, Windows won't send a query to my DNS sever—it will simply resolve the name from the cache.

In addition to caching positive responses, Windows caches negative responses. Negative responses are responses from a DNS server that sees itself as authoritative for a given domain but has no host record matching the query. Although this type of response has no TTL value attached to it, Windows caches negative responses by default for a period of 5 to 15 minutes, depending on which version of Windows you're using and how it's configured. To learn how to control this caching behavior through the registry, see the Web-exclusive sidebar "Controlling Positive and Negative Caching," http://www.windowsitpro.com, InstantDoc ID 48528.