[dns-operations] How many kinds of DNS DoS attacks are we trying to stop ?
dnsop+phil at spodhuis.org
Thu Sep 27 17:19:53 UTC 2012
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
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
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
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?
And then one I posted on G+ recently, prompted by the thread on this
list I think:
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
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.
More information about the dns-operations