nslookup flaws

[Barry Margolin]

In article <9i4lbm$7sq at pub3.rc.vix.com>,
Brad Knowles  <brad.knowles at skynet.be> wrote:
>		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.

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.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.