why does dig +trace change outcome?
Mark_Andrews at isc.org
Mon Jun 23 02:20:27 UTC 2008
> On Sat, 21 Jun 2008, Genco Yilmaz wrote:
> > 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
> >> krensavage.com
> >> 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:
> >> http://www.kloth.net/services/dig.php
> >> 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.
> >> -hal
> > Hello Hal,
> > This domain has been delegated to only 1 NS server at root servers.
> > #dig +short +norec ns krensavage.com @a.gtld-servers.net
> > yns1.yahoo.com.
> > Whereas, authoritative server lists 3 other servers;
> > #dig +short +norec ns krensavage.com @yns1.yahoo.com
> > ns8.san.yahoo.com.
> > yns2.yahoo.com.
> > yns1.yahoo.com.
> > ns9.san.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.
> Thanks, I'll try to get the RP to do that. But
> krensavage.com isn't my domain. I'm just trying to get the
> uga.edu NS to be able to see it. And since some others can
> get it, it's difficult for me to say that the problem is
> with their config and not mine.
Firstly when you run "dig +trace" it is dig, not the
nameserver making the queries. The nameserver listed in
@nameserver is only used to discover the set of root servers
to query to start the trace. Unless you are running "dig
+trace" on the problem nameserver you are already starting
out with a different source address for the queries in
addition to a different port being used.
Secondly there can be lots of reasons other than a bad
delegation that stop a resolution working. A route not
being propogated, a firewall block packets, a NAT that has
locked up. Some of these are externally visible. Others
will only be visible by looking at packet traces.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users