[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