10.13 Tracing Name Resolution Using dig

10.13.1 Problem

You want to trace the process of name resolution using dig.

10.13.2 Solution

Starting with a root name server, send nonrecursive queries (with the +norec command-line option) for the records you're looking for. (The root name servers are named [a-m].root-servers.net.) For example:

$ dig @a.root-servers.net www.oreilly.com +norec
 
; <<>> DiG 9.2.1 <<>> @a.root-servers.net www.oreilly.com +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44699
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
 
;; QUESTION SECTION:
;www.oreilly.com.               IN      A
 
;; AUTHORITY SECTION:
com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
 
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET.     172800  IN      A       192.5.6.30
G.GTLD-SERVERS.NET.     172800  IN      A       192.42.93.30
H.GTLD-SERVERS.NET.     172800  IN      A       192.54.112.30
C.GTLD-SERVERS.NET.     172800  IN      A       192.26.92.30
I.GTLD-SERVERS.NET.     172800  IN      A       192.43.172.30
B.GTLD-SERVERS.NET.     172800  IN      A       192.33.14.30
D.GTLD-SERVERS.NET.     172800  IN      A       192.31.80.30
L.GTLD-SERVERS.NET.     172800  IN      A       192.41.162.30
F.GTLD-SERVERS.NET.     172800  IN      A       192.35.51.30
J.GTLD-SERVERS.NET.     172800  IN      A       210.132.100.101
K.GTLD-SERVERS.NET.     172800  IN      A       192.52.178.30
E.GTLD-SERVERS.NET.     172800  IN      A       192.12.94.30
M.GTLD-SERVERS.NET.     172800  IN      A       192.55.83.30
 
;; Query time: 84 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Fri Jun 28 11:53:41 2002
;; MSG SIZE  rcvd: 465

When you receive a referral (a response with a NOERROR status, no answer section, and NS records in the authority section), send your next query to one of the name servers in the authority section. We'll query m.gtld-servers.net next:

$ dig @m.gtld-servers.net www.oreilly.com +norec
 
; <<>> DiG 9.2.1 <<>> @m.gtld-servers.net www.oreilly.com +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53652
;; flags: qr; 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: 251 msec
;; SERVER: 192.55.83.30#53(m.gtld-servers.net)
;; WHEN: Fri Jun 28 12:06:26 2002
;; MSG SIZE  rcvd: 109

Now we'll query ns.oreilly.com:

$ dig @ns.oreilly.com www.oreilly.com +norec    
 
; <<>> DiG 9.2.1 <<>> @ns.oreilly.com www.oreilly.com +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36079
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
 
;; 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      ns2.sonic.net.
oreilly.com.            7200    IN      NS      ns.oreilly.com.
oreilly.com.            7200    IN      NS      ns1.sonic.net.
 
;; ADDITIONAL SECTION:
ns.oreilly.com.         7200    IN      A       209.204.146.21
ns2.sonic.net.          80335   IN      A       208.201.224.33
 
;; Query time: 254 msec
;; SERVER: 209.204.146.21#53(ns.oreilly.com)
;; WHEN: Fri Jun 28 12:07:01 2002
;; MSG SIZE  rcvd: 143

This response has the record we were after in the answer section, so we're done.

10.13.3 Discussion

Notice that the query doesn't change: in this example, we look up A records for www.oreilly.com each time. By following the referrals, we get closer and closer to the name servers authoritative for the zone that contains the answer.

BIND 9's version of dig has a command-line option to trace name resolution automatically -- very slick! To reproduce the output above, you only need to run:

$ dig +trace www.oreilly.com

dig starts by looking up the list of root name servers on your default name server, then sends a nonrecursive query to one of them for the records you specified on the command line. Then it follows referrals, as we did, until it finds an answer.

If you're trying to track down a problem, not just reenacting name resolution for personal or pedagogical reasons, pay careful attention to dig's output. Look for responses that indicate that the domain name doesn't exist (NXDOMAIN in the status field of the header) or that refer you to name servers authoritative for a zone higher up in the namespace (for example, an oreilly.com name server referring you to a com name server), which is a symptom of a lame delegation.

10.13.4 See Also

dig(1); and Section 6.6, for using dig's +trace option to check delegation.