what does dig +trace do?

[Cathy Almond]

On 31/08/11 16:36, Tom Schmitt wrote:
> 
>>>> What strikes me as odd is that the first query does return 4 (internal)
>>>> root servers, but no glue records ?
>>>
>>> I have no idea why this is this way.
>>
>> Because +trace only displays the answer section of the responses by
>> default.
>> Try "dig +trace +additional".
> 
> Hi Chris,
> 
> you are right, thank you. With this I see the glue records:
> 
> ; <<>> DiG 9.8.0-P4 <<>> +trace example.com
> ;; global options: +cmd
> .                       10800   IN      NS      root1.
> .                       10800   IN      NS      root2.
> .                       10800   IN      NS      root3.
> .                       10800   IN      NS      root4.
> root1.     10800 IN A  10.111.111.111
> root2.     10800 IN A  10.111.112.112  
> root3.     10800 IN A  10.111.113.113
> root4.     10800 IN A  10.111.114.114
> ;; Received 159 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
> 
> ;; connection timed out; no servers could be reached
> 
> 
> The main problem is still the same though. The trace option fails with a timeout. Even thought I'm operating on the shell of one of the root-servers itself (so there is not much network in between to cause trouble).

What you will see when you trace this with wireshark is not quite what
you'd expect.

dig is following the referral at each step, but it's not using the glue
provided.  For each referral, it issues a query (following resolv.conf's
configuration to chose the server to ask) for the address of one of the
servers returned before then directly querying it for the name that's
being looked up.

This intermediate lookup doesn't appear in the dig +trace output.

Does that shed any more light on what might be happening in your case?