DekGenius.com
I l@ve RuBoard Previous Section Next Section

12.9 Using dig

That's one way to deal with what's arguably a shortcoming in nslookup . Another is just to chuck nslookup and use dig, the Domain Information Groper (a reverse-engineered acronym if we've ever heard one).

We said earlier that dig isn't as pervasive as nslookup, so we'd better begin by telling you where to get it. You can pick up source for dig from the tools directory (BIND 4), src/bin/dig directory (BIND 8), or bin/dig directory (BIND 9) of the BIND distribution. If you build the whole distribution, you'll build a nice, new copy of dig, too.

With dig, you specify all aspects of the query you'd like to send on the command line; there's no interactive mode. You specify the domain name you want to look up as an argument, and the type of query you want to send (e.g., a for address records, mx for MX records) as another argument; the default is to look up address records. You specify the name server you'd like to query after an "@." You can use either a domain name or an IP address to designate a name server. The default is to query the name servers in resolv.conf.

dig is smart about arguments, too. You can specify the arguments in any order you like, and dig will figure out that mx is probably the type of records, not the domain name, you want to look up.[6]

[6] Actually, early BIND 9 versions of dig (before 9.1.0) are order-impaired and require that you specify the domain name argument before the type. You can specify the server to query anywhere, though.

One major difference between nslookup and dig is that dig doesn't apply the search list, so always use fully qualified domain names as arguments to dig. So:

% dig plan9.fx.movie.edu

looks up address records for plan9.fx.movie.edu using the first name server in resolv.conf, while:

% dig acmebw.com mx

looks up MX records for acmebw.com on the same name server, and:

% dig @wormhole.movie.edu. movie.edu. soa

queries wormhole.movie.edufor the SOA record of movie.edu.

12.9.1 dig's Output Format

dig shows you the complete DNS response message in all its glory, with the various sections (header, question, answer, authority, and additional) clearly called out, and with resource records in those sections printed in master file format. This can come in handy if you need to use some of your troubleshooting tool's output in a zone data file or in your root hints file. For example, the output produced by:

% dig @a.root-servers.net ns .

looks like this:

; <<>> DiG 8.3 <<>> @a.root-servers.net . ns 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;;      ., type = NS, class = IN

;; ANSWER SECTION:
.                       6D IN NS        A.ROOT-SERVERS.NET.
.                       6D IN NS        H.ROOT-SERVERS.NET.
.                       6D IN NS        C.ROOT-SERVERS.NET.
.                       6D IN NS        G.ROOT-SERVERS.NET.
.                       6D IN NS        F.ROOT-SERVERS.NET.
.                       6D IN NS        B.ROOT-SERVERS.NET.
.                       6D IN NS        J.ROOT-SERVERS.NET.
.                       6D IN NS        K.ROOT-SERVERS.NET.
.                       6D IN NS        L.ROOT-SERVERS.NET.
.                       6D IN NS        M.ROOT-SERVERS.NET.
.                       6D IN NS        I.ROOT-SERVERS.NET.
.                       6D IN NS        E.ROOT-SERVERS.NET.
.                       6D IN NS        D.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.     6D IN A         198.41.0.4
H.ROOT-SERVERS.NET.     6D IN A         128.63.2.53
C.ROOT-SERVERS.NET.     6D IN A         192.33.4.12
G.ROOT-SERVERS.NET.     6D IN A         192.112.36.4
F.ROOT-SERVERS.NET.     6D IN A         192.5.5.241
B.ROOT-SERVERS.NET.     6D IN A         128.9.0.107
J.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.10
K.ROOT-SERVERS.NET.     5w6d16h IN A    193.0.14.129
L.ROOT-SERVERS.NET.     5w6d16h IN A    198.32.64.12
M.ROOT-SERVERS.NET.     5w6d16h IN A    202.12.27.33
I.ROOT-SERVERS.NET.     6D IN A         192.36.148.17
E.ROOT-SERVERS.NET.     6D IN A         192.203.230.10
D.ROOT-SERVERS.NET.     6D IN A         128.8.10.90

;; Total query time: 116 msec
;; FROM: terminator.movie.edu to SERVER: a.root-servers.net  198.41.0.4
;; WHEN: Fri Sep 15 09:47:26 2000
;; MSG SIZE  sent: 17  rcvd: 436

Let's examine this output section by section.

The first line, beginning with the master file comment character (;) and <<>> DiG 8.3 <<>>, simply parrots the options we specified in the command line, namely, that we were interested in the NS records that a.root-servers.net had for the root zone.

The next line, (1 server found), tells us that when dig looked up the addresses associated with the domain name we specified after the "@", a.root-servers.net, it found one. (If dig finds more than three, the maximum number of name servers most resolvers can query, it'll report three.)

The line beginning with ->> HEADER <<- is the first part of the header of the reply message that dig received from the remote name server. The opcode in the header is always QUERY, just as it is with nslookup. The status is NOERROR; it can be any of the statuses mentioned earlier in this chapter under Section 12.6.1. The ID is the message ID, a 16-bit number used to match responses to queries.

The flags tell us a bit more about the response. qr indicates that the message was a response, not a query. dig decodes responses, not queries, so qr will always be present. Not so with aa or rd, though. aa indicates that the response was authoritative, and rd indicates that the recursion desired bit was set in the query (since the responding name server just copies the bit from the query to the response). Most of the time rd is set in the query, you'll also see ra set in the response, indicating that recursion was available from the remote name server. However, a.root-servers.net is a root name server and has recursion disabled, like we showed you in Chapter 11, so it handles recursive queries the same as it does iterative queries. So it ignores the rd bit and correctly indicates that recursion wasn't available by leaving ra unset.

The last fields in the header indicate that dig asked one question and received 13 records in the answer section, zero records in the authority section, and 13 records in the additional data section.

The line after the line that contains QUERY SECTION: shows us the query dig sent: for the NS records in the IN class for the root zone. After ANSWER SECTION:, we see the 13 NS records for the root name servers, and after ADDITIONAL SECTION:, we have the 13 A records that correspond to those 13 root name servers. If the response had included an authority section, we'd have seen that, too, after AUTHORITY SECTION:.

At the very end, dig includes summary information about the query and response. The first line shows you how long it took the remote name server to return the response after dig sent the query. The second line shows you from which host you sent the query and to which name server you sent it. The third line is a timestamp showing when the response was received. And the fourth line shows you the size of the query and the response, in bytes.

12.9.2 Zone Transfers with dig

As with nslookup, you can use dig to initiate zone transfers. Unlike nslookup, though, dig has no special command to request a zone transfer. Instead, you simply specify axfr (as the query type) and the domain name of the zone as arguments. Remember that you can only transfer a zone from a name server that's authoritative for the zone.

So to transfer the movie.edu zone from wormhole.movie.edu, you could use:

$ dig @wormhole.movie.edu movie.edu axfr

; <<>> DiG 8.3 <<>> @wormhole.movie.edu movie.edu axfr 
; (1 server found)
$ORIGIN movie.edu.
@                       1D IN SOA       terminator al.robocop (
                                        2000091402      ; serial
                                        3H              ; refresh
                                        1H              ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

                        1D IN NS        terminator
                        1D IN NS        wormhole
                        1D IN NS        outland.fx
outland.fx              1D IN A         192.253.254.3
wormhole                1D IN A         192.249.249.1
                        1D IN A         192.253.253.1
wh249                   1D IN A         192.249.249.1
robocop                 1D IN A         192.249.249.2
bigt                    1D IN CNAME     terminator
cujo                    1D IN TXT       "Location:" "machine" "room" "dog" "house"
wh253                   1D IN A         192.253.253.1
wh                      1D IN CNAME     wormhole
shining                 1D IN A         192.253.253.3
terminator              1D IN A         192.249.249.3
localhost               1D IN A         127.0.0.1
fx                      1D IN NS        bladerunner.fx
bladerunner.fx          1D IN A         192.253.254.2
fx                      1D IN NS        outland.fx
outland.fx              1D IN A         192.253.254.3
dh                      1D IN CNAME     diehard
carrie                  1D IN A         192.253.253.4
diehard                 1D IN A         192.249.249.4
misery                  1D IN A         192.253.253.2
@                       1D IN SOA       terminator al.robocop (
                                        2000091402      ; serial
                                        3H              ; refresh
                                        1H              ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

;; Received 25 answers (25 records).
;; FROM: terminator.movie.edu to SERVER: wormhole.movie.edu
;; WHEN: Fri Sep 22 11:02:45 2000

Note that as with nslookup, the SOA record appears twice, at the beginning and the end of the zone. And as with all dig output, the results of the zone transfer are printed in master file format, so you can use the output as a zone data file if you need to.[7]

[7] Though you'd need to delete the extra SOA record first.

12.9.3 dig Options

There are too many command-line options to dig to show here, so look at dig 's manual page for an exhaustive list. Here's a list of the most important ones, though, and what they do:

-x address

nslookup is smart enough to recognize an IP address and look up the appropriate domain name in in-addr.arpa, so why not dig? If you use the -x option, dig assumes that the domain name argument you've specified is really an IP address, so it inverts the octets and tacks on in-addr.arpa. Using -x also changes the default record type looked up to ANY, so you can reverse map an IP address with dig -x 10.0.0.1.

-p port

Send queries to the specified port instead of port 53, the default.

+norec[urse]

Turn off recursion (recursion is on by default).

+vc

Send TCP-based queries (queries are UDP by default).

    I l@ve RuBoard Previous Section Next Section