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

[David Blacka]

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

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