dig +trace to find all the forwarders?

[Warren Kumari]

On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:

> 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.

Well, if you are just trying to figure out if the nameserver you are  
asking is the one doing the resolution, this *might* help you out:

http://www.damia.com/whatismydns/

W


> 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
>>
>>
>>

-- 
Militant Agnostic--I don't know and you don't either...