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/[email protected]/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/
