D. J. Bernstein
Internet publication
djbdns

Notes on nslookup

Do not use the ancient nslookup program. Whatever you're trying to do, there's a better way to do it. Even the BIND company, which maintains and distributes nslookup, says ``nslookup is deprecated and may be removed from future releases.''

The rest of this page discusses a specific problem with nslookup: namely, the *** Default servers are not available error message.

An example of the problem

Suppose you type

     nslookup -type=soa com m.gtld-servers.net

thinking that this will give you the .com SOA records from the m.gtld-servers.net server.

nslookup says

     *** Can't find server name for address 192.55.83.30: No information
     *** Default servers are not available

instead of showing you the SOA records.

You might think that the server doesn't have the SOA records, or that the server software has some bug. In fact, the server has the SOA records, and is behaving properly. You've encountered an nslookup bug.

Easy workaround: Don't tell nslookup which server to use. It will use your local DNS cache, as specified in /etc/resolv.conf; your DNS cache will contact the appropriate DNS server. For example, to look up SOA records for the com domain:

     nslookup -type=soa com

Even better, use dnsqr instead of nslookup:

     dnsqr soa com

If you want to query a specific DNS server, use dnsq:

     dnsq soa com m.gtld-servers.net

If you want to query a specific DNS server, and you really want to use nslookup for some reason, do not specify the server on the nslookup command line. Use the server command instead:

     nslookup
     server m.gtld-servers.net
     set type=soa
     com.
     exit

When the problem occurs

In short, nslookup does not work correctly if you specify a non-recursive server on the command line.

BIND servers are recursive by default, so BIND administrators generally don't run into this problem unless they know that they should make their servers non-recursive. In contrast, tinydns is never recursive.

What exactly is nslookup doing wrong? Three things:

Before doing what you tell it to do, nslookup tries a PTR query on the server's IP address, so that it can tell you the server's name, as if this information were more useful than the name or IP address that you gave nslookup in the first place.
When you specify a server on the command line, nslookup sends its silly PTR query to that server, unjustifiably assuming that the server is recursive or already has the answer. Correct behavior would be to ask the local cache.
If the silly PTR query fails, nslookup aborts, and never does what you told it to do.

On the bright side, the silly PTR query was finally eliminated from nslookup in BIND 9.1.

If you're running tinydns, and you really want to pander to nslookup's bugs (even though the .com servers don't), add

     .200.7.8.1.in-addr.arpa:1.8.7.200

to data, and make sure that 1.8.7.200 appears in an = line. Replace 1.8.7.200 with your IP address.