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

[Peter Dambier]

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

-- 
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
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/