Solution provider takeaway: Network solution providers need to know how DNS works and how to perform basic troubleshooting of DNS server failures, as explained in this tip.
DNS server failures are some of the most serious types of failures that can occur on a Windows network. If DNS is not working, then the Active Directory will not work either. Furthermore, users may not be able to access resources on the local network or the Internet. If your clients experience these types of problems, they will most likely call on you for help. As a network solution provider, you need to be familiar with how DNS works and how to perform basic troubleshooting. In this article, I show you some simple techniques for troubleshooting a DNS server failure.
Is the DNS server really to blame?
I have fixed a number of
First, confirm the DNS server's IP address and that the DNS server service is running. Once you verify these two things, you can get started with the process of troubleshooting the DNS server failure.
I like to start out by making sure that the client machine is pointed to the correct DNS server. The easiest way to do this is to open a command prompt window and enter the following command:
This command will list the computer's TCP/IP configuration. You can get the same information through the computer's network configuration screens, but I prefer to use this method because I have run into a couple of instances where the information that Windows showed did not match the configuration that Windows was actually using.
Upon displaying the machine's TCP/IP configuration, verify that the computer is pointed to the correct DNS server. For example, if you look at Figure A, you can see that my computer is pointed to a DNS server with an IP address of 220.127.116.11.
Verify that the machine's TCP/IP is configured to use the correct DNS server.
Assuming that the configuration is correct, the next thing I recommend doing is pinging the DNS server. This will verify that the client's machine is actually able to communicate with the DNS server. Keep in mind, though, that if the DNS server's firewall is configured to block ICMP traffic then the ping will not be successful.
Once you have verified that the client can communicate with the DNS server, it's time to see if the DNS server is able to resolve host names. The easiest way to do this is to test the IP address of a familiar host name. For example, I know that my website uses the IP address 18.104.22.168. Therefore, if I run the NSLOOKUP command against www.brienposey.com, my DNS server should resolve www.brienposey.com to 22.214.171.124, as shown in Figure B.
NSLOOKUP verified the IP address of my website.
One more important thing to notice in Figure B is that Windows also verifies the IP address of the DNS server that was used to resolve the domain name. This IP address should match the one that is shown in Figure A.
What happens if the NSLOOKUP command returns an incorrect IP address for the target domain? Well, there are a couple of things that could have happened. One possibility is that the domain's IP address has changed, but the change has not yet been replicated to the DNS server. Another possibility is that malware has modified the contents of the DNS cache. Once Windows has resolved a domain name to an IP address, the name resolution is cached and kept on hand for a while so that Windows does not have to repeat the query each time the domain name needs to be used. If there is an invalid entry in the cache, then Windows will not be able to access the domain correctly.
Fortunately, it is easy to flush the DNS cache. To do so, just enter the IPCONFIG command followed by the /FLUSHDNS switch. If you are running Windows Vista, then this operation will require elevated privileges. You can get these privileges by right-clicking on the Command Prompt menu option and choosing Run As Administrator from the resulting shortcut menu.
Once you flush the DNS cache, try running NSLOOKUP once again. If the host name is still incorrect, then there are a couple different possibilities. For example, the DNS server may have lost connectivity to a root-level server. Another possibility is that there is an incorrect entry in the LMHOSTS file or in the Windows registry. I show you how to deal with these types of issues in part 2 of this series.
About the author
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies.
This was first published in October 2008