[dns-operations] resolver cache question

[Mark Allman]

> One could use a Bloom filter to avoid caching (most) lookup
> results that are encountered just once.  Or start out with an
> artifically lowered TTL combined with prefetching.

I am not sure what you mean.  If a given lookup isn't in a bloom
filter, add it to the bloom filter and if it is cache it?

I dunno ... do we need that?  That's sort of the question.  Do
caches end up evicting useful records because of these one-time
records?  Or, do current cache sizes and eviction policies just
basically handle this without a lot of complication?  I really have
no idea.

> The authoritative server operators know that their zones are used
> for what is essentially an RPC.  Don't they set a zero TTL?

No.  The first paper I cited says in their dataset the one-time
lookups have TTLs on the order of 600sec (on median or something I
can't quite recall).  So, non-trivial.

> So maybe this is about ignoring low TTLs to increase cache hit
> rates.  Unfortunately this report is behind a paywall, and I'm not
> going to spend $35.95 to find out if the authors have considered
> Bloom filters and the rest.

Yeah- annoying as hell.  The particulars are different, but [3] has
the same sort of thrust.  I.e., infer which lookups will only be
used once and don't cache them.  I should have linked to this, as
well, in the first message.  The investigation is fine as far as it
goes.  But, it makes some assumptions about the size and operation
of the cache and those are the aspects I'd like to better
understand from folks who run real resolvers.

allman


[3] https://ccronline.sigcomm.org/2017/exploring-domain-name-based-features-on-the-effectiveness-of-dns-caching/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 220 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20201113/231a7e3d/attachment.sig>