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." > > >
signature.asc
Description: OpenPGP digital signature
