[DNSOP] Re: New Version Notification for draft-bortzmeyer-dnsop-poisonlicious-05.txt

[Ben Schwartz <[e-mail]>]

On Wed, Aug 5, 2026 at 10:54 AM Petr Špaček <[e-mail]> 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