[ratelimits] adding "all-responses-per-second X"
Vernon Schryver
vjs at rhyolite.com
Fri Sep 14 19:28:59 UTC 2012
Tony Finch recently mentioned DNS reflection amplification attacks
spread among many valid domains at an authority server to evade rate
limits on individual domains.
So what do you think about adding a new limit
all-per-second <number>;
to supplement the current responses-per-second, errors-per-second,
and nxdomains-per-second limits?
- It would limit responses to any single IP address block much
like the current limits, but without regard to qname, qtype,
class, or error type.
- Only responses not dropped by the other limits would be counted
in order to give precedence to the other limits.
- It would be constrained to at least twice the other limits.
- The 'slip' parameter would not apply to responses dropped by
this new limit.
- The limit would be disabled by default.
My questions are:
- Is this a bad idea? Should such simple rate-limiting be left to
to firewalls? I've been told that the demand for support in
the DNS server cannot be ignored.
- Are those characteristics wrong? For example, should it have
a default, enabling value when rate-limiting is enabled?
Unlike the defaults for the other limits, I can't think of a
rate that ould make sense in most installations.
- Is there a lower bound on the number of bogus DNS responses that
any target of a reflection attack today can be expected to
tolerate? Perhaps 100 or 1000 responses/second?
If so, should that be a lower limit on the new parameter?
- Is not honoring "slip" right? I figure that while it is
operating, things are in such a bad state between the server
and apparent client that a flood of TC=1 responses would do
more harm than good.
- Is there a better name than "all-per-second"?
Vernon Schryver vjs at rhyolite.com
More information about the ratelimits
mailing list