[dns-operations] DNS deluge for x.p.ctrc.cc

[Paul Vixie]

# I guess there are two kinds of amplification - recursive and non-recursive.
# But they both depend on the victim (supposedly) asking a question a lot of
# times.
# 
# Does it make sense that the victim would ask the same question over and
# over?  I.e. would it be practical for a dns server (whether authoritative or
# resolving) to rate-limit its response based on sourcip+query ?

yes and no.  the fact that a requestor isn't caching your responses doesn't,
by itself, justify withholding those responses.  especially negative responses,
since negative caching is optional.  but even positive caching is sometimes
impractical, like in embedded device controllers.  or someone could be doing
a lot of caching that you're not seeing, and you could see repeat queries due
to normal LRU expiry of a very hot very busy caching forwarder.  in short, we
can't just not answer because we think someone should've paid more attention
to what we said last time they asked the identical question.

but wait, it gets better.  if you want to rate-limit, like for example you'd
like to limit each source-ip to a DSL's worth of query traffic just on the
principle that "you've gotta draw the line SOMEWHERE", then you've got to hold
some flow state.  that will have to be in non-moving-part storage, which will
likely have some kind of cache in front of it.  the number of buckets you're
willing to keep (containing state information) and the size of the cache you
can put in front of those buckets (letting your CPU run at full speed) are
"discoverable parameters" that an attacker can measure or at least estimate,
and then attack by sending enough flows (not all of them toward a victim, some
are just noise to mix up the signal) to keep you from being able to remember
enough "flow state" information, or access it fast enough through your cache,
to be able to keep from doing the harmful thing they want you to do, or to keep
doing the beneficial thing they don't want you to do, or whatever.

if you get past all those hurdles, either with massive overprovisioning, good
random number based behaviour that makes your parameters hard to guess, or
faster-than-light technology that blows away all known obstacles, then you'll
still have a rate at which you're willing to answer.  that rate is enough, if
you're one of 122K (or 580K or 1M or whatever) recursive name servers with
similar rate limits, each able to send a trickle of larger-than-the-query
responses (whether 512B or 1500B or 4KB in size) toward the victim.

so even if you could get the set of people running open recursive AND authority
servers to all deploy perfect unassailable rate limiting (which to me sounds
as hard or harder than getting the whole internet to deploy BCP38), any single
name server will still be smashable by any russian mobster or angry teenager
using trivial and undetectable methods.

the only hint of a solution i've seen in all this so far is automated shunning
of known-open-recursive + known-recent-abused name servers, in order to push
these attacks toward other UDP-based services like (authority name servers)
which are more limited in number and thus may be a more tractible battlefield.