BIND 9.3.0rc4 is now available.

[Barry Margolin]

In article <chfgcf$26g5$1 at sf1.isc.org>, Tom Diehl <tdiehl at rogueind.com> 
wrote:

> On Sat, 5 Sep 2004, Paul Vixie wrote:
> 
> > Barry Margolin <barmar at alum.mit.edu> writes:
> > 
> > > > ...  use dig instead.  but we have to keep shipping [nslookup].
> > > 
> > > There are undoubtedly many scripts out there that use it, too.  It
> > > wouldn't be nice to break all of them just because there are better tools
> > > available (e.g. awk hasn't been deprecated just because things like Perl
> > > and Python make it redundant).
> > 
> > nslookup isn't redundant.  it's Evil.
> 
> Is there a document somewhere that gives specifics of why nslookup is evil?
> I have been told this many times by various people but I have never actually
> seen an explaination of the issues. FWIW I use dig and I am not sure I even
> remember how to use nslookup anymore but I am courious.

I don't know an official document, but here are some of the obvious 
problems.

nslookup gives misleading error messages, often conflating different 
errors into the same message.  For instance, it will tell you that a 
name doesn't exist when it really means that the name doesn't have 
records of the requested type.

It has this really annoying requirement that the server named on the 
command line (or the default server, if none was requested explicitly) 
be able to reverse-resolve its own address.  This is problematic when 
you're querying a non-recursive server that doesn't happen to host the 
reverse domain containing its address.

It doesn't distinguish the sections that records appear in.

Some of these problems can be worked around by enabling its debugging 
mode, so that it shows the decoded queries and responses.  But these are 
much more verbose than dig, providing little extra information (it's 
actually the same as using dig's +debug option).

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***