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

[Paul Vixie]

# 	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.
# 
# 	To avoid this you would have to special case returning
# 	referrals to the root.  Special cases are bad.

i guess i'm not looking for a special case.  i'm looking for reasons
why an authority server (which this is) would include an NS RRset for
either its cname owner or cname target, unless either one is below the
zonecut.  no modern client should cache or follow an upward referral,
so why include an authority section that isn't in-balliwick for the
zone of the qname?  with or without an answer section, it's nonsequitur.

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

while i also doubt this-- all i said was it looks suspicious to me--
i can imagine embedded non-caching iterative dns clients who blindly
follow this referral in pursuit of the target of that cname.  perhaps
this has morphed into a namedroppers@ or bind-workers@ topic, though.