If you're troubleshooting a name-resolution problem on your network, you can flush the DNS cache by using the Ipconfig /flushdns command at the command prompt, instead of modifying the registry. Flushing the DNS cache is a one-time operation that dumps the entire cache from memory and starts over from scratch. You can repeat the procedure as often as you want. Also, keep in mind that if you're using your local DNS server on your network as a resolution point for client workstations, it will likely be caching everything it handles as well. If you need to clear the cache on your DNS servers, you can do so through the Microsoft Management Console (MMC) DNS snap-in at Start, Programs, Administrative Tools, DNS. Right-click the DNS server's name and select Clear Cache.
Flushing the DNS cache is always smart if you're testing anything on your network that involves name resolution and if changes might have occurred in the past 5 to 15 minutes. However, as part of the process of clearing the cache, Windows will immediately preload the \%systemroot%\system32\drivers\etc\hosts file from your system into the cache.
Understanding Hosts
Although the cache can sometimes be a hindrance, it can also be quite helpful. Remember that the cache contains both cached copies of records that have been resolved and static entries defined in the hosts file on your local system. I've found the hosts file to be a useful troubleshooting tool when I want to control the behavior of the DNS resolver.
For example, when I'm working on a problem that involves multiple servers responding to one name, and I want to make sure that my system connects to a specific one, I turn to the hosts file. Consider the case of multiple front-end Microsoft Outlook Web Access (OWA) servers that all resolve to the same common URL, as defined in DNS. If your users are complaining about intermittent OWA problems, how would you know which front-end server to investigate? The hosts file lets you preempt the response that your DNS resolver would have normally returned and put your own answer in place. You can force the DNS resolver to always return a specific value by placing that value in the hosts file, which will be loaded into the cache and remain there permanently. The format is simple: You define the address and the name on one line. The DNS resolver cache updates automatically whenever you save any changes to the hosts file, so its effects are immediate.
Multi-Server/ Multi-Adapter Situations
Let's refer back to Figure 2's flowchart. We've discussed what happens when the local cache can resolve a query. But if the local cache can't resolve a query, how does the resolution process continue? Windows continues the name-resolution process by issuing a recursive DNS query to the server specified as the Preferred DNS server in the preferred network adapter's Internet Protocol (TCP/IP) Properties, which Figure 4 shows. If Windows receives no response (positive or negative) from the preferred server within 1 second, the OS issues the same query to the same DNS server—but through all the remaining eligible network adapters in the system—and wait 2 seconds for a response. If there's still no response, Windows issues three more query attempts to get an answer. Each query has a longer timeout than the previous one (2 seconds, 4 seconds, and 8 seconds, respectively) and goes to all the defined DNS servers through all the eligible adapters. The total time for a DNS-resolution process should be no more than 17 seconds.
As far as Windows is concerned, what makes an adapter "preferred" or "eligible"? (The Microsoft term is "under consideration.") In some of its technical documentation, Microsoft has been vague about this aspect of the name-resolution process. For example, if all the DNS servers on a specific adapter are queried and none of them reply, that adapter is taken out of consideration for a period of 30 seconds. It's safe to assume that the adapter is now removed from the "eligible" category for any future queries during that time period—although the documentation doesn't specifically state that. Also, Microsoft's documentation states that "the [DNS] resolver keeps track of which servers answer queries more quickly, and might move servers up or down on the list based on how quickly they reply to queries"—likely a strong determiner for preferred adapters.
Microsoft's assertion that the resolver can change the order of the DNS servers it queries based on its own formulas contradicts the settings you'll find in a network adapter's advanced DNS configuration interface, which lets you choose DNS server addresses in order of use. In much of its documentation, Microsoft clearly has other ideas. Therefore, I no longer trust the order in which the DNS resolver will attempt to look up IP addresses. When I'm troubleshooting, I typically use simple command-line sniffers such as Network Grep (Ngrep) and WinDump to see the DNS queries leaving my system, as well as the DNS servers they're destined for.
In an upcoming article, I'll dive more deeply into these tools, as well as a few others that might be new to you. Also, for another indispensable resource of DNS-related tools, see the Web-exclusive sidebar "An Invaluable DNSTroubleshooting Resource," InstantDoc ID 48529.
Nslookup
Once you understand how a DNS query works and how the DNS resolver sends DNS queries out of its various network adapters, you're ready to start working with the command-line utility Nslookup. This utility is, without a doubt, the Swiss Army knife of DNS resolution and troubleshooting.
You can use Nslookup as a non-interactive command, so you can use it to look up hosts through the standard resolution process that the Windows DNS resolver would normally perform. For example,
nslookup www.windowsitpro.com
Alternatively, you can tweak the resolution process and direct your DNS query to a specific server (instead of the servers configured locally) by adding the specific DNS server's IP address to the end of the command line. For example,
nslookup www.windowsitpro.com 10.0.0.1
This option is helpful if you want to make sure you're getting responses from a specific DNS server that might be problematic.
If you want to get even deeper into the resolution process, you can simply use Nslookup by itself and go to interactive mode, which lets you control much more of the resolution process, such as the server to use, the query type (recursive vs. iterative), and the level of debugging information to provide. Let's take a look at a few troubleshooting scenarios.
As I mentioned earlier, in some circumstances, the DNS-resolution process might need to go all the way to the root domain servers on the Internet, should no other servers along the way have an answer that's cached and still available within the record's defined TTL. You might also want to do so yourself (and check the responses each step of the way) to determine where the resolution process is breaking down. To simulate this process with Nslookup, you can issue iterative (not recursive) lookup queries for a target domain— but by starting with any of the root domain servers listed in Table 1 as the target DNS server, then manually following each referral that you receive until you get a final answer.
I performed a lookup for the fully qualified domain name (FQDN) www.windowsitpro.com by configuring Nslookup to use iterative queries. I used the Set Norecurse option at the prompt, then started my query at the root servers by using the Server option to tell Nslookup where to send the query. By following the referrals I received down the line, changing my target server each time, I could reach the answer by iterating through the entire process manually. This troubleshooting technique provides significantly more detail about the resolution process than simply issuing a query to your local DNS server and accepting whatever comes back as a response.
