[DNSOP] Re: Synchronizing caches of DNS resolvers ("poi sonlicious" draft)
Bill Woodcock <[email protected]> Tue, 28 Jul 2026 15:03:26 +0545
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
--===============5314778351270445811== Content-Type: multipart/signed; boundary="Apple-Mail=_614EECCE-D9BE-4ED4-AE47-A5A1ACC98D58"; protocol="application/pgp-signature"; micalg=pgp-sha256 --Apple-Mail=_614EECCE-D9BE-4ED4-AE47-A5A1ACC98D58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 28, 2026, at 14:38, Ond=C5=99ej Sur=C3=BD <[email protected]> = wrote: >=20 >> On 27. 7. 2026, at 07:54, Bill Woodcock <[email protected]> wrote: >>=20 >>=20 >>=20 >>> On Jul 20, 2026, at 17:55, Stephane Bortzmeyer = <[email protected]> wrote: >>> = https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poisonlicious/ >>=20 >> I strongly support the effort, but would prefer DoT to be mandatory, = and DANE authentication to be preferred over TSIG, when available. >=20 > I strongly believe the security mechanism should be a matter of local = policy > (and implementation defaults) rather than something enforced by the = Internet > Standard. >=20 > So far, the DNS does not even enforce a secure transport and/or = authentication > for XFRs, so enforcing DoT/DANE/whatever for something that is going = to be > mostly used on internal networks feels over the top. Sorry, I should have said DoQ/DoT; force of habit. I hear you, but I think that as long as we make security optional, a lot = of people won=E2=80=99t bother, and then a lot of people writing code = won=E2=80=99t prioritize it, and then it won=E2=80=99t work when it=E2=80=99= s needed. Whereas if everything is as secure as our current standards = facilitate, all the time, we only have a single build target and test = case and the most-sensitive traffic doesn=E2=80=99t have a target = painted on its back. Why should HTTP be secure-by-default, but DNS not? -Bill --Apple-Mail=_614EECCE-D9BE-4ED4-AE47-A5A1ACC98D58 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEm6XJ0FdpKWJHso4lb6RwSyiLf4cFAmpoc+IACgkQb6RwSyiL f4eOMw//SZIWIcRZ/ID02FpUgaEhH/EghGzCCffh+EECTAIccjD6j/wQ8zz01tIu abMY7STFwElC6O5ad5+kZK56AFwXHi34SRkz6sMITxZujwVqeqFM/ASfEQfwOaWE EYz7SgR9jxyzKsABXR7eQx2ry0AEL62lA0cTRzoOmiudmDdSrsVuxWSPT4AbFa6k rpG8ebaKw3ANgDeBsjxP1G5H3wMAYLHl4DlWm6N6nMLmzTGJcYacUtbbU7i9zwu1 QHrzj0a0Flspph8j6JnUc98kEO1NJH0jeVoiGA1ssGi9vF+GOCUeFaWW5QGdEIKs RAJNj08YfNd4cbXQri/FlBt/x68SOkYKebxJIvyWnX7o/wVeNzyYtulQDj3ARkO+ xos2jOtGKce5iQ9ungXB6IgMG+N10STUyw+VjOrFZ1pZ0aZNdaA93cJdByHGt3nS R2OCksJDBfrRBHmDIm9TJscoRGy4m0cshvs180Q+f1wYq7F4yR7MvBDPQc3K4a5R vSmaKswWLFLzkFRACdyx1QSIzoxOyv9CZkxm4yAGRq/esXQ22gBtJNFOIMRtcLn5 D7JyRo09hj87BsxDr0vXGHdBegxWstPmCdu/CKI59SGS9Oj+My58/AadxttcqaQv kgJHaah6u+P8U81EmCTt4zZWitmCQ19uEu7sbPWHygjv0o6rCjs= =ABM5 -----END PGP SIGNATURE----- --Apple-Mail=_614EECCE-D9BE-4ED4-AE47-A5A1ACC98D58-- --===============5314778351270445811== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============5314778351270445811==--