[dns-operations] How many kinds of DNS DoS attacks are we trying to stop ?

[Phil Pennock]

On 2012-09-27 at 12:23 -0400, Olafur Gudmundsson wrote:
> Similarly we should think about approaches that operators/implementors 
> can take to limit their vulnerability

Three crazy ideas, not tried because so far I've been lucky enough to
not get a serious DoS; throwing them out to see what sticks, past the
mockery.

(1)
Log queries in-memory only, with a ring buffer, so that if a reader
doesn't keep up, it loses those queries; in high enough volume, log
statistical samples.

Experiment to see if OS fingerprinting yields useful signal on DNS UDP
queries (I suspect not?).

Build a reputation DB of known-good querants who can be put into a
default QoS queue which separates from normal traffic; let the
characterisation include the OS fingerprint, so that spoofed traffic
from a bot-net of consumer OS machines is less likely to impact those
legitimate resolver running on a production systems which can be told
apart.  (If Windows Server can't be told from Windows Desktop anymore,
that's an issue, but still provides some protection for folks running
non-Windows for production, so benefits a significant fraction of the
deployed userbase).

(2)
Does anyone know what percentage of legitimate resolvers are
sufficiently non-buggy that an empty response with TC set will cause TCP
retry immediately, so that a server can enter a TCP-only mode with a
minimal response for those cases?

(3)
And then one I posted on G+ recently, prompted by the thread on this
list I think:

  https://plus.google.com/101939425596655172174/posts/3zrD8WC4GhD

  DNS DDoS amplifier resistance: as a thought, would it be a reasonable
  step, not hurting interop, to have an authoritative DNS server process
  a UDP-based ANY query by including, at most, an MX and any A responses
  in the ANSWER section and setting the TrunCated bit of the response if
  there were any other records skipped?

  So someone debugging will likely see the full response as their client
  switches to TCP; someone using broken old mail-servers (that don't
  understand recursive cache behaviour as different QTYPE cached entries
  expire at different times) still gets an MX response, and things
  generally work, but the opportunities for amplification over UDP are
  reduced.

  The most notable change would be that the ANY response with the MX
  would not include in-bailiwick A records for the hosts pointed to by
  the MX records in the ADDITIONAL section, because some clients assume
  that only the last section received could have been truncated, so an
  ADDITIONAL section can't be included.

  If the response is in a child zone for which the server is not
  authoritative, then NS and glue records would be returned as normal.

  Thoughts? 

-Phil