4 ms·
This is great, already installed via Homebrew. Something that puzzles me while using dig(1) is that I don't really understand the +trace output. In my mind it
by alpb 6y ago
This is great, already installed via Homebrew.
Something that puzzles me while using dig(1) is that I don't really understand the +trace output. In my mind it should be rather easy to trace a DNS request, something like: dig A google.com → etc/resolv.conf says your nameserver is X.Y.Z.T → made a query to X.Y.Z.T, it recursed → domain google.com has nameserver ns.a.b. → ADDITIONAL section told us ns.a.b is at X.C.F.G IP → made dns query to X.C.F.G, it told us it was Authoritative and gave RRs [IP1, IP2].
I never quite can get this level of clarity from dig(1), instead, "dig A google.com +trace" gives an output like this: https://gist.github.com/ahmetb/28a3853bef72fbabf4f0d8ac0712a38d https://gist.github.com/ahmetb/28a3853bef72fbabf4f0d8ac0712a... which makes me think like: what the hell, am I actually hitting root nameservers every time?
If your tool can help developers here, I think it's a major value add.
- kbenson 6y ago> what the hell, am I actually hitting root nameservers every time? Trace hits the roots because trace is for tracing the lookups from the root nameservers through the rest of the path. It's in the man page: +[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. ...
- cesarb 6y ago> made a query to X.Y.Z.T, it recursed If it recursed, then X.Y.Z.T gave you the final response. It doesn't tell you how it arrived at that final response, and it might not even know (it only saves the final response in the cache). The output of dig +trace is the steps a recursive resolver would have to follow if it started from scratch (with a cold cache).
- alpb 6y agoOh yeah my bad, in that case, let's say "X.Y.Z.T said it doesn't support recursion".