[dns-operations] does anybody know why yahoo+akamai are doing this?
davidb at verisignlabs.com
Mon Mar 20 17:04:22 UTC 2006
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
>> 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, 22.214.171.124): 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.
David Blacka <davidb at verisignlabs.com>
Sr. Engineer VeriSign Applied Research
More information about the dns-operations