Looking Up Records with dig

.10.1 Problem

You want to look up records using dig.

.10.2 Solution

Specify the domain name you want to look up, the record type you e interested in (unless its A, the default), and the domain name or IP address of the name server you want to query (unless its the first one in your resolvers configuration, which is the default) as arguments to dig:

$ dig @a.gtld-servers.net a www.oreilly.com

The arguments may appear in any order: dig is smart enough to determine which is which (fairly easy, since the name servers domain name or address has an "@" in front of it, domain names usually have dots in them, and there are only so many record types).

Unlike nslookup, dig doesn apply the search list by default, so use fully qualified domain names, both to specify the domain name you want to look up and any remote name server you want to query.

.10.3 Discussion

dig prints the DNS response message it gets back in a very detailed format. For example, heres the output produced by the dig command above:

; <<>> DiG 9.2.1 <<>> @a.gtld-servers.net www.oreilly.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17064
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
 
;; QUESTION SECTION:
;www.oreilly.com. IN A
 
;; AUTHORITY SECTION:
oreilly.com. 172800 IN NS NS.oreilly.com.
oreilly.com. 172800 IN NS NS1.SONIC.NET.
 
;; ADDITIONAL SECTION:
NS.oreilly.com. 172800 IN A 209.204.146.21
NS1.SONIC.NET. 172800 IN A 208.201.224.11
 
;; Query time: 80 msec
;; SERVER: 192.5.6.30#53(a.gtld-servers.net)
;; WHEN: Thu Jun 27 16:49:31 2002
;; MSG SIZE rcvd: 109

In this case, the answer is a little hard to find. The banner, on the first line, echoes the query sent (for A records for www.oreilly.com on a.gtld-servers.net). dig also prints the header (after ->>HEADER<<-), which tells us that this was a standard QUERY response (not a NOTIFY message or dynamic update), and that the return code was NOERROR, indicating that the query was processed successfully.

The rest of the header shows us that this was a nonauthoritative (aa didn appear as a flag) response (qr was set). The query was recursive (rd means "recursion desired") but recursion wasn available (ra didn appear as a flag). Thats not surprising, since we sent the query to a gTLD name server.

The QUESTION SECTION parrots the question we asked (again), and the AUTHORITY SECTION shows the two NS records returned by the name server we queried, referring us to name servers closer to the answer. The ADDITIONAL SECTION gives us the addresses of those name servers.

At the end, we see that the response took 80 milliseconds, that the name server we queried was a.gtld-servers.net at 192.5.6.30, plus a date- and timestamp and the fact that the reply was 109 bytes long.

If the name server we queried had actually returned the records we asked for, those records would appear in the answer section, as shown here:

$ dig @ns.oreilly.com www.oreilly.com a 
 
; <<>> DiG 9.2.1 <<>> @ns.oreilly.com www.oreilly.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40642
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
 
;; QUESTION SECTION:
;www.oreilly.com. IN A
 
;; ANSWER SECTION:
www.oreilly.com. 7200 IN A 209.204.146.22
 
;; AUTHORITY SECTION:
oreilly.com. 7200 IN NS ns.oreilly.com.
oreilly.com. 7200 IN NS ns1.sonic.net.
oreilly.com. 7200 IN NS ns2.sonic.net.
 
;; ADDITIONAL SECTION:
ns.oreilly.com. 7200 IN A 209.204.146.21
ns1.sonic.net. 6237 IN A 208.201.224.11
ns2.sonic.net. 62511 IN A 208.201.224.33
 
;; Query time: 100 msec
;; SERVER: 209.204.146.21#53(ns.oreilly.com)
;; WHEN: Thu Jun 27 16:55:01 2002
;; MSG SIZE rcvd: 159

This time, its an authoritative answer (aa is in the flags field) and recursion was available (the ra flag -- whoops) and the A record we asked for is in the ANSWER SECTION.

.10.4 See Also

dig(1) and "Using dig" in Chapter 12 of DNS and BIND.