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

Peter Dambier peter at peter-dambier.de
Mon Mar 20 20:36:20 UTC 2006

David Blacka 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
>>>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, 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?

I have seen both Bind 9 and Bind 8 "kashpureffed". I am not shure this
is the way it was done. All I know is, since I slaved the root it no
more happened.

It is root-servers.net they return. So normally you wont notice.
But suppose the returned public-root.net ???

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

I have compared the timing of Bind 9 and dnscache (djbdns). djbdns
takes longer to return an answer. It obviously does not believe in
the glue records returned. At least not if they obviously are outside

Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
mail: peter at echnaton.serveftp.com

More information about the dns-operations mailing list