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

[Paul Vixie]

# 2) Running a stub zone seems to be a violation of the spec - coherency
# (sameness of the answers) is important to DNS.  Ergo, running an stub, or as
# I read it, an alternate, version of someone else's zone is a step in the
# wrong direction.

no.  stub servers are not described explicitly by the spec, but they are
merely a case of mixed-mode (authority and recursive in the same server image)
that mark andrews invented about ten years back.  they cause a server to
fetch and hold and use the apex NS RRset for some zone, even if that server
is not authoritative for that zone, and is not normally recursive.  the
NS RRset thus fetched will only be used nonauthoritatively.  there is no
violation of the spec.  the only danger is that the list of master servers
from which to fetch the NS RRset is the usual set of hardcoded IP addresses,
and BIND has no facility for tracking such a "stub zone" as it moves around.
but that's a weakness in the implementation, unrelated to "the spec" at all.

# 3) If the Yahoo servers do remove their hint files, will queriers be able
# to understand an "I'm a lame server" for out-of-baliwick queries?  As far
# as I can recall, there is no message return code that a server can use in a
# response to say "I don't know and don't ask me again."  Over time, the
# convention of sending an upwards referral has been adopted as that message.

most servers who issue glueless referrals lack root hints, and many servers
who issue nonterminal out-of-zone CNAME chains lack root hints, and so we
know that the average dns client is apparently coping with the configuration
i advise for yahoo.com's servers.

# For clarification, Paul, what should the Yahoo servers return for a query
# for (www.isc.org, IN, A) or (www.yahoo.akadns.net., IN, A)? The first being
# a genuinely lame response, the other one that might be handled by the stub
# zone you recommend.

i was once a fan of upward referrals, but i learned better.  in the first
case, the answer should be a rate-limited REFUSED message.  in the second
case, it should be an empty answer section, a copy of the apex NS RRset in
the the authority section, and whatever glue records are available in the
additional-data section.

but note, since yahoo.com's nameservers are not listed in anybody's
resolv.conf files and are not in any NS RRset for either of the zones
you asked about, that it should never hear the queries you describe, and
would be within its rights to just drop them on the floor, or answer with
REFUSED in both cases.

(note that to keep DNS out of the DDoS food chain, REFUSED really has to
become rate-limited, even if that simulates "selective line loss".  sorry.)