<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite"><br>
On 23.11.2018 18:36, via Unbound-users wrote: <br>
<br>
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?<br>
</blockquote>
<br>
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."<br>
<br>
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).<br>
<br>
<blockquote type="cite">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.<br>
</blockquote>
<br>
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."<br>
<br>
<br>
<br>
</body>
</html>