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
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
