[dns-operations] does anybody know why yahoo+akamai are doing this?

[Mark Andrews]

> 
> On Mar 20, 2006, at 9:23 AM, Mark Andrews wrote:
> 
> >
> >>> Ah Akamai!  I am much behind Paul on depth of understanding, albeit,
> >>> I will pro-offer the following, mostly clueless, attempt at an
> >>> explanation.
> >>
> >> I'm in the same boat r.e. depth of understanding, but doesn't that
> >> seem awfully redundant?  The nameserver doing the lookup should go to
> >> the roots anyway, assuming it hasn't already cached referrals
> >> for .net or akamai.net.
> >>
> >> Matt
> >
> > 	This all falls out of RFC 1034.  They are returning the
> > 	*best* referral they can on the second (or later) pass
> > 	through RFC1034 Section 4.3.2.
> 
> Er, what?  If this was a non-authoritative response, it would not be  
> terribly unusual -- the resolver would just be returning the closest  
> NS RRset that it had.  However, the aa bit is set, so I am puzzled as  
> to how it could not have a better NS set.  Namely, the one for  
> yahoo.com.  Fingerprinting ns5.yahoo.com returns:
>    fingerprint (ns5.yahoo.com, 216.109.116.17): BIND 8.3.0-RC1 -- 8.4.4

	AA says that the *first* answer (CNAME) is authoritative.  Any
	other records in the answer section may not be authoritative.
 
> Also, the response isn't a referral.  Was there ever any DNS software  
> that would interpret it is as such?
> 
> > 	To avoid this you would have to special case returning
> > 	referrals to the root.  Special cases are bad.
> >
> > 	I also doubt that this is causing the spikes that Paul
> > 	mentioned originally unless the auth servers are BIND 8
> > 	behind a one way firewall which allows the queries to the
> > 	root out by not the replies in.
> >
> > 	Mark
> 
> --
> David Blacka    <davidb at verisignlabs.com>
> Sr. Engineer    VeriSign Applied Research
> 
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org