13.5 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.
13.5.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 namedon'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 will have 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 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:
If the name server is a slave server, you should first check whether or not its master has the correct data. If it does, and the slave doesn't:
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.
13.5.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:
13.5.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:
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 slaves', 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 will help the administrator track down the problem on the remote end.
13.5.4 Lookups Take a Long Time
Long name resolution periods are usually due to one of two problems:
Usually, sending a few ping s will point 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 ping s or queries, but connectivity to the remote network seems all right (a tracert , for example, will get 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 will require 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!