nslookup flaws
Nathan Jones
Personally, I loathe nslookup and don't use it. Unfortunately a few
colleagues are yet to make the transition to dig (and host).
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?
--
nathanj
Barry Margolin
Nathan Jones <nat...@kmail.com.au> wrote:
>I believe there are problems with nslookup, but I'm having trouble
>finding out specifically what they are.
Off the top of my head:
1. Its error messages are imprecise. In particular, you get "Nonexistent
host/domain" when either the name doesn't exist (dig reports "status:
NXDOMAIN") or when the name exists but doesn't have any records of the
requested type (dig reports "status: NOERROR" and "ANSWER: 0").
2. When it displays results, you can't tell what section they're in. So
it looks like you asked for an A record and for some reason the server
responded with an SOA record instead (this is actually the SOA record
that gets put into the Authority section of a negative response, in
order to provide a negative cache TTL).
3. It automatically implements the search list by default. Debugging
utilities should do just what you ask, not apply lots of automatic
extras.
4. Its stupid requirement that the server be able to reverse-resolve its
own address. If a server is non-recursive and not hosting its own
reverse domain, it won't be able to do this, and nslookup will think
that it's a broken server and skip over it.
--
Barry Margolin, bar...@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.
Brad Knowles
At 12:10 PM +1000 7/6/01, Nathan Jones wrote:
> 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.
--
Brad Knowles, <brad.k...@skynet.be>
/* efdtt.c Author: Charles M. Hannum <ro...@ihack.net> */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers */
/* */
/* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */
/* where title-key = "153 2 8 105 225" or other similar 5-byte key */
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
Barry Margolin
Brad Knowles <brad.k...@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.
Jonathan de Boyne Pollard
NJ> I believe there are problems with nslookup, but I'm having
NJ> trouble finding out specifically what they are.
NJ> Can someone here point me in the right direction?
http://cr.yp.to/djbdns/faq/tinydns.html#nslookup
http://homepages.tesco.net./~J.deBoynePollard/FGA/nslookup-daft-error-message.html