A very wise man once said “if DNS ain’t happy, ain’t nobody happy”. If we overlook the atrocious grammar for a moment and focus on what he meant, the statement is spot on. Almost all applications and services on the network are dependent upon DNS. Every user application is. And if there is a problem with DNS, no application will function correctly. Being able to quickly troubleshoot DNS is a key skill, and one that every IT pro should have. Here are some tools and methods to get you started.
Never make assumptions!
Before you get started too far down the road of troubleshooting DNS, make sure that there’s not a problem closer to the user.
Typos
Far too often, a supposed problem with DNS or a server down could simple be a typo in what the user was putting into the address bar. Spelling counts, even on the Internet!
DNS down
The DNS server itself may be down or unreachable. See if you can ping your DNS server or tracert past your Internet router before spending too much time running down the wrong problem.
State information in cache
Clients cache DNS information for the duration of the TTL, just like servers. In Windows, you can clear the client’s DNS cache by entering
ipconfig /flushdns [enter]
at an administrative command prompt. Clear out the cache and then see if you still have problems.
HOSTS and LMHOSTS files
More commonly found on servers than workstations, bad entries in the HOSTS or LMHOSTS files can send you on a wild goose-chase. If you ping and get one ip.addr, but do an NSLOOKUP (see below) and get another, you may be dealing with bad data in one of these files. If they exist, your operating system will favor their answers over querying a server. Check them, and comment or delete anything in them that is wrong.
Using NSLOOKUP
The NSLOOKUP command is built into all versions of Windows. Its syntax is straightforward. If you enter NSLOOKUP FQDN [enter] it will query the first DNS server configured in your network card and, assuming DNS is working and the name you query is valid, return the ip.addr.
There are many other switches that you can use with NSLOOKUP, and you can also enter an interactive session with NSLOOKUP. Open a command prompt, and type NSLOOKUP [enter] to get into interactive mode. Then type ? [enter] to see all the options that are available.
As you can see, you can either set options for the session or use switches to modify specific commands. You can specify a DNS server to query, the type of record you want to look up, such as A, PTR, MX, etc., to request a recursive lookup, append the default domain name, and more. Here are some example commands to get you started. Use these directly at the command prompt, rather than in an interactive session.
- Simple query – this simply looks up a name against your default servernslookup www.gfi.com [enter]
- Specific record type-this query can look up a specific record. Use MX, A, NS, PTR, etc.nslookup –query=MX gfi.com [enter]
- Specific record type for NS or SOA-either of these queries can help you find the authoritative DNS servers for a domainnslookup –query=NS gfi.com [enter]nslookup –query=SOA gfi.com [enter]
- Query for anything available-this query will usually return the NS, SOA, MX and TXT records for a domain.nslookup –query=ANY gfi.com [enter]
- Query an ip.addr for an associated name. This only works if there is an in-addr.arpa zone for the network with the appropriate PTR record in place, so don’t be surprised if this fails.nslookup 216.134.217.31 [enter]
- Debug query-if you want to see everything that goes on with the query and response, use debug. If you really want to see more, use –d2 instead of –debug. Mind. Blown. Boom.nslookup –debug www.gfi.com [enter]
Using WHOIS
If you want to find the authoritative servers for a domain, you can use WHOIS to check the domain record. Go to http://www.whois.net/ and enter the domain name you are investigating. That will list information about the domain, including the authoritative DNS servers on the Internet.
You can then specify one of the authoritative name servers for the domain in your query to be sure you are going “straight to the source” for your data. If responses from the authoritative server differ from your local or ISP’s DNS server, you are dealing with stale data in the cache, and may have to wait for it to expire.
Often, you can find the same information using NSLOOKUP and querying for the SOA record. It should have the primary name server listed.
It even goes so far as to give you the ip.addr of that authoritative server to save you some time looking it up.
Now, if you want to be sure you are going straight to that source, query the primary name server. Just remember to set your type back to A.
As you can see from the above responses, gfi.com has a single A record, but www.gfi.com has been delegated to two other servers. If we query one of them, we see…
With the above, you ought to have enough to start using NSLOOKUP to troubleshoot DNS issues. Query your own domain to see what comes back for records you are familiar with, then compare that to other domains and see what the differences are.
If you are already familiar with NSLOOKUP, are there any other special syntaxes that you like to use when troubleshooting DNS resolution? If there are, please leave a comment.
