[DNSOP] Re: Synchronizing caches of DNS resolvers ("pois onlicious" draft)

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

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


Tim Wicinski <[email protected]> wrote:
    > But I SHOULD NOT be allowed to
    > synchronize unsigned DNS records from resolvers not under my locus of
    > control.

Is it:
1. that your cache should refuse to accept to synchronize over an insecure =
channel?
2. that the other resolver should refuse to send synchronization data over =
an
   insecure channel?

It seems that we are conflating "locus of control" with secure channel, the
assumption being that if you control a resolver that you can secure the cha=
nnel?

I can see lots of debug situations where it would be useful to yank the
current cache over a channel for later debugging.   How that's secured seems
a local concern; I can well see IP/v6 acceptlists (and ::1) being considered
secure.

So, I think it's really (1), not (2)?

(I can *also* see situations where I might want to load a specific cache
contents into a resolver in order to replicate how it behaves when certain
conditions occur.  Debug.  Compile. Restart.  Up-arrow Return)

    >> I agree entirely.
    >>
    >> We are dealing with Key-Value paired parameters, right?
    >>
    >> Perhaps an unspecified configuration (where the administrator has not
    >> set key and value) must be declared by the RFC standard by
    >> default. This would leave administrators the option to upgrade/repla=
ce
    >> (should/may) choose to override each security parameter (key-value
    >> pair), selecting from the approved list of values.
    >>
    >> > On 28 Jul 2026, at 12:26, Ond=C5=99ej Sur=C3=BD <[email protected]> =
wrote:
    >> >
    >> > =EF=BB=BFAbsolutely, the draft should say that the backchannel SHO=
ULD be
    >> authenticated and secure. I am just against enforcing specific means
    >> to achieve this.
    >> >
    >> > Ondrej
    >> > --
    >> > Ond=C5=99ej Sur=C3=BD (He/Him)
    >> >
    >> > A gentle nudge is always appreciated if I take a little longer to
    >> reply.
    >> >
    >> >> On 28. 7. 2026, at 12:38, Simon Jackson <simon=3D
    >> [email protected]> wrote:
    >> >>
    >> >> =EF=BB=BFPerhaps clear use of the verbs MUST, SHOULD, MAY, COULD=
=E2=80=A6  >> Simon
    >> >>
    >> >>>> On 28 Jul 2026, at 10:19, Bill Woodcock <[email protected]> wrote:
    >> >>>
    >> >>> =EF=BB=BF
    >> >>>
    >> >>>>> On Jul 28, 2026, at 14:38, Ond=C5=99ej Sur=C3=BD <ondrej@sury.=
org> wrote:
    >> >>>>>
    >> >>>>>> On 27. 7. 2026, at 07:54, Bill Woodcock <[email protected]> wrote:
    >> >>>>>
    >> >>>>>
    >> >>>>>
    >> >>>>>>> On Jul 20, 2026, at 17:55, Stephane Bortzmeyer <bortzmeyer=3D
    >> [email protected]> wrote:
    >> >>>>>>>
    >> https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poisonliciou=
s/
    >> >>>>>>
    >> >>>>>> I strongly support the effort, but would prefer DoT to be
    >> mandatory, and DANE authentication to be preferred over TSIG, when
    >> available.
    >> >>>>
    >> >>>> I strongly believe the security mechanism should be a matter of
    >> local policy >>>> (and implementation defaults) rather than something
    >> enforced by the Internet >>>> Standard.
    >> >>>>
    >> >>>> 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 optiona=
l,
    >> a lot of people won=E2=80=99t bother, and then a lot of people writi=
ng code
    >> won=E2=80=99t prioritize it, and then it won=E2=80=99t work when it=
=E2=80=99s 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
    >> >>>
    >> >>> _______________________________________________ >>> DNSOP mailing
    >> list -- [email protected] >>> To unsubscribe send an email to
    >> [email protected] >>> <signature.asc>
    >> >
    >>
    >> _______________________________________________ DNSOP mailing list --
    >> [email protected] To unsubscribe send an email to [email protected]
    >>

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------
    > _______________________________________________ DNSOP mailing list --
    > [email protected] To unsubscribe send an email to [email protected]

=2D-
Michael Richardson <[email protected]>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-                      *I*LIKE*TRAINS*




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

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

iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmppgr4ACgkQlUzhVv38
QpB5Fgf8Dbxkh77GLTiF3fBologkwUsUgPgKWwl6PO68Itx8EBaEHkFMzLYhoVO+
FE3dXHJ5T8B9aEoJcTduWUmTLROkh2k07A8m+0whnezfFE/wfKIJFsCPmZx4zaS6
l5AJqYzLFWMPn6HcQnzK+N7QNpnf+MkPZt9aGSrIa5D2b/HnWn2txkFV2TFuakOY
sS1jE+sE/7O903iDwRW9RJPZeWkmD59l7YHe3YS+ujtnl7RHPbIhdrrPJv9G9XBE
k3p+9QYDk7jXYFsZy1dSU2vs+4RXd5CCKENKUVII4bnpcZ9PPJDkwVoca/3XKiC7
54SOy4Pma4W1ByxkXNJldv/GiXjTzw==
=4sPE
-----END PGP SIGNATURE-----
--=-=-=--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============4145165205332554455==--