10.10 Looking Up Records with dig
10.10.1 Problem
You want to look up records using
dig.
10.10.2 Solution
Specify
the domain name you want to look up, the record type
you're interested in (unless it's
A, the default), and the domain name or IP address of the name server
you want to query (unless it's the first one in your
resolver's 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
server's 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't 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.10.3 Discussion
dig
prints the DNS response message it gets
back in a very detailed format. For example, here's
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't appear as a flag) response
(qr was set). The query was recursive
(rd means "recursion
desired") but recursion wasn't
available (ra didn't appear as
a flag). That's 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, it's 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.10.4 See Also
dig(1) and "Using
dig" in Chapter 12 of DNS and
BIND.
|
