14.7. Problem SymptomsSome problems, unfortunately, aren't as easy to identify as the ones we listed. You'll experience some misbehavior but won't be able to attribute it directly to its cause, often because any of a number of problems can 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.
14.7.1. Local Name Can't Be Looked UpThe first thing to do when a program like telnet or ftp can't look up a local domain name is to use nslookup or dig to try to look up the same name. When we say "the same name," we mean literally the same name -- don't add labels 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 doesn't understand how the search list works and just needs direction. Occasionally, you'll turn up real host configuration errors:
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 isn't responding with data you think it should:
If the problem server is a caching-only name server:
14.7.2. Remote Names Can't Be Looked UpIf your local lookups succeed but you can't look up domain names outside your local zones, there is a different set of problems to check:
14.7.3. Wrong or Inconsistent AnswerIf you get the wrong answer when looking up a local domain name, or an inconsistent answer depending on which name server you ask or when you ask, first check the synchronization between your name servers:
You probably can't determine conclusively that the primary master hasn't been reloaded, 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.
If you can determine that a parent name server -- a remote zone's parent, your zone's parent, or even one in your zone -- is giving out a bad answer, check whether this is coming from old delegation information. Sometimes this requires contacting both the administrator of the remote zone and the administrator of its parent to compare the delegation and the current, correct list of authoritative name servers.
If you can't induce the administrator to fix the data or if you can't track down the administrator, you can always use the bogus substatement or bogusns directive to instruct your name server not to query that particular server.
14.7.4. Lookups Take a Long TimeSlow name resolution is usually due to one of two problems:
Sometimes, though, the results are inconclusive. For example, the parent name servers 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 traceroute, 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 requires a call or a message to the administrator of the remote zone. (Remember, whois gives you phone numbers!)
14.7.5. rlogin and rsh to Host Fails Access CheckThis is a problem you expect to see right after you set up your name servers. Users unaware of the change from the host table to domain name service won't know to update their .rhosts files. (We covered what needs to be updated in Chapter 6, "Configuring Hosts".) Consequently, rlogin's or rsh's access check will fail and deny the user access.
Other causes of this problem are missing or incorrect in-addr.arpa delegation (problems 9 and 10) or forgetting to add a PTR record for the client host (problem 4). If you've recently upgraded to BIND Version 4.9 or newer and have PTR data for more than one in-addr.arpa zone in a single zone data file, your name server may be ignoring the out-of-zone data. Any of these situations will result in the same behavior:
In other words, the user is prompted for a password despite having set up password-less access with .rhosts or hosts.equiv. If you were to look at the syslog file on the destination host (wormhole.movie.edu, in this case), you'd probably see something like this:% rlogin wormhole Password:
You can tell which problem it is by stepping through the resolution process with yourfavorite query tool. First query one of your in-addr.arpazone's parent name servers for NS records for your in-addr.arpa zone. If these are correct, query the name servers listed for the PTR record corresponding to the IP address of the rlogin or rsh client. Make sure they all have the PTR record and that the record maps to the right domain name. If not all the name servers have the record, check for a loss of synchronization between the primary master and the slaves (problems 1 and 3).May 4 18:06:22 wormhole inetd: login/tcp: Connection from unknown (220.127.116.11)
14.7.6. Access to Services DeniedSometimes rlogin and rsh aren't the only services to go. Occasionally you'll install BIND on your server and your diskless hosts won't boot, and hosts won't be able to mount disks from the server, either.
If this happens, make sure that the case of the domain names your name servers return agrees with the case your previous name service returned. For example, if you are running NIS and your NIS host maps contain only lowercase names, you should make sure your name servers also return lowercase domain names. Some programs are case-sensitive and won't recognize names in a different case in a data file, such as /etc/bootparams or /etc/exports.
14.7.7. Can't Get Rid of Old DataSometimes, after decommissioning a name server or changing a server's IP address, you'll find the old address record lingering around. An old record may show up in a name server's cache or in a zone data file weeks or even months later. The record clearly should have timed out of any caches by now. So why's it still there? Well, there are a few reasons this happens. We'll describe the simpler cases first.
18.104.22.168. Old delegation informationThe first (and simplest) case occurs if a parent zone doesn't keep up with its children or if the children don't inform the parent of changes to the authoritative name servers for the zone. If the edu administrators have this old delegation information for movie.edu:
then the edu name servers will give out the bogus old address for wormhole.movie.edu.$ORIGIN movie.edu. @ 86400 IN NS terminator 86400 IN NS wormhole terminator 86400 IN A 22.214.171.124 wormhole 86400 IN A 126.96.36.199 ; wormhole's former ; IP address
This is easily corrected once it's isolated to the parent zone's name servers: just contact the parent zone's administrator and ask to have the delegation information updated. If your parent zone is one of the gTLDs, you may be able to fix the problem by filling out a form on your registrar's web site to modify the information about the name server. If any of the child zone's name servers have cached the bad data, kill them (to clear out their caches), delete any backup zone data files that contain the bad data, then restart them.
188.8.131.52. Registration of a non-name serverThis is a problem unique to the gTLD zones: com, net, and org. Sometimes, you'll find the gTLD name servers giving out stale address information about a host in one of your zones -- and not even a name server! But why would the gTLD name servers have information about an arbitrary host in one of your zones?
Here's the answer: you can register hosts in the gTLD zones that aren't name servers at all, such as your web server. For example, you could register an address for www.foo.com through a com registrar, and the com name servers will give out that address. You shouldn't, though, because you'll lose a fair amount of control over the address. If you need to change the address, it could take a day or more to push the change through your registrar. If you run the foo.com primary master name server, you can make the change almost instantly.
184.108.40.206. What have I got?How do you determine which of these problems is plaguing you? Pay attention to which name servers are distributing the old data and which zones the data relates to:
Copyright © 2002 O'Reilly & Associates. All rights reserved.