Is there any reason to use dig versus nslookup?

[Tony Williams]

We have just updated HP-UX with BIND 9..2.0. Is there any reason to use dig versus nslookup?

[James R. Ferguson]

Hi Tony:

I suppose it depends on what you want to do. The 'dig' tool heralds from Linux and is purported to be more flexible than 'nslookup' in its capabilities.

Regards!

...JRF...

[Tony Williams]

Thanks James,

I had heard that there are problems with nslookup and that it shouldn't be used and I was hoping someone had intimate knowledge of whether the problems exist or not. I found this from Google but it doesn't help much:

I believe there are problems with nslookup, but I'm having trouble finding out specifically what they are.
Can someone here point me in the right direction?

For starters:

1. nslookup requires that reverse DNS be configured for the nameservers listed in /etc/resolv.conf. If you've got a DNS problem, that's just as likely to affect your ability to serve reverse DNS as it is anything else, so when you most need nslookup to work, is when it is mostly likely to fail.

2. Even with all debugging options turned on, nslookup doesn't show you everything that's going on with the query, or all the data returned.

3.Most vendor-supplied versions of nslookup have been hacked to by-pass the DNS and to include resolution involving things like /etc/hosts, NIS, etc.... This just confuses the issues. Sometimes there are times when you want to debug these non-DNS name services, but nslookup should not be doing this without your requesting it to do so.

4.Even when querying just the DNS, nslookup by-passes the standard resolver routines, so when nslookup does a query, that's not following the same code path as when a program does a query, and therefore using nslookup may not tell you anything about where the problem may be -- nslookup may work fine when the program doesn't, or nslookup may fail when the program works fine.

5. nslookup's timeout/retry algorithm is different from the resolver's. When there are multiple nameservers /etc/resolv.conf, the resolver queries them in the order ABCABCABC..., but nslookup uses the order AAA...BBB...CCC.... And once it gets a response from a server, it locks onto that one for the rest of the session (or until you use the "server" command to select a server explicitly).

[Tony Williams]

From Jonathan de Boyne Pollard:
You've come to this page because you've used nslookup.
This is the Frequently Given Answer to such usage.

(You can find a different approach to this answer on Will Yardley's nslookup flaws page.)

You are using nslookup. Don't.

nslookup is badly designed. It's a very poor tool for several reasons. It has been widely acknowledged for several years that it is a bad tool. Even the company that writes BIND states that nslookup is deprecated and may be removed from future releases of BIND. (Even though your particular operating system vendor may have packaged it separately, nslookup is in fact a diagnostic tool that is a part of the BIND package.)

Stop using nslookup right now. Start using better, less flawed, tools instead. Almost every DNS server software package comes bundled with tools to manually query the DNS for diagnostic purposes. Use the tools that came with the package that you have.

Even BIND itself comes with better tools. The company that writes BIND has in fact rewritten nslookup for BIND version 9.x . It no longer contains one of the daft design flaws. But it also no longer contains some of the functionality of the original tool, and prints a prominent warning message every time that it is invoked stating a BIND-centric version of what this page recommends - i.e. that one should stop using nslookup in favour of host and dig.

The flaws in nslookup
Here are several of the more major flaws in nslookup.

nslookup performs hidden queries and prints a daft error message.
This daft design flaw in nslookup is threefold:

Before performing the query that you actually instructed it to perform, nslookup performs other, hidden, queries. One of these is a reverse lookup on the IP address of the server that it is sending the query to. It prints the result as the name of the server.

This query is pointless. You gave nslookup that IP address yourself, either indirectly by specifying a domain name or directly by supplying an explicit IP address, when you told it what server to query. If you specified the server by name, nslookup is just wasting its time trying to turn the IP address back into a name. It already has the name that yielded the IP address in the first place. If you specified the server by IP address, nslookup has no business assuming either that you are interested in the reverse mapping of that IP address to a domain name (If you were, you would have issued the query explicitly. You are invoking a tool that performs DNS queries, after all.) or that such a reverse mapping even exists at all (There is no requirement for it to exist. Not all IP addresses need have domain names associated with them.).

A far better design would simply use the information that you told it to use exactly as it stands, without trying to be "helpful" when repeating it back to you.

nslookup has its own internal DNS client. Unfortunately, it uses this for every query that it makes. This includes the reverse lookup on the IP address of the current server. This means that nslookup sends the "PTR" query for the inverse lookup to the very server whose IP address is being looked up.

It has no business doing this. There's no justification whatsoever for the assumption that every content DNS server serves up the reverse lookup domain for the IP address on which it happens to be listening.

A far better design would perform the reverse lookup through the ordinary system-wide DNS client library, and your ordinary proxy DNS servers.

If the reverse lookup fails, nslookup prints an error message:

*** Can't find server name for address 10.0.0.1: ...
*** Default servers are not available


If it continues, you should consider yourself lucky. Most flavours of nslookup simply abort at this point, without performing the query that they were actually instructed to perform at all.

nslookup uses its own internal DNS client.
nslookup doesn't use the system-wide DNS client libraries that everything else uses for name and address lookups (usually the BIND DNS client library). It has its own internal DNS client, allowing it to explicitly control things such as the search path, target server, recursion desired flag, and so forth. However, several of the aspects of nslookup's internal DNS client are different to the system-wide DNS client libraries:

nslookup's timeout/retry algorithm is different to that of the BIND DNS client library. When multiple proxy DNS servers are listed in /etc/resolv.conf, the BIND DNS client library tries all of them at each timeout value before proceeding to a longer timeout value. nslookup's client library, in contrast, tries all timeout values against a single proxy DNS server before proceeding to the next. (In other words: The BIND DNS client library uses the order "ABCABCABC..." whereas nslookup's DNS client uses the order "AAA...BBB...CCC...".)

Once nslookup receives a response from a proxy DNS server, it locks on to that server for the remainder of the session (or until the server command is used). The BIND DNS client library tries all configured proxy DNS servers every time, and doesn't remember which proxy DNS server to use from one lookup to the next.

nslookup doesn't show the actual response.
By default, nslookup prints its interpretation of the responses that it receives, rather than the raw response. This interpretation is often misleading. For example: nslookup interprets a partial answer ending in a referral as "no answer".

Even with all of its debugging options turned on, nslookup doesn't display all of the content of the responses that it receives.

nslookup is sometimes modified by the reseller to do non-DNS things.
BIND and its tools, including nslookup, are often bundled with the operating system by the vendor. Several vendors supply versions of BIND and its tools that the vendor has made modifications to. These vendors supply their own modified versions of nslookup that "for convenience" bypass the DNS and use extraneous sources of information such as /etc/hosts and NIS.

Such modifications make nslookup unsuitable as a tool for DNS problem diagnosis, since one cannot determine whether a problem that (such a modified version of) nslookup reports is a DNS problem or a problem with performing lookups using one of the other sources of information.

[Thomas J. Harrold]

I manage a lot of different O/S types, and nslookup is the only tool that I can guarantee will be there.

I have started using "dig" and "host", when available. (since I've started installing bind 9 on any DNS servers)

Some people tend to get a bit religious about certain tools. I try not to.

I use what works in order to get my job done.

-tjh

[Geoff Wild]

# nslookup
Note: nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead. Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
> exit


That's the main reason to use dig - as nslookup is "fading away" :)

I prefer dig - just take a bit getting used to it.


Rgds...Geoff