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.
tower:~$ dig @ns.adnc.com FreeSoft.org mx  ; <<>> DiG 2.1 <<>> @ns.adnc.com FreeSoft.org mx  ; (1 server found)  ;; res options: init recurs defnam dnsrch  ;; got answer:  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10  ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 2, Addit: 2  ;; QUESTIONS:  ;; FreeSoft.org, type = MX, class = IN   ;; ANSWERS:  FreeSoft.org. 86400 MX 100 mail.adnc.com.   ;; AUTHORITY RECORDS:  FreeSoft.org. 86400 NS ns.adnc.com.  FreeSoft.org. 86400 NS ns2.adnc.com.   ;; ADDITIONAL RECORDS:  ns.adnc.com. 86400 A 18.104.22.168  ns2.adnc.com. 86400 A 22.214.171.124   ;; Total query time: 464 msec  ;; FROM: tower to SERVER: ns.adnc.com 126.96.36.199  ;; WHEN: Tue Mar 19 20:31:58 1996  ;; MSG SIZE sent: 30 rcvd: 126
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.
tower:~$ dig @ns.adnc.com mail.adnc.com  ; <<>> DiG 2.1 <<>> @ns.adnc.com mail.adnc.com  ; (1 server found)  ;; res options: init recurs defnam dnsrch  ;; got answer:  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10  ;; flags: qr aa rd ra; Ques: 1, Ans: 2, Auth: 3, Addit: 3  ;; QUESTIONS:  ;; mail.adnc.com, type = A, class = IN   ;; ANSWERS:  mail.adnc.com. 86400 CNAME gemini.adnc.com.  gemini.adnc.com. 86400 A 188.8.131.52   ;; AUTHORITY RECORDS:  adnc.com. 86400 NS gemini.adnc.com.  adnc.com. 86400 NS taurus.adnc.com.  adnc.com. 86400 NS ns.mci.net.   ;; ADDITIONAL RECORDS:  gemini.adnc.com. 86400 A 184.108.40.206  taurus.adnc.com. 86400 A 220.127.116.11  ns.mci.net. 161123 A 18.104.22.168   ;; Total query time: 310 msec  ;; FROM: tower to SERVER: ns.adnc.com 22.214.171.124  ;; WHEN: Tue Mar 19 20:33:00 1996  ;; MSG SIZE sent: 31 rcvd: 183
I read this output as follows: mail.adnc.com is an alias for gemini.adnc.com, whose IP address is 126.96.36.199. 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.
5 vyger> dig ns.adnc.com  ; <<>> DiG 2.0 <<>> ns.adnc.com  ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6  ;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 9, Addit: 9  ;; QUESTIONS:  ;; ns.adnc.com, type = A, class = IN   ;; ANSWERS:  ns.adnc.com. 54654 A 188.8.131.52   ;; AUTHORITY RECORDS:  . 453829 NS A.ROOT-SERVERS.NET.  . 453829 NS H.ROOT-SERVERS.NET.  . 453829 NS B.ROOT-SERVERS.NET.  . 453829 NS C.ROOT-SERVERS.NET.  . 453829 NS D.ROOT-SERVERS.NET.  . 453829 NS E.ROOT-SERVERS.NET.  . 453829 NS I.ROOT-SERVERS.NET.  . 453829 NS F.ROOT-SERVERS.NET.  . 453829 NS G.ROOT-SERVERS.NET.   ;; ADDITIONAL RECORDS:  A.ROOT-SERVERS.NET. 520206 A 184.108.40.206  H.ROOT-SERVERS.NET. 520206 A 220.127.116.11  B.ROOT-SERVERS.NET. 520206 A 18.104.22.168  C.ROOT-SERVERS.NET. 520206 A 22.214.171.124  D.ROOT-SERVERS.NET. 520206 A 126.96.36.199  E.ROOT-SERVERS.NET. 520206 A 188.8.131.52  I.ROOT-SERVERS.NET. 520206 A 184.108.40.206  F.ROOT-SERVERS.NET. 520206 A 220.127.116.11  G.ROOT-SERVERS.NET. 520210 A 18.104.22.168   ;; Sent 1 pkts, answer found in time: 330 msec  ;; FROM: vyger to SERVER: default -- 127.0.0.1  ;; WHEN: Fri Sep 6 16:38:22 1996  ;; MSG SIZE sent: 29 rcvd: 340
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 22.214.171.124 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):
39 vyger# tcpdump -s512 -i ppp0 udp port domain tcpdump: listening on ppp0 16:38:21.817066 ppp-blt-1-03.netrail.net.domain > skipper.netrail.net.domain: 21213+ A? ns.adnc.com. (29) 16:38:22.072951 skipper.netrail.net.domain > ppp-blt-1-03.netrail.net.domain: 21213 1/9/9 A 126.96.36.199 (160) (frag 36540:168@0+)
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 188.8.131.52.