|
Chapter 11 nslookup |
|
|
|
Chapter 11 nslookup |
|
The last thing you want is to have problems with your troubleshooting tool. Unfortunately, some types of failures render the troubleshooting tool mostly useless. Other types of nslookup failures are, at best, confusing because they don't give you any direct information to work with. While there may be a few problems with nslookup itself, most of the problems you encounter will be with name server configuration and operation. We'll cover a few odd problems here.
This isn't really a problem, per se , but it can be awfully confusing. If you use nslookup to look up a type of data for a domain name, and the domain name exists, but no data of the type you're looking for exists, you'll get an error like this:
%nslookupDefault 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
What could have gone wrong if your server can't look up its own name?
%nslookupDefault Server: terminator.movie.edu Address: 0.0.0.0 >terminatorServer: 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 name server 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 server is 0.0.0.0, nslookup grabbed the system's host name (what the hostname command returns) for the server field and gave you its prompt. It is only when you try to look up something that you find out that there is no server responding. In this case, it is pretty obvious that there is no name 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 is still trying to look up the item 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? Use the ls command to point out the difference:
%nslookupDefault Server: terminator.movie.edu Address: 0.0.0.0 >ls foo.- Try to list a nonexistent domain *** 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:
%nslookupDefault 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 domain in your world.
Here is one of the 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" means that the name 3.249.249.192.in-addr.arpa doesn't exist. In other words, nslookup couldn't find the name for 192.249.249.3, its name server host. But didn't we just say that nslookup doesn't look up anything when it starts up? In the configuration presented before, nslookup didn't look up anything, but that's not a rule. If you create a resolv.conf that includes nameserver lines, nslookup looks up the address in order to get the name server's name. In the preceding example, there is a name server running on 192.249.249.3, but it said there is no PTR data for the address 192.249.249.3. Obviously, this name server's data is messed up, at least for the 249.249.192.in-addr.arpa zone.
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 makes sense.
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 zone security is stopping 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. At 4.9.3, support for inverse queries was dropped, which broke old nslookup s. To accommodate these old clients, a configuration file statement was added.
In BIND 4, the statement looks like this:
options fake-iquery
In BIND 8, the statement looks like this:
options { fake-iquery yes; };
This statement causes your name server to respond to the inverse query with a "fake" response that is good enough for nslookup to continue.
Zone security features can also cause nslookup startup problems. When nslookup attempts to find the name of its server (using a PTR query, not an inverse query), the query can be refused. If you think the problem is zone security, make sure your BIND 4 secure_zone TXT resource records or BIND 8 allow-transfer substatement include the network for the host running nslookup , and the address 127.0.0.1 if nslookup is running on the host also running the name server.
Zone security is not limited to causing nslookup to fail to start up. It can also cause lookups and zone transfers to fail in the middle of a session when you point nslookup to a remote name server. This is what you will see:
%nslookupDefault Server: hp.com Address: 15.255.152.4 >server terminator.movie.eduDefault 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 >
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 nameserver in resolv.conf did not respond. We had put a second nameserver line in resolv.conf , and the second server did respond. From now on, nslookup will send queries only to wormhole ; it won't try the name server at 192.249.249.3 again.
We've been waving our hands in the last examples, saying 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 packets 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 won't see anything printed to your screen for 75 seconds; it'll look as if nslookup has hung.
You can run into a rather unsettling problem called "unspecified error." We have an example of this error here. We've only included the tail end of the output, since we only want to talk about the error at this point. You'll find the whole nslookup session that produced this segment in Chapter 13, Troubleshooting DNS and BIND .
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 domain, so don't create too many. (Advice like this makes you wonder why you bought this book, right?) How many is too many depends upon how well the names can be "compressed" in the packet, which, in turn, depends upon how many name servers share the same domain in their domain name. The root name servers were renamed to all be in the root-servers.net domain for this very reason - more names fit in DNS packets if they share a common domain, which allows more root name servers to support the Internet. As a rule of thumb, don't go over 10 NS records. As for what caused this error, you'll have to read Chapter 13 . Those of you who just read Chapter 9, Parenting , may know already.
|
|
|
|
| 11.6 Less Common Tasks |
|
11.8 Best of the Net |