root servers list changing?

[Mark Damrose]

"Matthew Hannigan" <mlh at zip.com.au> wrote in message
news:ain0s2$bods$1 at isrv4.isc.org...
>
> >
> > Nslookup is a bad command, for many reasons, and you should use "dig"
for
> > all command line DNS lookups unless you prefer "host" which is less
general
> > but more friendly.
>
> I've read that often enough but it's still not clear to me why
> dig is so much better.  Certainly the output is still fairly cryptic
> and messy.
>

nslookup fails as a DNS testing tool in a couple of important ways.

First, it behaves like a client resolver - trying the search path if the
original question is not found.  e.g.  your machine is located in domain
x.com and you ask about host.y.com.  If host.y.com is not found it will try
host.y.com.x.com.  If that is also not found nslookup will respond with a
failure about host.y.com.x.com - which is confusing to a lot of people.  If
x.com happens to have a global record, you could even get a success where
you should have gotten a failure and you might not notice that answer was
different than the question you asked.

2nd, it does a lookup of the in-addr record for the server before it will do
the query you specified.  If the in-addr record is not present, nslookup
will bomb.  The error message it gives is very misleading, and if you
haven't encountered it before it will send you looking for other problems.
Personally I feel that your testing tool should not rely on DNS being set up
correctly.  Testing to see if DNS is set up correctly is the whole point of
having a tool.

On the other hand, a lot of the cryptic and messy information that dig
supplies is quite useful once you get to know it.

;; flags: qr aa rd ra;

shows you the flags that were set in the response.
qr - this is a query response.
aa - the server claims it is giving an authoritive answer.  If you have a
server that was supposed to be a master or slave and didn't have this bit
set, you would know it was misconfigured and answering from cache.  That's a
lot harder to see with nslookup.
rd - recursion desired, the query was made requesting recursion.
ra - recursion available, the server will do recursion for you.

dig shows you the answer to your query, the list of authoritive servers and
any additional records that were returned - e.g. A records returned along
with an MX query.  nslookup only shows you the answer to your specific
question and the server that you used.

dig shows you the TTL value of the records - again giving you a clue about a
misconfigured server.  If the TTL is decrementing when you are supposed to
be getting an authoritive answer you can quickly spot a problem.

dig allows you to specify tcp or udp, request with or without recursion, and
many other things which allow you fine grain control of your testing.  It is
very much a tool worth learning.