[ratelimits] Whitelist ratelimit

[Vernon Schryver]

> From: "Gary E. Miller" <gem at rellim.com>
> To: ratelimits at lists.redbarn.org

> My problem is that a local SpammAssasin instance is also generating
> a lot of DNS qps and sometimes gets limited.  I know that the SLIP
> will kick the valid requests to TCP, but is there a simple way
> to just whitelist some local IPs?


} From: P Vixie <paul at redbarn.org>

} You can put your local clients in a separate view and only rate
} limit the non local clients in the view for the non local clients.

There is an exempt-clients{} clause in the current or perhaps future
version of the rate limit patch, but using it is generally a bad idea.
As Paul Vixie wrote, it is almost always better segregate your DNS
clients into views by trust, and use separate (or no) rate-limit{}
settings in each view.  A local DNS client running SpamAssassin ought
to be trusted to not generate DNS reflection attack traffic or you
probably bigger problems than can be helped by DNS rate limiting.

A relevant question is whether you really need to run an open recursive
DNS server.  There are situations where DNS server operators must
answer untrustworthy clients, but there are also many open recursive
DNS servers without that excuse.  Could you stop answering DNS requests
from strangers?


> On the flip side, I am seeing a few frequent victim IPs in the
> DNS requests.  They come and go freqeuently so I get a bit of
> window-shading.  Anyway to blacklist a range to do the SLIP thing?

I don't understand that question unless the answer is put the
frequent victims into a view with "rate-limit{... slip 1; ....};"
If that is the answer, it is probably a right answer to the wrong
question.  Unlike *CLIENT* rate limiting, the BIND9 rate limiting patch
is *RESPONSE* rate limiting.  A victim that does not send any of the
requests forged in a reflection attack *IS NOT AFFECTED* by BIND9 rate
limiting.  There is no reason to apply the SLIP thing to requests from
a victim that differ from the stream of forged requests.

For example, if the forged attack requests are for "ANY isc.org", then
there is almost certainly no reason to worry about legitimate requests
from the victim, because the victim is unlikely to request "ANY isc.org".
Only the forged "ANY isc.org" requests will be affected by the BIND9
response rate limiting.

I apologize for shouting, but the confusion between client and
response rate limiting is incredibly persistent and widespread.
There is an endless stream of suggestions, complaints, and assertions
based on that confusiion.


Vernon Schryver    vjs at rhyolite.com