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.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
