|
|
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 [1] ; <<>> DiG 2.1 <<>> @ns.adnc.com FreeSoft.org mx [2] ; (1 server found) [3] ;; res options: init recurs defnam dnsrch [4] ;; got answer: [5] ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 [6] ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 2, Addit: 2 [7] ;; QUESTIONS: [8] ;; FreeSoft.org, type = MX, class = IN [9] [10] ;; ANSWERS: [11] FreeSoft.org. 86400 MX 100 mail.adnc.com. [12] [13] ;; AUTHORITY RECORDS: [14] FreeSoft.org. 86400 NS ns.adnc.com. [15] FreeSoft.org. 86400 NS ns2.adnc.com. [16] [17] ;; ADDITIONAL RECORDS: [18] ns.adnc.com. 86400 A 205.216.138.22 [19] ns2.adnc.com. 86400 A 205.216.138.24 [20] [21] ;; Total query time: 464 msec [22] ;; FROM: tower to SERVER: ns.adnc.com 205.216.138.22 [23] ;; WHEN: Tue Mar 19 20:31:58 1996 [24] ;; 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 [1] ; <<>> DiG 2.1 <<>> @ns.adnc.com mail.adnc.com [2] ; (1 server found) [3] ;; res options: init recurs defnam dnsrch [4] ;; got answer: [5] ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 [6] ;; flags: qr aa rd ra; Ques: 1, Ans: 2, Auth: 3, Addit: 3 [7] ;; QUESTIONS: [8] ;; mail.adnc.com, type = A, class = IN [9] [10] ;; ANSWERS: [11] mail.adnc.com. 86400 CNAME gemini.adnc.com. [12] gemini.adnc.com. 86400 A 205.216.138.22 [13] [14] ;; AUTHORITY RECORDS: [15] adnc.com. 86400 NS gemini.adnc.com. [16] adnc.com. 86400 NS taurus.adnc.com. [17] adnc.com. 86400 NS ns.mci.net. [18] [19] ;; ADDITIONAL RECORDS: [20] gemini.adnc.com. 86400 A 205.216.138.22 [21] taurus.adnc.com. 86400 A 205.216.138.24 [22] ns.mci.net. 161123 A 204.70.128.1 [23] [24] ;; Total query time: 310 msec [25] ;; FROM: tower to SERVER: ns.adnc.com 205.216.138.22 [26] ;; WHEN: Tue Mar 19 20:33:00 1996 [27] ;; 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 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.
5 vyger> dig ns.adnc.com [1] ; <<>> DiG 2.0 <<>> ns.adnc.com [2] ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 [3] ;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 9, Addit: 9 [4] ;; QUESTIONS: [5] ;; ns.adnc.com, type = A, class = IN [6] [7] ;; ANSWERS: [8] ns.adnc.com. 54654 A 205.216.138.22 [9] [10] ;; AUTHORITY RECORDS: [11] . 453829 NS A.ROOT-SERVERS.NET. [12] . 453829 NS H.ROOT-SERVERS.NET. [13] . 453829 NS B.ROOT-SERVERS.NET. [14] . 453829 NS C.ROOT-SERVERS.NET. [15] . 453829 NS D.ROOT-SERVERS.NET. [16] . 453829 NS E.ROOT-SERVERS.NET. [17] . 453829 NS I.ROOT-SERVERS.NET. [18] . 453829 NS F.ROOT-SERVERS.NET. [19] . 453829 NS G.ROOT-SERVERS.NET. [20] [21] ;; ADDITIONAL RECORDS: [22] A.ROOT-SERVERS.NET. 520206 A 198.41.0.4 [23] H.ROOT-SERVERS.NET. 520206 A 128.63.2.53 [24] B.ROOT-SERVERS.NET. 520206 A 128.9.0.107 [25] C.ROOT-SERVERS.NET. 520206 A 192.33.4.12 [26] D.ROOT-SERVERS.NET. 520206 A 128.8.10.90 [27] E.ROOT-SERVERS.NET. 520206 A 192.203.230.10 [28] I.ROOT-SERVERS.NET. 520206 A 192.36.148.17 [29] F.ROOT-SERVERS.NET. 520206 A 192.5.5.241 [30] G.ROOT-SERVERS.NET. 520210 A 192.112.36.4 [31] [32] ;; Sent 1 pkts, answer found in time: 330 msec [33] ;; FROM: vyger to SERVER: default -- 127.0.0.1 [34] ;; WHEN: Fri Sep 6 16:38:22 1996 [35] ;; 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 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):
39 vyger# tcpdump -s512 -i ppp0 udp port domain tcpdump: listening on ppp0 16:38:21.817066 ppp-blt-1-03.netrail.net.domain