On Tue, Mar 02, 2021 at 07:01:10PM -0200, Viktor Dukhovni wrote: > > On Mar 2, 2021, at 6:46 PM, Peter van Dijk <[email protected]> > > wrote: > > > > Compared to REFUSED, the synthetic RRSIG has the benefit of not causing > > a retry towards another auth (as Florian said); why not go another step > > then and make it cacheable? You say 'no point in caching', I agree, but > > then how about going another step and saying 'no point in a resolver > > repeating this question on behalf of a client every second' - so put a > > juicy TTL on it. > > That way caches end up storing useless garbage, so the question is what > to optimise for, avoiding filling caches with garbage when each query > asks for a different name, or avoiding repeated queries for the RRSIG > of a fixed name. ...
caches operate at equilibrium. the working set doesn't begin to cover the TTL before exhaustion. caching something that doesn't get reused quickly and thereafter reused often is a zero-cost affair, it'll face discard at a priority in keeping with its observed value. we should not reason from "not storing useless garbage" in a world already containing wildcards and synthesis. it's all garbage, mostly useless, and differentiating between one kind of garbage and another is a fool's errand. -- Paul Vixie _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
