How To Troubleshoot DNS Issues in Windows and Active Directory

Wednesday, December 29th, 2010 by Andrew Kuhlmann (See all posts by Andrew Kuhlmann)

A very common issue which occurs when troubleshooting server related issues is DNS. There are many reasons for this, however the primary reason is the delay in propagation of DNS records. Often times a web application or site will require DNS records to function properly, but these changes either cannot be made prior to testing or do not propagate fast enough due to the nature of DNS servers.

When testing from a Windows machine you have the option of modifying the Hosts file. This file is located at the same path for almost all modern versions of Windows, including Windows Server:

%systemdrive%\Windows\System32\drivers\etc

To edit the hosts file, simply click on it. Use notepad to open the file.

A typical hosts file will look something like this by default:

By default, the hosts file is inert. That is to say, it doesn’t do anything until you add a line to it.

In terms of DNS resolution, the hosts file is a substitute for A records. The hosts file does not support other record types such as MX, Cname, etc. Technically by modifying the hosts file you are simply mapping an IP to a host name, which is effectively what an A record would do on a normal DNS server.

Editing the hosts file to achieve your objective is easy. For example, I want testdomain.com to resolve to an internal IP of 192.168.1.2. The host file entry that I would make would look like this:

192.168.1.2 testdomain.com

Note that you can use a tab or space to separate the IP and the hostname, either one works the same way.

Utilizing the hosts file you can rule out simple resolution issues for a given site, or you can setup an internal testing environment without making any modifications to a DNS server.

Once you are ready to make the DNS changes publicly, you can simply come back to the hosts file and comment out the entry that you have made previously by adding a # to the beginning of the line. This will allow you to quickly modify this line back if needed. You can also comment this file to explain what certain records are, which is useful for example if you are modifying the hosts file on a server which multiple people administer.

Another common issue that comes up a lot is the DNS cache in Windows. This occurs at a few different levels, and I’ll go over them in order. The first is at the workstation level. Typically in an Active Directory environment, all workstations will be configured in one way or another to use an Active Directory server as their DNS provider. Depending on the organizational topology, this DNS server will then query external DNS servers for records which it does not have a corresponding Forward Lookup Zone.

If you have recently made a change to or deleted a DNS record, and this record has been looked up recently, it will be stored in the DNS cache in several places. Firstly on the AD DNS server, and again on each Workstation or Server which has made this query as well.

Thankfully, forcing updates is not difficult. In windows, the command to use is:

ipconfig /flushdns

This command will flush the DNS cache. The next time you try and resolve a host, it will pull a new record from your DNS server.

However, simply running this command on your workstation may not resolve your issue if it is a public DNS record. You will also need to run this command on your AD server which is providing DNS resolution. Additionally, you must also clear the cache of the DNS service itself. This is done via the DNS MMC snap-in as is seen in this example:

Once you have cleared the DNS service cache, you will then be able to pull fresh records on your DNS server. That way, all workstations or servers which utilize this server will get fresh records. Of course, if the records are still out of date on the public DNS server which your DNS server utilizes then you will continue to get the old records until the new ones propagate.

Finally, another amazingly useful tool is something I think that a lot of administrators take for granted. That is, nslookup.exe.  This is a utility that comes installed by default on all Windows systems. While this utility may seem redundant to ping, as all it does at first glance is resolve hosts to IPS, it actually is a lot more useful when the full set of arguments are used.

For example, I know that my DNS server is sitting with a clear cache for testdomain.com. I’ve made the public DNS record changes on my web hosting providers DNS servers, and I want to check to see if they have propagated out to other DNS servers such as the ones that my AD server forwards requests to… However, I don’t want to actually change the DNS server that my workstation uses.

Nslookup is very useful in this instance, as you are able to easily change the server which it uses to resolve domains.

To achieve this, open a command prompt and simply run nslookup.

To change the DNS server to Google’s public DNS server (8.8.8.8) simply issue the command

server 8.8.8.8

The expected result of this command would look like this:

Now I’m ready to lookup a hostname. Simply type the name of the domain you wish to lookup and it will query the above specified DNS server for the record. By default, nslookup is going to return the A record. However, you can change the type of record to query for by using the following command:

set type=(ex. A,AAAA,A+AAAA,ANY,CNAME,MX,NS,PTR,SOA,SRV)

For example, to return any record I’d use:

set type=any

This is by no means an exhaustive list of the features of nslookup. For additional features simply type ? for the built in help text.

As stated above, DNS is a very common cause of problems with web services. I recommend whenever you’re having an issue with a given service or application to simply check the DNS on each machine to make sure that it’s resolving how you think that it should. Utilizing the above methods you should be able to quickly rule out resolution issues.