Bug 4211 - Exclude [interface/port/IP-address(es)] from ip-ratelimit
Exclude [interface/port/IP-address(es)] from ip-ratelimit
Status: NEW
Product: unbound
Classification: Unclassified
Component: server
Other All
: P5 normal
Assigned To: unbound team
Depends on:
  Show dependency treegraph
Reported: 2018-11-27 17:38 CET by Fredrik Pettai
Modified: 2019-02-12 14:14 CET (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Fredrik Pettai 2018-11-27 17:38:55 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.
Comment 1 Eric Luehrsen 2018-11-28 05:02:07 CET
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.
Comment 3 Fredrik Pettai 2018-12-10 09:12:32 CET
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>
 or perhaps 
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.
Comment 4 Fredrik Pettai 2019-02-12 14:14:59 CET
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.