Petr Špaček <[email protected]> writes: > On 05. 08. 26 17:33, Ben Schwartz wrote: >> 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. > > I would much prefer if we just defined what messages on the wire mean > and left implementations to figure out what's best for them. We have > bunch of resolvers with different strategies and there's a reason for > it - different deployments have different requirements. DNS is nowhere > close to one size fits all.
I agree with Petr here. I understand that implementers don't want to add more complex logic to their implementation, and by that to introduce new failures modes and security risks. On the topic of broadcast: My idea setup would involve a multicast group in a cluster, where a resolver can decide to join or leave. Like a resolver with a cold-cache to join the group and warm up the cache, and then leave when it reaches a certain level of cache hit ratio threshold. BR, -- Babak Farrokhi
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
