Hi, I think global IP-ratelimit will fit nicely. Do you have information about typical values used in networks (recommendiations) ? I will do my own research, but it would be great to have some reference.
I am also thinking about dropping large packets (since they are used only for tunnel purposes) Thanks a lot pon., 26.11.2018, 10:28: Wouter Wijngaards via Unbound-users <[email protected]> napisał(a): > > Hi, > > Unbound has ratelimit options for both user query count (ip-ratelimit) > and number of iterative queries under a domain beneath a zone > (ratelimit-below-domain and ratelimit-for-domain). The first is per-IP > address, the second based on domain name. Could set a global number, or > specify the culprit's client-IP or the tunnel service domain name. > > Best regards, Wouter > > On 11/23/18 7:44 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote: > >> > >> On 23.11.2018 18:36, via Unbound-users wrote: > >> > >> however, those concerns are in a way off topic for this mailing list, > >> so allow me to ask a more direct unbound question. why does the cache > >> bloat? you're using LRU replacement, and these records are never > >> accessed. therefore while they can push other more vital things out of > >> the cache, decreasing cache hit rate, they should be primary targets > >> for replacement whenever other data is looking for a place to land. i > >> understand that this cache churn has a cost, in bandwidth and in CPU, > >> but not in memory -- once the cache reaches its working set maximum, > >> it ought to grow no further. what could i be misunderstanding about this? > > > > Your understanding is correct I trust and bloating been a misdirection > > indeed. Referring to initial post: "Since I am observing a lot of DNS > > Tunnel “users” , the cache started to store totally useless records of > > type TXT and NULL." > > > > And in this context those queries, which to my understanding can be of > > high frequency in a DNS tunnel (depending on its purpose), are replacing > > legitimate records once the max. cache size is reached. And as you > > stated churning the cache comes at a cost. I am wondering what > > legitimate purpose it is for the resolver not only to cache NULL records > > but even serve them to clients other than perhaps some corporate > > edge/niche cases considering that at least rfc1035 does not specify a > > legitimate purpose for NULL records (as of today). > > > >> a second unbound-related topic is cache management itself. it is > >> unusual for the splay between a name and its descendants to number in > >> the millions. it happens for arpa, and popular TLD's such as COM, NET, > >> ORG, and DE. as a cache management strategy, consider whether to more > >> rapidly discard descendants of a high splay apex, unless they are > >> accessed at least once. and in defiance my fear-related argument > >> above, when the cache is full beyond some threshold like 90%, consider > >> using the "splay is high, subsequent access of descendants is zero" as > >> a signal to (a) not cache new descendant data, and (b) syslog it. > >> there isn't a dnstap message-tag for this condition yet, but there > >> ought to be. splay is easy to keep track of unless your cache is flat. > > > > After reading it I thought that something like Rate-limiting Fetches Per > > Zone as implemented in BIND would be helpful to have in unbound too: > > "which defines the maximum number of simultaneous iterative queries to > > any one domain that the server will permit before blocking new queries > > for data in or beneath that zone." > > > > > > >
