25

When I look at the man page for dig, I get the following:

+[no]trace
  Toggle tracing of the delegation path from the root name servers for the name
  being looked up. Tracing is disabled by default. When tracing is enabled, dig
  makes iterative queries to resolve the name being looked up. It will follow
  referrals from the root servers, showing the answer from each server that was
  used to resolve the lookup.

So how does this work, in practice? What would be the equivalent series of dig commands (without +trace) that would be functionally equivalent?

2 Answers 2

44

dig +trace works by pretending it's a name server and works down the namespace tree using iterative queries starting at the root of the tree, following referrals along the way.

The first thing it does is ask the normal system DNS server for NS records for "."

After it gets a response, which will be the current list of root name servers, it'll pick one and then ask for the A record for that name if it didn't get it in the additional records section the first time so it's got an IP address to send the next query to. Let's say it picks f.root-servers.net whose IP address is 192.5.5.241.

At this point, let's use dig +trace www.google.co.uk. as our command with a domain name we want to trace the resolution path for.

The next behind-the-scenes query will be this:

$ dig +norecurse @192.5.5.241 www.google.co.uk

   ; <<>> DiG 9.9.4 <<>> +norecurse @192.5.5.241 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8962
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 15

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk.              IN      A

;; AUTHORITY SECTION:
uk.                     172800  IN      NS      ns5.nic.uk.
uk.                     172800  IN      NS      ns6.nic.uk.
uk.                     172800  IN      NS      ns4.nic.uk.
uk.                     172800  IN      NS      nsc.nic.uk.
uk.                     172800  IN      NS      ns2.nic.uk.
uk.                     172800  IN      NS      ns3.nic.uk.
uk.                     172800  IN      NS      nsd.nic.uk.
uk.                     172800  IN      NS      nsa.nic.uk.
uk.                     172800  IN      NS      ns7.nic.uk.
uk.                     172800  IN      NS      nsb.nic.uk.
uk.                     172800  IN      NS      ns1.nic.uk.

;; ADDITIONAL SECTION:
ns1.nic.uk.             172800  IN      A       195.66.240.130
ns2.nic.uk.             172800  IN      A       217.79.164.131
ns3.nic.uk.             172800  IN      A       213.219.13.131
ns4.nic.uk.             172800  IN      A       194.83.244.131
ns5.nic.uk.             172800  IN      A       213.246.167.131
ns6.nic.uk.             172800  IN      A       213.248.254.130
ns7.nic.uk.             172800  IN      A       212.121.40.130
nsa.nic.uk.             172800  IN      A       156.154.100.3
nsb.nic.uk.             172800  IN      A       156.154.101.3
nsc.nic.uk.             172800  IN      A       156.154.102.3
nsd.nic.uk.             172800  IN      A       156.154.103.3
ns1.nic.uk.             172800  IN      AAAA    2a01:40:1001:35::2
ns4.nic.uk.             172800  IN      AAAA    2001:630:181:35::83
nsa.nic.uk.             172800  IN      AAAA    2001:502:ad09::3

;; Query time: 45 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Tue Feb 11 19:19:14 MST 2014
;; MSG SIZE  rcvd: 507

Wow, so now we know that there are nameservers for uk and that's the only thing the root server knows about. This is a referral, because we did not ask for recursion (+norecurse turns it off).

Great, we rinse and repeat. This time we pick one of the uk nameservers and ask it the same question.

$ dig +norecurse @195.66.240.130 www.google.co.uk

; <<>> DiG 9.9.4 <<>> +norecurse @195.66.240.130 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk.              IN      A

;; AUTHORITY SECTION:
google.co.uk.           172800  IN      NS      ns1.google.com.
google.co.uk.           172800  IN      NS      ns3.google.com.
google.co.uk.           172800  IN      NS      ns2.google.com.
google.co.uk.           172800  IN      NS      ns4.google.com.

;; Query time: 354 msec
;; SERVER: 195.66.240.130#53(195.66.240.130)
;; WHEN: Tue Feb 11 19:22:47 MST 2014
;; MSG SIZE  rcvd: 127

Awesome, now we have found out that the uk top-level nameserver knows there's a zone called google.co.uk and tells us to go ask those nameservers our question. This is another referral.

Rinse, repeat.

This time, however, we didn't get A records in the additional records section of the response, so we pick one, say ns2.google.com, and we have to go find it's address. We restart a query (at the root again) and chase down the tree to find the IP address for ns2.google.com. I'll skip that part for brevity, but we learn that the IP for it is 216.239.34.10.

So our next query is:

$ dig +norecurse @216.239.34.10 www.google.co.uk

; <<>> DiG 9.9.4 <<>> +norecurse @216.239.34.10 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33404
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.co.uk.              IN      A

;; ANSWER SECTION:
www.google.co.uk.       300     IN      A       74.125.225.216
www.google.co.uk.       300     IN      A       74.125.225.223
www.google.co.uk.       300     IN      A       74.125.225.215

;; Query time: 207 msec
;; SERVER: 216.239.34.10#53(216.239.34.10)
;; WHEN: Tue Feb 11 19:26:43 MST 2014
;; MSG SIZE  rcvd: 82

And we're done! (finally) How do we know we're done? We got an answer to our query, which was the A records for www.google.co.uk. You can also tell because it's not a referral anymore, the aa bit is set in the last response meaning this is the authoritative answer for your query.

So that's what's happening each step along the way when you use dig +trace.

Note that if you have a DNSSEC-aware version of dig and you add +dnssec to the command, you may see a bunch more records. What those extra records are is left as an exercise for the reader... but gets into how dig +sigchase works.

2
  • One doubt: in the request to @192.5.5.241, the answers in the ADDITIONAL SECTION, are they the so called glue records? Nov 9, 2017 at 8:21
  • Yes, because the name of the A records exist within or below the zone the NS records in the Authority section refer, so they are necessary to continue the resolution process.
    – milli
    Nov 27, 2017 at 23:29
2

Lets say you were looking up

www.domain.co.uk

DNS is a heirarchy, starting with root servers that know which servers are authoritative for the TLDs (the last part of the domain name). So the equivilent to

dig subdomain.domain.co.uk

Step by step would be:

dig SOA @g.root-servers.net uk

(ie, query one of the root servers to find who is authoritative for .uk)

This responds with a series of authoritative uk servers, so we ask them who has co.uk

dig SOA @ns6.nic.uk co.uk

And we are told the SOA (authority) is at the same servers

So lets query ns1.nic.uk to see who has domain.co.uk

dig SOA @ns1.nic.uk domain.co.uk

This comes back and says authority for domain is at dns.dns1.de (plus backups);

So now we can ask for the A record:

dig  A @dns.dns2.de www.domain.co.uk

;; QUESTION SECTION:
;www.domain.co.uk.              IN      A

;; ANSWER SECTION:
www.domain.co.uk.       86400   IN      CNAME   domain.co.uk.
domain.co.uk.           86400   IN      A       95.130.17.36
5
  • How do I address the topic of delegation? Let's say the authority for domain.co.uk is dns.dns1.de, but members.domain.co.uk has been delegated to dns.dns2.com and I'm looking up joe.members.domain.co.uk. How do I know when it's "safe" to step off the SOA merry-go-round and query the other records?
    – Doktor J
    Feb 12, 2014 at 3:02
  • The actual process asks for the A record all along. There's no magic switching to SOA queries. (There couldn't be, since a resolving proxy wouldn't know when to switch back.) There's no magic modification of the domain name in the question, either. It's www.domain.co.uk. all of the way through. This is important to remember, because that means that any of the content servers queried can provide the complete answer.
    – JdeBP
    Feb 12, 2014 at 12:03
  • 1
    @DoktorJ Yep, this is my mistake JdeBP is right. I was trying to amek a point with the SOA, but it got tangled up into the reply. The other answer is more accurate.
    – Paul
    Feb 12, 2014 at 12:09
  • @Paul thanks for the followup; I've flagged the other answer as the correct answer to help out anyone else who may end up here (no offense to you!) :)
    – Doktor J
    Feb 12, 2014 at 20:05
  • @doktorj Not at all, that is exactly as it should be :)
    – Paul
    Feb 12, 2014 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.