Better ratelimiting? (again)

[Benno Overeinder]

Hi Fredrik,

Top posting, sorry.

Probably it makes also sense to make this configuration option dynamic
via unbound-control (via setoption opt: val).

Cheers,

-- Benno


On 13/12/2018 22:30, Fredrik Pettai via Unbound-users wrote:
> Hi,
> 
> (ip-)ratelimiting is a nice addition, but it's currently like a big hammer, since it's basically on/off for the unbound instance.
> I'd like to have some sort of possibility to exclude a part of unbound from this, be it a interface, a dedicated port(listner) or configurable IP-network range(s).
> (Ref https://www.mail-archive.com/unbound-users@unbound.net/msg05119.html)
> 
> Some alternative ideas to the earlier suggested per subnet ip-ratelimit:
> 
> 1) Mimic what's common in the "networking world", allowing to configure a (higher) burst limit, could be a way of allowing bursty clients to finish all lookups without getting slowed down by dropped queries. 
> 
> ip-ratelimit-burst: <max-limit>
>  or perhaps 
> ip-ratelimit-burst: <max-limit/seconds>  # X seconds of burstiness allowed 
> 
> 
> 2) Another approach would be to allow to configure the ip-ratelimit-factor to be exponential over time (as an alternative to the fixed 1/X behavior), slowly dropping a bigger amount of the exceeding queries over time (by for instance increasing X +1 every second.)
> 
> 
> I personally like the per-subnet option the most, as it gives full control over ip-ratelimiting. 
> But 2) seems like a low hanging fruit implementation wise, and would be very helpful compared to the current state. It could be applied to ratelimit(-for-domain etc.) too (if that would be useful?)
> 
> Re,
> /P
> 


-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/