why does dig +trace change outcome?

[Mark Andrews]

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

	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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org