Tracing Name Resolution Using dig
.13.1 Problem
You want to trace the process of name resolution using dig.
.13.2 Solution
Starting with a root name server, send nonrecursive queries (with the +norec command-line option) for the records you e 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. Well 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 well 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 e done.
.13.3 Discussion
Notice that the query doesn 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 9s 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 e trying to track down a problem, not just reenacting name resolution for personal or pedagogical reasons, pay careful attention to digs output. Look for responses that indicate that the domain name doesn 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.
.13.4 See Also
dig(1); and Section 6.6, for using digs +trace option to check delegation.
Категории