why does dig +trace change outcome?
gencoyilmaz at gmail.com
Sat Jun 21 21:52:39 UTC 2008
On Sat, Jun 21, 2008 at 5:53 PM, Hal Brooks <hal at uga.edu> wrote:
> Some name servers, but not all, are unable to resolve
> But even those which are ordinarily unable to resolve
> krensavage.com seem to be able to get answers with dig if
> the +trace option is used.
> For example, this web site:
> offers a browser interface to dig. If you use their
> localhost as the server and query for an A record, but
> don't specify "trace", then the unhappy result is
> "connection timed out; no servers could be reached", but if
> you do specify "trace" then you get 6 answers.
> Similarly from the command line:
> dig @dns1.uga.edu krensavage.com # times out
> dig @dns1.uga.edu krensavage.com +trace # OK
> But other name servers handle it fine (and dig works
> even without +trace):
> dig @ns1.usg.edu krensavage.com # OK
> dig @ns1.usg.edu krensavage.com # also OK
> The only shortcoming I see with the krensavage.com setup is
> that the whois record only has 1 name server
> (yns1.yahoo.com) listed.
> For comparison, olivebarn.com, has similar characteristics
> (though the whois record lists both yns1.yahoo.com and
> yns2.yahoo.com), but it doesn't result in the same failures
> I'm seeing for krensavage.com.
> Any and all help appreciated.
This domain has been delegated to only 1 NS server at root servers.
#dig +short +norec ns krensavage.com @a.gtld-servers.net
Whereas, authoritative server lists 3 other servers;
#dig +short +norec ns krensavage.com @yns1.yahoo.com
I suppose, it is better to fix this mismatch first. Because trace option
causes dig to make iterative queries,
you don't see the response from the cache.
More information about the bind-users