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). dig is a powerful DNS query tool that comes with BIND. Unfortunately, it isn't shipped with Windows Server 2003, but you can get a version of dig that runs on Windows NT, Windows 2000, and Windows Server 2003 from ftp://ftp.isc.org/isc/bind/contrib/ntbind-8.4.1/BIND8.4.1Tools.zip. You may also need to download the other DLLs available at ftp://ftp.isc.org/isc/bind/contrib/ntbind-8.4.1. Follow the installation instructions in the readme1sttools.txt file and note the Known Problems section of that file. It tells you, for example, that on Windows 2000 and Windows Server 2003, dig can't read the resolver configuration from the Registry, so it has no idea what name servers to query by default. You'll need to create the file %SystemRoot%\system32\drivers\etc\resolv.conf that contains at least one line specifying a name server to query:
nameserver 4.2.2.2
Now, all this might seem like a lot of trouble when nslookup is already installed. But for our DNS troubleshooting purposes, we left nslookup in the dust years ago. We hope you'll come to appreciate dig as much as we do.
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.
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 record, not the domain name, you want to look up.
One major difference between nslookup and dig is that dig doesn't apply the search list so always give dig fully qualified domain names as arguments. So:
C:\> dig plan9.fx.movie.edu
looks up address records for plan9.fx.movie.edu using the first name server in resolv.conf, while:
C:\> dig acmebw.com mx
looks up MX records for acmebw.com on the same name server, and:
C:\> dig @wormhole.movie.edu. movie.edu. soa
queries wormhole.movie.edu for 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 datafile or in your root hints file. For example, the output produced by:
C:\> dig @a.root-servers.net ns .
looks like this:
; <<>> DiG 8.4 <<>> @a.root-servers.net ns . ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13297 ;; 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. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 J.ROOT-SERVERS.NET. 5w6d16h IN A 192.58.128.30 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. 5w6d16h IN A 192.36.148.17 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 ;; Total query time: 0 msec ;; FROM: typhoon to SERVER: 198.41.0.4 ;; WHEN: Tue Aug 12 14:48:50 2003 ;; 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.4 <<>>, 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. 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, 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:
C:\> dig @wormhole.movie.edu movie.edu axfr
; <<>> DiG 8.4 <<>> @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: Tue Aug 12 14:50:03 2003
Note that as with nslookup, the SOA record appears twice, at the beginning and the end of the zone.
12.9.3 dig Options
There are too many dig command-line options 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).
