On 01/08/12 11:49, Mark Goldfinch wrote:
How would we protect ourselves as DNS operators from
traffic originators in this scenario?
As Jay points out, this isn't a DNSSEC-specific problem. It exacerbates
it, sure, but any big response will do for DNS amplification; you don't
need DNSSEC. An "ANY" query for the apex of a domain with SPF records,
other TXT records, a long NS list, a good-sized MX cloud and a both A &
AAAA records for all the listed services will produce a pretty decent
sized response without needing to throw DNSSEC at it.
So yeah, you can keep your responses down to minimal answers, no SPF or
TXT, one or two MX records, two NS records, an A and no DNSSEC, and you
won't be such an attractive target, but you're still putting out bigger
responses than the queries.
The longer answer is to look at rate limiting queries. If you're getting
a high rate of repeated queries or even particularly high rates of any
type of query from a particular source, throttle the source. Yes, you
need to keep state. DNS has a TTL field for a reason; if you're getting
queries from a "source" (e.g. the target of DNS amplification attack) at
a significant multiple of the rate specified by the TTL of the query
responses, someone is Doing It Wrong and it's OK to stop listening to them.
The real solution is for providers to filter source addresses at the
edge so that this kind of spoofing can't happen.