 |  |
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.[98]
[98]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:
looks up address records for plan9.fx.movie.edu using the first name server in resolv.conf, while:% dig plan9.fx.movie.edu
looks up MX records for acmebw.com on the same name server, and:% dig acmebw.com mx
queries wormhole.movie.edufor the SOA record of movie.edu.% dig @wormhole.movie.edu. movie.edu. soa
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:
looks like this:% dig @a.root-servers.net ns .
Let's examine this output section by section.; <<>> 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
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, "Showing the Query and Response Messages". 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, "Security", 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[99]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).
