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

[David Blacka]

On Mar 20, 2006, at 12:11 PM, Mark Andrews wrote:

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

Yes, I know that.  What puzzled me was that it had www.yahoo.com  
CNAME as authoritative data, yet not yahoo.com NS.

I'm guessing that there is some sort of semi-obvious scenario here,  
but I haven't been able to think of it, so I'm asking.

--
David Blacka    <davidb at verisignlabs.com>
Sr. Engineer    VeriSign Applied Research