IN TXT & NULL trash records

[Wouter Wijngaards]

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."
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181126/e4b77103/attachment.bin>