On Wed, Aug 5, 2026 at 10:54 AM Petr Špaček <[email protected]> wrote: > On 04. 08. 26 22:00, Ben Schwartz wrote: ... > > My question is whether we should be pursuing this > > architecture (an O(N) response "broadcast" for cache sharing), as > > opposed to some other architecture (such as a multilayer cache > > architecture). Are you running broadcast-style cache sharing in > > production? > > It does not have to be broadcast, does it? Generally it is discretion of > the sender to whom it will get delivered, and I would expect great > variety in strategies here. E.g. not sending NXDOMAINs unless they pass > some heuristic etc.
Filtering which responses are shared seems plausible. Delivering different responses to subsets of the fleet in a useful way seems much more difficult. If I were trying to use poisonlicious in a highly optimized architecture, it would look like this: 1. The stub issues a query. 2. The query hits a dispatcher (dnsdist), which routes it to a resolver instance based on hash(qname) 3. The resolver starts working, encountering some cache misses along the way. On cache miss, it sends an RD=0 (i.e. cache snooping) query back to the dispatcher, which forwards it to the responsible instance by hash(qname). 4. If the cache snooping query fails, the resolver queries upstream, and copies the response to the dispatcher via poisonlicious. 5. The dispatcher forwards the poisonlicious response to the instance responsible for hash(qname), which adds it to the cache. If an architecture like this is in scope for poisonlicious, then I think it would be useful. I don't see any technical impediment within the present draft, but perhaps the operational considerations could be expanded to note the possibility of a dispatcher and "lookaside snooping" behavior. --Ben Schwartz _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
