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?
Best Answer
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:
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.Awesome, now we have found out that the
uk
top-level nameserver knows there's a zone calledgoogle.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:
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 howdig +sigchase
works.