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:

% nslookup
Default Server:  terminator.movie.edu
Address:  0.0.0.0

> movie.edu.

*** No address (A) records available for movie.edu.

So what types of records do exist? Just set type=any to find out:

> 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.66

12.7.2 No Response from Server

What could have gone wrong if your name server can't look up its own name?

% 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

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

 > ls foo.      —Try to list a nonexistent zone
*** Can't list domain foo.: 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.
[terminator.movie.edu]
*** Can't list domain foo.: No information

That is, unless there's a top-level foo zone in your world.

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:

% nslookup

*** Can't find server name for address 192.249.249.3: Non-existent host/domain
*** Default servers are not available

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.

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:

% nslookup
*** Can't find server name for address 192.249.249.3: Query refused
*** Default servers are not available
%

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.

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:

options fake-iquery

In BIND 8, the statement looks like this:

options { fake-iquery yes; };

(BIND 9 doesn't support fake-iquery as of 9.1.0.)

This causes your name server to respond to the inverse query with a "fake" response that is good enough to let nslookup continue.^[5]

^[5] 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:

% 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

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.

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

As you can see by the timeouts, it took 75 seconds for nslookup to give up. Without the debugging output, you wouldn't have seen anything printed to the screen for 75 seconds; it'd look as if nslookup had hung.

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):

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

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. Those of you who just read Chapter 9, may know already.