** Note **

I did not write this post - I just stuck it up here some time back.  For
some reason, it seems that people have linked to it, so I'm hesitant to
take it down entirely. It's probably wiser to link to the original post
from the BIND newsgroup / mailing list archives.

http://groups.google.com/group/comp.protocols.dns.bind/msg/6de73c9eaa37137f

-wby, 10.19.2005

Original text follows...

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

        I'm sure others on the list can add to these items.



That reminds me of another one:

5. nslookup's timeout/retry algorithm is different from the resolver's.
   When there are multiple nameservers in /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).

The DNS & BIND book says this is a feature, "you *want* your
troubleshooting tool to talk only with one name server, so you can
reduce
the number of variables when analyzing a problem."  IMHO, if you're
debugging a particular server you'll usually use the "server" command to
lock onto that server (just as with dig you'll use "@<server>"); if you
don't select a server manually, the tool is being used as a
general-purpose
query tool and should follow the normal retry algorithm.