[DNSOP] Fwd: New Version Notification for draft-bortzmeyer-d nsop-poisonlicious-05.txt

--===============7614490162009214076==
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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=20
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:

=2D 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.

=2D 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.

=2D 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.

=2D 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.

=2D 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?



=2D------------------- Start of forwarded message --------------------
From: [email protected]
To: "Ond=C5=99ej Sur=C3=BD" <[email protected]>,
 "St=C3=A9phane Bortzmeyer" <[email protected]>,
 "Babak Farrokhi" <[email protected]>, "Moin Rahman" <[email protected]>,
 "Ondrej Sury" <[email protected]>, "Otto Moerbeek" <[email protected]=
m>,
 "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-poisonlici=
ous-05.txt
Status:   https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poisonlic=
ious/
HTML:     https://www.ietf.org/archive/id/draft-bortzmeyer-dnsop-poisonlici=
ous-05.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-bortzmeyer-dnsop-pois=
onlicious
Diff:     https://author-tools.ietf.org/iddiff?url2=3Ddraft-bortzmeyer-dnso=
p-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


=2D------------------- End of forwarded message --------------------

Best Regards,

=2D-=20
Babak Farrokhi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iKQEARYKAE0WIQRu+73tYCYKk7tFGWuCnEUHptH9aQUCanI5DhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMTHGJhYmFrQGZhcnJva2hpLm5ldAAKCRCCnEUHptH9
aUT9AQCB5/4YW+OgOFBjTYhM+p4pjhvmiuEb3JMAHEMzUfPhlQD3VSYZsPPi9IRd
dg/GxSIqS1A/e8e/Y0qHBlEjQz+7Bg==
=Z/G6
-----END PGP SIGNATURE-----
--=-=-=--


--===============7614490162009214076==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============7614490162009214076==--