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? _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
