[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==--