IN TXT & NULL trash records

[Maciej Gawron]

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
<unbound-users at nlnetlabs.nl> 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."
> >
> >
> >
>