Connected: An Internet Encyclopedia
Dig I

Up: Connected: An Internet Encyclopedia
Up: Programmed Instruction Course
Up: Section 2 - Domain Naming
Prev: The DNS Protocol
Next: Dig II

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, the domain name we are going to lookup. The first argument, 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 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 ( is authoritative for this record, as is 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 is the only mail exchanger for the 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

[1]  ; <<>> DiG 2.1 <<>> 
[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]  ;;, type = A, class = IN
[10] ;; ANSWERS:
[11]  86400   CNAME
[12]        86400   A
[15]       86400   NS
[16]       86400   NS
[17]       86400   NS
[20]        86400   A
[21]        86400   A
[22]     161123  A
[24] ;; Total query time: 310 msec
[25] ;; FROM: tower to SERVER:
[26] ;; WHEN: Tue Mar 19 20:33:00 1996
[27] ;; MSG SIZE  sent: 31  rcvd: 183

I read this output as follows: is an alias for, whose IP address is The authority section is somewhat interesting, since 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, 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

[1]  ; <<>> DiG 2.0 <<>> 
[2]  ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6
[3]  ;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 9, Addit: 9
[4]  ;; QUESTIONS: 
[5]  ;;, type = A, class = IN
[7]  ;; ANSWERS:
[8]    54654   A
[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.
[22] A.ROOT-SERVERS.NET.     520206  A
[23] H.ROOT-SERVERS.NET.     520206  A
[24] B.ROOT-SERVERS.NET.     520206  A
[25] C.ROOT-SERVERS.NET.     520206  A
[26] D.ROOT-SERVERS.NET.     520206  A
[27] E.ROOT-SERVERS.NET.     520206  A
[28] I.ROOT-SERVERS.NET.     520206  A
[29] F.ROOT-SERVERS.NET.     520206  A
[30] G.ROOT-SERVERS.NET.     520210  A
[32] ;; Sent 1 pkts, answer found in time: 330 msec 
[33] ;; FROM: vyger to SERVER: default --
[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 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 is the same as, 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 is in a different domain than my ISP, its name server decided that mine should have asked the root name servers for information about (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 >
   21213+ A? (29)
16:38:22.072951 >
   21213 1/9/9 A (160) (frag 36540:168@0+)

My local name server (which handled the Dig request, remember?) passed the question on to, 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 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

Next: Dig II

Connected: An Internet Encyclopedia
Dig I