A major blocker is interop. It is difficult to get everyone agree on a same shared KV Store and the same data structure. And this may also not be viable if you are serving several hundred thousands of QPS in a cluster. One thing every DNS Resolver agrees on is, well, DNS protocol.
We are currently working on implementing the patched Unbound in some canary locations to measure the production impact, and I was hoping I can share the results during the next meeting. BR, Babak Ben Schwartz <[email protected]> writes: > 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] -- Babak Farrokhi
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
