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

[Paul Vixie]

# Do you think the protocol ought to define a return code that indicates that
# the server has no means to answer the query?

as a maintainance and diagnostic convenience, yes.  but operationally
speaking, REFUSED or "just drop the query" is adequate to keep everything
running.  (it only affects behaviour that's already not going to succeed.)

# >(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.)
# 
# If the bit size of a response is < or = the bit size of the query, is the
# DNS any part of the DDoS food chain?  If the response has RCODE=Lame,
# ANCOUNT=0, NSCOUNT=0, and ADCOUNT=0, is there amplification?

reflection is enough.  doesn't have to be amplified to be painful.  the fact
that it's from udp/53 will mean it gets through some victim rate limiters
where an icmp reply (or other non-amplified reflective attacks) would not.

# I'd really prefer if we could avoid a design in which the is disincentive
# to respond to a query.

me too, which is why i'm also working on various sticks and carrots to cause
BCP38 to be more widely deployed.  meanwhile we have to keep the net running.
(and on the internet, "meanwhile" is an undefined period of time, oft "long".)

# I don't like having protocols in an "uncertain" state.

given the number of servers who "just drop" AAAA queries, thus fouling up any
reasonable method of opportunistically using V6 when available and falling
back to V4, i have to agree-- rate limiting that simulates line loss is not
good for the internet.  the only thing worse, is not having it.