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

[Paul Vixie]

# > 	AA says that the *first* answer (CNAME) is authoritative.  Any
# > 	other records in the answer section may not be authoritative.
# 
# Yes, I know that.  What puzzled me was that it had www.yahoo.com  
# CNAME as authoritative data, yet not yahoo.com NS.
# 
# I'm guessing that there is some sort of semi-obvious scenario here,  
# but I haven't been able to think of it, so I'm asking.

the yahoo.com nameservers do not (thank the gods!) have fetch-glue enabled,
and so they don't have any NS information for the target of the nonterminal
CNAME chain they're returning.  RFC1034 implies that whatever is the closest
zone cut to this nonterminal CNAME target, should go into the authority
section.  however, RFC1034 also implies that CNAMEs will be in-zone, and has
no direct provision for out-of-zone or otherwise nonterminal CNAME chains.
therefore we end up with rules like "if someone sends you out-of-ballywick
NS RRsets, you should ignore them" where what we really need is a rule like
"if you're sending an out-of-zone nonterminal CNAME chain, the NS RRset you
include with it should be that of your zone, not the target zone, since you
probably won't want to recurse to get the right information, and you might
not even have root hints if you're running authoritative-only."  in other
words, RFC1034 is just wrong in this case.  which is why i wondered whether
this thread should move to namedroppers at .  operationally speaking, the right
thing for yahoo to do is remove its root-hints so it'll have NO matching NS
RRs.  code-wise, BIND should avoid sending them, since it already ignores
them when received.  spec-wise, another DNS Clarifications RFC is necessary.