Bugzilla – Bug 4211
Exclude [interface/port/IP-address(es)] from ip-ratelimit
Last modified: 2019-02-12 14:14:59 CET
ratelimiting is a nice addition, but it's currently like a big sledge 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 network range(s).
Like if loopback could be excluded by default, I'd be fine with that.
Use Case: This could be used in an any-cast global cluster of Unbound servers. They may prefer queries that are near over distant. They may prefer known consumer grade ISP blocks over the rest falling outside the intended audience. It is not desired to block (firewall) these IP blocks, but rather bias rate preference.
Use Case: This could be used so that Unbound could serve a public-private split
network such as a restaurant. The business side of the network would have a lot of blackhole DNS for ads and malicious sites (in view: clause), but unlimited queries. The guest side of the network would be uncensored and not resolve any DHCP DNS (again view:), but have query limits to prevent abuse against the local restaurant router/DNS appliance.
It seems ip-ratelimit-factor can at best allow 50% of the ratelimit exceeding queries through, although the man page explained formula "hint" that 100% should be doable thru setting ip-ratelimit-factor to 1 (1/X). But instead "1" gives the same behaviour as "0". A bug in unbounds behaviour or man page?
Allowing either "ip-ratelimit-factor: 1 (or 0 would perhaps be more logical, (as 0 usually is used to turn off something in unbound) to allow 100% of the exceeding queries to pass normally would be most helpful for debugging purposes, just making unbound signal then clients pass the ip-ratelimit without interfering / dropping queries.
Here are some alternative ideas to the earlier suggested per subnet ip-ratelimit:
1) Mimic what's common in the "IP 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/seconds for allowed burst>
2) Another approach would be to allow to configure the ip-ratelimit-factor to be exponential over time (as an alternative to the fixed behaviour), slowly dropping a bigger amount of the exceeding queries over time.
btw. for option 2) it would also make sense to have a sort of burst allowance value (say 3 seconds) so the client(s) can send a bigger amount of queries for a few seconds before the ratelimiting starts to react.