[DNSOP] Re: Fwd: New Version Notification for draft-bortzm eyer-dnsop-poisonlicious-05.txt

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

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


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=E2=80=AFPM 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 Securi=
ty
>>    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=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" <otto.moerbeek@powerdns=
.com>,
>>  "Stephane Bortzmeyer" <[email protected]>,
>>  "Willem Toorop" <[email protected]>
>> Subject: New Version Notification for draft-bortzmeyer-dnsop-poisonlicio=
us-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-poisonl=
icious-05.txt
>> Status:   https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poison=
licious/
>> HTML:     https://www.ietf.org/archive/id/draft-bortzmeyer-dnsop-poisonl=
icious-05.html
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-bortzmeyer-dnsop-p=
oisonlicious
>> Diff:     https://author-tools.ietf.org/iddiff?url2=3Ddraft-bortzmeyer-d=
nsop-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]

=2D-=20
Babak Farrokhi

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

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

iKUEARYKAE0WIQRu+73tYCYKk7tFGWuCnEUHptH9aQUCanNb/hsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMTHGJhYmFrQGZhcnJva2hpLm5ldAAKCRCCnEUHptH9
acOIAQDkZjywgACR/sj2+qmkCASlP3iybBf3dVU9We5PcZbcVQEA3RFpxE+7IOLT
277APypQ59PsxqnBIMCvYM9Bz6Lrww4=
=YEnF
-----END PGP SIGNATURE-----
--=-=-=--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============0734350268887401795==--