[dns-operations] does anybody know why yahoo+akamai are doing this?
davidb at verisignlabs.com
Mon Mar 20 19:37:45 UTC 2006
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,
>>>>> I will pro-offer the following, mostly clueless, attempt at an
>>>> 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.
>>> 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, 184.108.40.206): BIND 8.3.0-RC1 --
> 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
More information about the dns-operations