Dig I

Dig I
One of the most useful software tools for studying name server
operation is called Dig, which stands for Domain Information Groper.
Basically, this program submits DNS queries and presents the
results in a human-readable format.
Let's examine several examples of DIG usage.

Dig output begins with information about the command issued and
the name server(s) used, then prints the resolver flags in use,
then decodes the DNS message received back as an answer.
After printing the header fields and flags, the question is printed,
followed by the answer, authority records, and additional records
sections. Each of these sections contains zero or more resource
records, which are printed in a human-readable format, beginning
with the domain name, then the Time To Live, then the type code,
and finally the data field. Finally, summary information
is printed about how long the exchange required.

The main argument in this Dig request is FreeSoft.org,
the domain name we are going to lookup. The first argument,
@ns.adnc.com is optional and specifies a name server
to use (normally the system default is chosen). The
last argument specifies a Query Type, in this case
for mail exchanger (MX) records. This argument is also
optional, and defaults to address (A) RRs. Dig has
numerous other options; see its man page for details.

Let's go through this line by line, as they've been numbered for
your convenience (normally no numbers appear). The first
two lines repeat the arguments back to us and tell us that
the standard DNS lookup on the server succeeded. If Dig
hangs after printing the first line, there may be a failure
in your local DNS configuration; try replacing
ns.adnc.com with an IP address.

Next we see the resolver options, which are documented in
BIND's resolver(3) man page. Starting on line 5,
we see the various header options from the reply. The various
fields and flags are documented in
RFC 1035 §4.1.1.

Now comes the various resource records. The answer (line 11) is
what we asked for. The authority records (line 14-15) inform
us that this name server (ns.adnc.com)
is authoritative for this record, as is ns2.adnc.com.
Not surprisingly, we note that the AA bit was set as
a flag (line 6). The additional records (lines 18-19) give
the IP address of the name servers.

Finally, we get timing stats (line 21), an indication of the
foreign DNS and IP addresses (line 22), a timestamp (line 23),
and the sizes of the request and reply (line 24).

Knowing from the previous request that mail.adnc.com is
the only mail exchanger for the FreeSoft.org domain,
we now request the IP address of this host. Note that no
type argument is required, as IP address lookup
(A RRs) is the default.

I read this output as follows:
mail.adnc.com is an alias for gemini.adnc.com,
whose IP address is 205.216.138.22. The authority
section is somewhat interesting, since ns.adnc.com
does not appear to be authoriative for its own domain!
But line 6 shows the Authoritative Answer (AA) bit set in the header,
indicating that this is not a cached entry, but one that
comes directly from an authoritative name server! Since we
asked ns.adnc.com, and line 25 confirms that that's
the server we were talking to, something seems a bit wierd here.
Let's investigate further.

A few things are different about this last exchange.
First, instead of specifying a name server in the command,
I used the default local name server. Second, the answer I
got back was not authoritative (no AA bit in line 3),
so it was cached. Line 8 shows a lower TTL value than the
86400s in the authorative answer. Repeating the query
will show the TTL value dropping as the cached record ages.
We can't tell from this listing exactly where the entry was cached.
If I wanted to know this, I would repeat the query with
recursion disabled and step through the name server tree manually.
Note, however, that my local name server has almost certainly
cached the record itself at this point - as has every name server
that handled the record during the exchange.

This reply answers the original question - why isn't ns.adnc.com
listed as a name server for its own domain? The answer is that
it is listed - in a way. Note that ns's IP address
of 205.216.138.22 is the same as gemini.adnc.com,
which was listed as a name server. The two are, in
fact, the same host, since they have the same IP address.

We also got nine authority records for the Internet root name servers,
and nine additional address records to go along with them.
This is a product of my local name server configuration, which
sends all requests first to my Internet service provider's
name server.
In general, I suggest configuring
leaf name servers in this manner - just pass the request on to
the next name server up, hoping for a cache hit.
However, since adnc.com is in a different domain than
my ISP, its name server decided that mine should have asked the
root name servers for information about adnc.com
(since that's what it had to do), and passed along authority
information with that "suggestion".

Just for informative value, I had a
TCPdump running on my PPP link during the last Dig exchange.
Here's part of what I saw
(note that I increased the snarf length with the -s flag
to decode as much of the message as possible):

My local name server (which handled the Dig request, remember?) passed
the question on to skipper.netrail.net, my Internet
service provider's name server.
The query ID
is 21213, and the + indicates that recursion was requested.
All this is documented in the
TCPdump Manual Page.
A? indicates that the packet is a question for an address (A)
record for nn.adnc.com.
The next packet is the reply - or actually, the first packet of the reply,
which was so big it had to be fragmented (because of the 18 extra RRs
for the various root name servers). 1/9/9 indicates
one answer, nine authority records, and nine additional records.
The answer is also shown - an A record containing
205.216.138.22.