dig +trace to find all the forwarders?

Josh Kuo josh.kuo at gmail.com
Mon Apr 26 07:10:51 UTC 2010


What is happening is I suspect the DNS resolved IP given by my ISP is
actually forwarding recursive queries to yet-another-server(s), and is
introducing slow name resolution and timeouts. In any case, I will
have to involve the ISP in troubleshooting and (hopefully) fixing the
problem. I was hoping there is some way to mimic "traceroute" with
"dig +trace", I didn't think so, and Mark confirmed it.

On Sunday, April 25, 2010, Warren Kumari <warren at kumari.net> wrote:
>
> On Apr 25, 2010, at 12:01 AM, Josh Kuo wrote:
>
>
> You need administrative access to see the overides to the normal resolution
> process.
>
>
> Just so I understand this completely, by administrative access you mean I need to be able to log in to each of the resolvers (not administrative access on my local workstation to do a 'sudo dig example.net a +trace'), correct?
>
> A follow up question to that... is it even possible to perform such a trace (revealing all resolvers) with the DNS protocol?
>
>
> 'tis not doable[0].
>
> What is the root problem that you are trying to solve here? Is this just to know because you want to, or are you trying to solve a specific issue? In the very large majority of cases[1] your machine is going to be querying whatever is configured in your resolv.conf (or equivalent) and those nameservers will go do the resolution for you (as opposed to multiple levels of forwarders).
>
>
> [0]: I have horrid visions of someone responding back with some truly horrendous kludge that involves looking up random strings and querying heaps-o-servers to see if any of them had cached the answer or something equally icky. Actually, you cloud see if the server that you query is the one that actually touches the auth server, but this is all ugly.
>
> [1]: No hard data here -- does anyone have any sort of guestimate on fraction of forwarded queries?
>
> W
>
>
> Or is this purely a designed limitation of dig?
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>



More information about the bind-users mailing list