[dns-operations] does anybody know why yahoo+akamai are doing this?
Mark_Andrews at isc.org
Mon Mar 20 18:11:04 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
> >>> 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, 18.104.22.168): 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
More information about the dns-operations