15.6 Problem Symptoms
Some problems, unfortunately, aren't as easy to identify as the ones we've listed. You'll probably experience some misbehavior that you won't be able to attribute directly to its cause, often because any of a number of problems may cause the symptoms you see. For cases like this, we'll suggest some of the common causes of these symptoms and ways to isolate them.
15.6.1 Can't Look Up Local Name
The first thing to do when a program like telnet or ftp can't look up a local name is to use nslookup to try to look up the same name. When we say "the same name," we mean literally the same name?don't add a domain name and a trailing dot if the user didn't type either one. Don't query a different name server than the user did.
As often as not, the user mistyped the name or misunderstood how the search list works and just needs direction. Occasionally, you'll turn up real host configuration errors, such as a mistake in the resolver configuration (e.g., the wrong IP address for a name server). You can check for errors like this using nslookup's set all command.
If nslookup points to a problem with the name server, rather than with the host's configuration, check for the problems associated with the type of name server. If the name server is the primary master for the zone but it doesn't respond with data you think it should:
Check that the zone or zone datafile contains the data in question.
Ensure that the domain names in the records are correct (problem 6).
If the name server is a secondary server, you should first check whether or not its master has the correct data. If it does, and the secondary doesn't:
Make sure you've incremented the serial number on the primary (problem 1).
Look for a problem on the secondary in updating the zone (problem 4).
If the primary doesn't have the correct data, of course, diagnose the problem on the primary.
If the problem server isn't authoritative for the zone that contains the data, check that your parent zone's delegation to your zone exists and is correct (problems 8 and 9). Remember that to that name server, your zone looks just like any other remote zone. Even though the host it runs on may be inside your zone, the name server must be able to locate an authoritative server for your zone from your parent zone's servers.
15.6.2 Can't Look Up Remote Names
If your local lookups succeed but you can't look up names outside your local zones, there is a different set of problems to check:
Can you ping the remote zone's name servers? Maybe you can't reach the remote zone's servers because of connectivity loss (see problem 7).
Is the remote zone new? Maybe its delegation hasn't yet appeared (see problem 8). Alternatively, the delegation information for the remote zone may be wrong or out of date, due to neglect (see problem 9).
Does the domain name actually exist on the remote zone's servers? Does it exist on all of them (see problems 1, 2, and 4)?
15.6.3 Wrong or Inconsistent Answer
If you get the wrong answer when looking up a local name or you get an inconsistent answer, depending on which name server you ask or when you ask, first check the synchronization between your name servers:
Are they all holding the same serial number for the zone? Did you forget to increment the serial number on the primary after you made a manual change (see problem 1)? If you did, the name servers may all have the same serial number, but they will answer differently out of their authoritative data.
Did you forget to restart the primary after making a manual change (see problem 2)? Then the primary returns (via nslookup, for example) a different serial number than the serial number in the zone datafile.
Are the secondaries having trouble updating from the primary (see problem 4)?
Is the name server's round-robin feature rotating the addresses of the domain name you're looking up?
If you get these results when looking up a name in a remote zone, you should check whether the remote zone's name servers have lost synchronization. You can use tools like nslookup to determine whether the remote zone's administrator has forgotten to increment the serial number, for example. If the name servers answer differently from their authoritative data but show the same serial number, the serial number probably wasn't incremented. If the primary's serial number is much lower than the secondary's, the primary's serial number was probably accidentally reset. We usually assume a zone's primary name server is running on the host listed as the origin in the SOA record.
You probably can't determine conclusively that the primary hasn't been restarted, though. It's also difficult to pin down updating problems between remote name servers. In cases like this, if you've determined that the remote name servers are giving out incorrect data, contact the zone administrator and (gently) relay what you've found. This helps the administrator track down the problem on the remote end.
15.6.4 Lookups Take a Long Time
Long name resolution periods are usually due to one of two problems:
Connectivity loss (see problem 7), which you can diagnose with tools like ping and tracert
Incorrect delegation information (see problem 9), which points to the wrong name servers or the wrong IP addresses
Usually, sending a few pings points to one or the other of these causes. Either you can't reach the name servers at all, or you can reach the hosts but the name servers aren't responding.
Sometimes, though, the results are inconclusive. For example, the parent name servers may delegate to a set of name servers that don't respond to pings or queries, but connectivity to the remote network seems all right (a tracert, for example, gets you to the remote network's "doorstep"?the last router between you and the host). Is the delegation information so badly out of date that the name servers have long since moved to other addresses? Are the hosts simply down? Or is there really a remote network problem? Usually, finding out requires a call or a message to the administrator of the remote zone. (And remember, whois gives you phone numbers!)
That's about all we can think of to cover. It's certainly a less than comprehensive list, but we hope it'll help you solve the more common problems you encounter with DNS and give you ideas about how to approach the rest. Boy, if we'd only had a troubleshooting guide when we started!
