Community Pick: Many members of our community have endorsed this article.

DNS Troubleshooting made easy

Most DNS problems are VERY easily troubleshot and identifiable if you can follow the steps a DNS query takes. I would like to share the step-by-step a DNS query takes from the origin to the destination.
1)  The client tries to contact a remote site using DNS and will send out a DNS query. It will first look at its own records prior to anything else.
 --- a)The first place it will look in its own DNS resolver cache
((NOTE: The problem with a DNS resolver cache is you may, once in a while, get a bad record. This will point your client to the wrong IP. You can resolve this by flushing your DNS cache. It doesn't hurt your computer to flush the DNS cache, and it can easily be done by going to the command prompt and typing IPconfig /flushdns))
--- b)Then, the client will look in the C:\Windows\system32\drivers\ect\Host file. This file has to be manually configured.
((NOTE: The problem with a configured HOST file, is if the client does not see the DNS solution in the Host file, it can assume that the query can't be resolved and stop right there. In other words your query will not make it to the server and could time out.  If you have a DNS server, these records should NEVER be configured. They are editable by with a text editor, like Wordpad or notepad. It is OK to have the default loopback address for the local HOST.))
2) If the client can not resolve its own query, then it will go to it's preferred DNS server.

3) The preferred DNS server will first try to look up the DNS query in its own DNS cache.

4) After looking in all of these places, you finally arrive at looking up your DNS records in the forward lookup zone. The forward lookup zone carries groups of different records. For a good list of DNS record types, and their use, I would like to revert you to a well written article by another Expert's Exchanges Articles:
5) If the DNS server can't find the records that it is authoritative for, within the forward lookup zone, either the server or client will try to make a query to an outside server. What approach it takes depends upon your configuration. So, let's define what you have configured by defining the two lists and methods of contacting other DNS servers.

>>There are two types of contacts to outside servers. One is a recursive and the other is an iterative query.
>>There are also two lists to contact the outside server. One is called a forwarder and the other is called roothints.
Here is a brief explaination of each:
---Iteration: Iteration is done when the server can't resolve the query and tells the client, "I can't do it, let me refer you to an outside root server." This referal can come from the server's cache records. The client will then go out to a root server it was refered to, and that root server will refer that client to a Top Level domain server. The top level domain server will refere the client all the way down to the authoritative server of that DNS query. So, it's basically passing the buck.

---Recursive lookup: A recursive query appends a flag on the query that basically asks the server to perform an iterative query on behalf of the client. Like above, your server will be passed down from the outside root server to the top level domain server, on down the chaing to the authoritative server. Once DNS resolution is provided. The server provides the DNS resolution to the query back to the client.

---Forwarders: Forwarders are manually configured DNS servers that your server will send a recursive query on behalf of the client. The outside Forwarding server will perform the iterative query and pass that back to your client.

---Root Hints: Root Hints are a list of public DNS that come configured already. This list of servers is at the root of DNS to outside servers.

Disabling recursion will effectively not permit servers to performing iterative queries on behalf of the clients or another server. So, effectively that disables forwarders and defaults your client to perform iterative queries.

With knowledge of a DNS query comes some very powerful DNS troubleshooting techniques.

--Let's say a single client or member server is having problems with DNS. That means the client has a problem with its DNS resolver cache, preferred DNS server, or Host file.
--Let's say you can't locate one client within the domain using DNS. It is probably because that client didn't register itself within DNS.
How to perform dynamic DNS registration by Chris Dent:

--Let's say you can't access many clients and services on your domain. This is probably caused by the DNS records are having problems and need to be diagnosed using some of the tools below. Or your preferred DNS server is an outside server.

--Let's say you can't contact your mail server internally, but can externally. It's probably a certain record for mail servers, known as an MX record, within the DNS forward lookup zone.

--Let's say your having problems loggging on and you get an error saying the domain server can not be found or can not be contacted. Most likely this means that your SRV records are not found by your clients. This could mean your preferred DNS server on your clients are not local preferred DNS servers or it could mean that the SRV records are corrupt.
How do you verify your SRV records:

--Lets say you can contact outside web sites while having no problem with domain services (like authentication) and connections. This is almost definately your prefered DNS server is an outside server, not your inside server.

--Let's say a DHCP client is having problems communicating with the domain while having no problems with outside web sites. This is caused by one of two issues. Either your DHCP server is passing down the wrong IP for the preferred DNS server. You can edit this by going to DHCP snap in>>scope options>>DNS servers. The other scenario is your router is supplying DHCP. The problem with the router supplying DHCP is by default it will also usually supply DNS. However, it will NOT hold the domain server's SRV records for authentication and other services. These two errors are quite common.

For a list of other things that kill DNS, a nice article to read is "10 DNS errors that kill your network"

**Do you see how this might help you?


You will find that the above information will help you pinpoint about 90% of all DNS problems in a couple minutes. But, there are other tools to help you along in troubleshooting DNS.

Two of them are DCdiag or Netdiag:
Both tools are found in the server support tools and 2003 server support tools. These support tools can be used to limited extent with XP pro systems  
-Netdiag- audits the network configuration of that compputer
-DCdiag- looks into the overall health of a Domain controller
At the command prompt, you can type DCdiag /V (stands for DCdiag verbose) or Netdiag. It will tell you of DNS errors. However, unless you can interpret the error into something tangible, these errors may not tell you much.

Another fine article written by Microsoft is how to verify the DNS SRV records.SRV, stands for SeRVice records. If you are having problems with authentication due to DNS, then you may wish to look into your SRV records of that DNS server to make sure it has your authentication servers listed. SRV records point the way to your Active directory servers and other services. These particular records can be askew from time to time. And you may run into things like not being able to authenticate or logon to your server.  Here is the article on checking your SRV records. Please NOTE ((A DSL router will not support SRV records and therefore is not an appropriate DNS server for a LAN with a Windows Domain controller on it. So, disabling a DSL router's ability to provide DHCP and DNS is important to providing a good domain.))


As mentioned above, there are tools specific to a LAN with a domain, (netdiag and DCdiag). They can be cumbersome to decipher unless you have a lot of experience interpereting the errors.

Tools that can be used to check the paths of DNS queries can also be deceiving.

NSLookup is strictly a DNS checking tool, but ping is not. Ping is a multi-communications protocol checking tool. Let's say you ping something by computer name:

EXAMPLE: Ping Mycomputer.

Did you know you are actually checking the Netbios path and not the DNS path? So, you may be able to ping by computer name, but not have access through DNS to the computer. If you ping by fully qualified domain name, this is a DNS ping.

Example: Ping

So, for DNS troubleshooting, I recommend you use NSlookup. Using this tool will tell you where your DNS query stops. They call these hops.
-- If the query stops at the client, you will get an unresolved address. This means  you have a problem with the client,
-- If it stops at your LAN's DNS server, you will see your DNS server as the first hop. This means your LAN's DNS server isn't able to communicate to outside servers.  
--If it stops after bouncing around to all kinds of different servers, you may see a whole bunch of hops that are trying to give you DNS resolution. This means that outside servers were not able to give you DNS resolutions to your query. Most likely, you were looking to an outside server to resolve something within your LAN.

Another tool recommended for DNS troubleshooting is called Dig. It was recommended to me by Chris_Dent, Expert's Exchange's top DNS expert.

Personally, I have never used.


Below is a diagram I like to provide to illistrate a DNS query> I found it on a Microsoft Technet article that I can't find any more:


Comments (6)

Chris DentPowerShell Developer
Top Expert 2010


Hey Chief :)

I hope you don't mind me dropping a few comments in :)

> 3) Then, the server will look in a couple places prior to the forward lookup zone.
> --b) then it will look at its own C:\Windows\system32\drivers\ect\Host file.

The DNS Server will never provide an answer to a query from its own Hosts file. That's for the DNS Client service only.

> ---Recursive lookup: A recursive lookup is handled by the server.

Recursion Desired is a flag in the header of the DNS Request. If a system requests recursion it is asking the server to perform an Iterative Query on behalf of the client.

If the client says No Recursion (in the header) then it is up to the client to perform an Iterative Query. The MS DNS Resolver (Client) cannot perform Iterative Queries. The DNS server will provide the best answer it is able in this instance (from Cache typically).

When using Forwarders the server will make a query with Recursion Desired to the Forwarder. The Forwarder performs the Iterative Query (if no cached answer is found).

> ---Root Hints: Root Hints are a list of public DNS servers that your server
> forwards DNS queries to if your server can't resolve the DNS query

It doesn't Forward the request that tends to be reserved for when the Iterative process is being handed off. Rather it makes a request to a root server, the root server returns a Referral, then the server makes a request to the TLD (Top Level Domain) servers and so on down the chain until it arrives at the authoritative servers and can get an answer. This one is an Iterative Query.

> Special NOTE: ((Forwarders will use recursion, while Root Hints Servers
> use iterative queries. If you have recursion disabled, your server defaults to root hints.))

Disabling Recursion (support for Recursive Queries) disables both Forwarders and Root Hints. The server will only answer from Cache or Local (Authoritative) zones.

And I have another tool for you. Dig. There's a Windows version of it here, it's really rather useful.


Nice article, thank you.


Hey Chris:

I am finally getting around to editting the article. Thanks for the corrections. Following the query really clears up the troubleshooting of DNS.
Premkumar YogeswaranPrincipal Infrastructure Engineer - IT

Hi ChiefIT,
It is an good article..!!!

I have a question in this:
@ Clients Responsibility:
a) DNS cache b)host file both is fine.

Could you let us know were the DNS suffix list will participate in DNS query?

Chris DentPowerShell Developer
Top Expert 2010

DNS suffixes are appended, in order, to any single-label query (or multi-label query, set in group policy).

As such, the DNS Suffixes and the appending of are the responsibility of the client, this would be a "1 c". The client then repeats the query (2 to 4) for each suffix until it either gets a non-NXDOMAIN response or it runs out of suffixes to append.


View More

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.