Regarding adoption: Has anyone deployed something like this? In large scale resolvers I expect to see something more akin to Unbound's Cache DB module [1], backed by a shared database. This arrangement could be called "L2 caching", and it achieves the same effect as poisonlicious at much lower communication and memory cost (but with greater complexity and slightly slower resolution).
If poisonlicious is substantially deployed then I suppose we should adopt and formalize it, but otherwise I feel it would be better to focus our effort on standards that more closely match the architectures we see in the world. --Ben Schwartz [1] https://nlnetlabs.nl/documentation/unbound/doxygen/cachedb_8h.html On Tue, Aug 4, 2026 at 3:11 PM Babak Farrokhi <[email protected]> wrote: > > > Dear DNSOP, > > This is the revision -05 of the Poisonlicious draft (not a great name, > in retrospect), which came out of the DNS Hackathon in Stockholm in > March last year. > We have not written to the list since -01, and almost everything in this > revision comes from feedback we received here, so thank you for all your > input so far. > > Changes: > > - We removed the requirement that said the participating resolvers > should sit in same organizational domain. It is now the mutual trust > and an agreed policy. > In exchange, when the peers are not under the same administration, the > originator MUST now remove the question section. > > - We tightened two requirements that were implied in previous revisions. > The resolver MUST send only data that it is sure of, and a resolver > that cannot rely on its peers applying the agreed policy MUST NOT > accept their data. > > - TSIG is now mandatory to implement but optional to use, following > Section 7 of BCP 61 (RFC 3365). Implementations MUST support it, > therefore there is always at least one common authentication > mechanism. > > - The draft now says how the TSIG MAC is computed for these messages. > These are responses signed like a query (Section 5.1 RFC 8945), with > no request MAC (Section 4.3.1). This already separates these messages > from ordinary response, and the dedicated TSIG key is now a SHOULD. > > - We hardened the privacy text on snooping. Since the messages contain > the resolved names, they reveal to an eavesdropper what their clients > queried, therefoe removing the question section is not enough. > Either an Encrypted transport or a protected path,is now RECOMMENDED. > > We need input on the followings: > > 1- Paul Wouters asked for a mode allowing mutually untrusted nodes to > share only DNSSEC-validated data, like pool.ntp.org does. We have not > done that, since we think it is a different trust model from what > draft describes. We would like to know if the group wants it in > scope. > > 2- We left the operational choice of security mechanism open, and there > is no strict requirement for authentication in deployment. But Security > Considerations says "trust between the peer resolvers is expected > because it is the only way for the receiver to be sure of the data". > We think that is right for closed groups, but we want to know if this > is too loose. > > And the obvious question: is there interest in adopting this in DNSOP? > > > > -------------------- Start of forwarded message -------------------- > From: [email protected] > To: "Ondřej Surý" <[email protected]>, > "Stéphane Bortzmeyer" <[email protected]>, > "Babak Farrokhi" <[email protected]>, "Moin Rahman" <[email protected]>, > "Ondrej Sury" <[email protected]>, "Otto Moerbeek" <[email protected]>, > "Stephane Bortzmeyer" <[email protected]>, > "Willem Toorop" <[email protected]> > Subject: New Version Notification for > draft-bortzmeyer-dnsop-poisonlicious-05.txt > Date: Tue, 04 Aug 2026 11:02:38 -0700 > > A new version of Internet-Draft draft-bortzmeyer-dnsop-poisonlicious-05.txt > has been successfully submitted by Babak Farrokhi and posted to the > IETF repository. > > Name: draft-bortzmeyer-dnsop-poisonlicious > Revision: 05 > Title: Synchronizing caches of DNS resolvers > Date: 2026-08-03 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-bortzmeyer-dnsop-poisonlicious-05.txt > Status: > https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poisonlicious/ > HTML: > https://www.ietf.org/archive/id/draft-bortzmeyer-dnsop-poisonlicious-05.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-bortzmeyer-dnsop-poisonlicious > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-bortzmeyer-dnsop-poisonlicious-05 > > Abstract: > > Networks of cooperating and mutually trusting DNS resolvers could > benefit from cache sharing, where one resolver would distribute the > result of a resolution to other resolvers. This document > standardizes a protocol to do so. > > > > The IETF Secretariat > > > -------------------- End of forwarded message -------------------- > > Best Regards, > > -- > Babak Farrokhi > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
