 |  |
12.7. Troubleshooting nslookup Problems
The last thing you want is to have problems with your troubleshooting tool. Unfortunately, some types of failures render nslookup nearly useless. Other types of nslookup failures are (at best) confusing, because they don't give you any clear information to work with. While there may be a few problems with nslookup itself, most of the problems you encounter will be caused by name server configuration and operation. We'll cover these problems here.12.7.1. Looking Up the Right Data
This isn't really a problem per se, but it can be awfully confusing. If you use nslookup to look up a type of record for a domain name, and the domain name exists but records of the type you're looking for don't, you'll get an error like this:
So what types of records do exist? Just set type=any to find out:% nslookup Default Server: terminator.movie.edu Address: 0.0.0.0 > movie.edu. *** No address (A) records available for movie.edu.
> set type=any
> movie.edu.
Server: terminator.movie.edu
Address: 0.0.0.0
movie.edu
origin = terminator.movie.edu
mail addr = al.robocop.movie.edu
serial = 42
refresh = 10800 (3H)
retry = 3600 (1H)
expire = 604800 (7D)
minimum ttl = 86400 (1D)
movie.edu nameserver = terminator.movie.edu
movie.edu nameserver = wormhole.movie.edu
movie.edu nameserver = zardoz.movie.edu
movie.edu preference = 10, mail exchanger = postmanrings2x.movie.edu
postmanrings2x.movie.edu internet address = 192.249.249.6612.7.2. No Response from Server
What could have gone wrong if your name server can't look up its own name?
The "no response from server" error message means exactly that: the resolver didn't get back a response. nslookup doesn't necessarily look up anything when it starts up. If you see that the address of your name server is 0.0.0.0, then nslookup grabbed the system's host name (what the hostname command returns) for the Default Server field and gave you its prompt. It's only when you try to look something up that you find out there is no name server responding. In this case, it's pretty obvious that there's no server running -- a name server ought to be able to look up its own name. If you are looking up some remote information, though, the name server could fail to respond because it's still trying to look up the data and nslookup gave up waiting. How can you tell the difference between a name server that isn't running and a name server that is running but didn't respond? You can use the ls command to figure it out:% nslookup Default Server: terminator.movie.edu Address: 0.0.0.0 > terminator Server: terminator.movie.edu Address: 0.0.0.0 *** terminator.movie.edu can't find terminator: No response from server
In this case, no name server is running. If the host couldn't be reached, the error would be "timed out." If a name server is running, you'll see the following error message:% nslookup Default Server: terminator.movie.edu Address: 0.0.0.0 > ls foo. -- Try to list a nonexistent zone *** Can't list domain foo.: No response from server
That is, unless there's a top-level foo zone in your world.% nslookup Default Server: terminator.movie.edu Address: 0.0.0.0 > ls foo. [terminator.movie.edu] *** Can't list domain foo.: No information
12.7.3. No PTR Record for Name Server's Address
Here's one of nslookup's most annoying problems: something went wrong, and nslookup exited on startup:
The "nonexistent domain" message means that the name 3.249.249.192.in-addr.arpa doesn't exist. In other words, nslookup couldn't map 192.249.249.3, the address of its name server, to a domain name. But didn't we just say that nslookup doesn't look up anything when it starts up? In the configuration we showed you before, nslookup didn't look up anything, but that's not a rule. If you create a resolv.conf that includes one or more nameserver directives, nslookup tries to reverse map the address to get the name server's domain name. In the preceding example, there is a name server running on 192.249.249.3, but it said there are no PTR records for the address 192.249.249.3. Obviously, the reverse-mapping zone is messed up, at least for the domain name 3.49.249.192.in-addr.arpa.% nslookup *** Can't find server name for address 192.249.249.3: Non-existent host/domain *** Default servers are not available
The "default servers are not available" message in the example is misleading. After all, there is a name server there to say the address doesn't exist. More often, you'll see the error "no response from server" if the name server isn't running on the host or the host can't be reached. Only then does the "default servers are not available" message make sense.
12.7.4. Query Refused
Refused queries can cause problems at startup, and they can cause lookup failures during a session. Here's what it looks like when nslookup exits on startup because of a refused query:
This one has two possible causes. Either your name server does not support inverse queries (older nslookup s only) or an access list is preventing the lookup.% nslookup *** Can't find server name for address 192.249.249.3: Query refused *** Default servers are not available %
Old versions of nslookup (pre-4.8.3) used an inverse query on startup. Inverse queries were never widely used -- nslookup was one of the few applications that did use them. In BIND 4.9, support for inverse queries was dropped, which broke old nslookup s. To accommodate these old clients, a new configuration file option was added.
In BIND 4, the directive looks like this:
In BIND 8, the statement looks like this:options fake-iquery
options { fake-iquery yes; };This causes your name server to respond to the inverse query with a "fake" response that is good enough to let nslookup continue.[97]
[97]The fake response to an inverse query for, say, the domain name that owns the address 192.249.249.3 is just the address in square brackets, [192.249.249.3].Access lists can also cause nslookup startup problems. When nslookup attempts to find the domain name of its name server (using a PTR query, not an inverse query), the query can be refused. If you think the problem is an access list, make sure you allow the host you're running on to query the name server. Check any secure_zone TXT records or allow-query substatements for the IP address of the local host or the loopback address, if you're running nslookup on the same host as the name server.
Access lists can do more than cause nslookup to fail to start up. They can also cause lookups and zone transfers to fail in the middle of a session when you point nslookup at a remote name server. This is what you would see:
% nslookup Default Server: hp.com Address: 15.255.152.4 > server terminator.movie.edu Default Server: terminator.movie.edu Address: 192.249.249.3 > carrie.movie.edu. Server: terminator.movie.edu Address: 192.249.249.3 *** terminator.movie.edu can't find carrie.movie.edu.: Query refused > ls movie.edu --This attempts a zone transfer [terminator.movie.edu] *** Can't list domain movie.edu: Query refused >
12.7.5. First resolv.conf Name Server Not Responding
Here is another twist on the last problem:
This time, the first name server listed in resolv.conf did not respond. We had a second nameserver directive in resolv.conf, though, and the second server did respond. From now on, nslookup will send queries only to wormhole.movie.edu; it won't try the name server at 192.249.249.3 again.% nslookup *** Can't find server name for address 192.249.249.3: No response from server Default Server: wormhole.movie.edu Address: 192.249.249.1
12.7.6. Finding Out What Is Being Looked Up
We've been waving our hands in the last examples, claiming that nslookup was looking up the name server's address, but we didn't prove it. Here is our proof. This time, when we started up nslookup, we turned on d2 debugging from the command line. This causes nslookup to print out the query messages it sent, as well as printing out when the query timed out and was retransmitted:
% nslookup -d2
------------
SendRequest( ), len 44
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0,
additional = 0
QUESTIONS:
3.249.249.192.in-addr.arpa, type = PTR, class = IN
------------
timeout (5 secs)
timeout (10 secs)
timeout (20 secs)
timeout (40 secs)
SendRequest failed
*** Can't find server name for address 192.249.249.3: No response from server
*** Default servers are not available
12.7.7. Unspecified Error
You can run into a rather unsettling problem called an "unspecified error." We have an example of this error here. We've included only the tail end of the output, since we just want to talk about the error at this point (you'll find the whole nslookup session that produced this segment in Chapter 14, "Troubleshooting DNS and BIND"):
What happened here is that there was too much data to fit into a UDP datagram. The name server stopped filling in the response when it ran out of room. The name server didn't set the truncation bit in the response packet, or nslookup would have retried the query over a TCP connection; the name server must have decided that enough of the "important" information fit. You won't see this kind of error very often. You'll see it if you create too many NS records for a zone, so don't create too many. (Advice like this makes you wonder why you bought this book, right?) How many is "too many" depends on how well the domain names in the packet can be "compressed," which, in turn, depends on how many name servers' names end in the same domain name. The root name servers were renamed to end in root-servers.net for this very reason -- this allows more root name servers (13) on the Internet. As a rule of thumb, don't go over 10 NS records. As for what caused this error, you'll just have to read Chapter 14, "Troubleshooting DNS and BIND". Those of you who just read Chapter 9, "Parenting", may know already.Authoritative answers can be found from: (root) nameserver = NS.NIC.DDN.MIL (root) nameserver = B.ROOT-SERVERS.NET (root) nameserver = E.ROOT-SERVERS.NET (root) nameserver = D.ROOT-SERVERS.NET (root) nameserver = F.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET (root) nameserver = *** Error: record size incorrect (1050690 != 65519) *** relay.hp.com can't find .: Unspecified error
|  | |
| 12.6. Less Common Tasks |  | 12.8. Best of the Net |
