[DNSOP] Re: Synchronizing caches of DNS resolvers ("pois onlicious" draft)
Tim Wicinski <[email protected]> Tue, 28 Jul 2026 15:44:38 -0400
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <CADyWQ+HXY_Hy5_O=MCf2GMGRVKrR70HikKAZ8MRP7DQgCOXoQQ@mail.gmail.com> |
--===============2399014632297694974== Content-Type: multipart/alternative; boundary="0000000000006695400657b112f7" --0000000000006695400657b112f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adopting this draft. As for the security mechanism, I agree that it SHOULD be authenticated but also local policy. If I run a fleet of resolvers and control their cache, I SHOULD be able to synchronize even unsigned DNS records. But I SHOULD NOT be allowed to synchronize unsigned DNS records from resolvers not under my locus of control. On Tue, Jul 28, 2026 at 2:43=E2=80=AFPM Simon Jackson <simon=3D [email protected]> wrote: > 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 woul= d > leave administrators the option to upgrade/replace (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 SHOULD b= e > 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 <[email protected]> = 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-poisonlicious/ > >>>>>> > >>>>>> 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 loca= l > 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 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=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] > --0000000000006695400657b112f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac= e">I support adopting this draft.=C2=A0 =C2=A0As for the security mechanism= , I agree that it SHOULD be authenticated=C2=A0but also local=C2=A0policy.= =C2=A0</div><div class=3D"gmail_default" style=3D"font-family:monospace">If= I run a fleet of resolvers and control their cache, I SHOULD be able to sy= nchronize even unsigned DNS records.=C2=A0</div><div class=3D"gmail_default= " style=3D"font-family:monospace">But I SHOULD NOT be allowed to=C2=A0synch= ronize unsigned DNS records from resolvers not under my locus of control.</= div><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div>= <div class=3D"gmail_default" style=3D"font-family:monospace"><br></div></di= v><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cla= ss=3D"gmail_attr">On Tue, Jul 28, 2026 at 2:43=E2=80=AFPM Simon Jackson <= ;simon=3D<a href=3D"mailto:[email protected]">40jacksonfami= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex">I agree entirely.<br> <br> We are dealing with Key-Value paired parameters, right?<br> <br> Perhaps an unspecified configuration (where the administrator has not set k= ey and value) must be declared by the RFC standard by default. This would l= eave administrators the option to upgrade/replace (should/may) choose to ov= erride each security parameter (key-value pair), selecting from the approve= d list of values.<br> <br> > On 28 Jul 2026, at 12:26, Ond=C5=99ej Sur=C3=BD <<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > =EF=BB=BFAbsolutely, the draft should say that the backchannel SHOULD = be authenticated and secure. I am just against enforcing specific means to = achieve this.<br> > <br> > Ondrej<br> > --<br> > Ond=C5=99ej Sur=C3=BD (He/Him)<br> > <br> > A gentle nudge is always appreciated if I take a little longer to repl= y.<br> > <br> >> On 28. 7. 2026, at 12:38, Simon Jackson <simon=3D<a href=3D"mai= lto:[email protected]" target=3D"_blank">40jacksonfamily.me= @dmarc.ietf.org</a>> wrote:<br> >> <br> >> =EF=BB=BFPerhaps clear use of the verbs MUST, SHOULD, MAY, COULD= =E2=80=A6<br> >> Simon<br> >> <br> >>>> On 28 Jul 2026, at 10:19, Bill Woodcock <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> >>> <br> >>> =EF=BB=BF<br> >>> <br> >>>>> On Jul 28, 2026, at 14:38, Ond=C5=99ej Sur=C3=BD <<= a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>= wrote:<br> >>>>> <br> >>>>>> On 27. 7. 2026, at 07:54, Bill Woodcock <<a hre= f=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<b= r> >>>>> <br> >>>>> <br> >>>>> <br> >>>>>>> On Jul 20, 2026, at 17:55, Stephane Bortzmeyer= <bortzmeyer=3D<a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a>> wrote:<br> >>>>>>> <a href=3D"https://datatracker.ietf.org/doc/dr= aft-bortzmeyer-dnsop-poisonlicious/" rel=3D"noreferrer" target=3D"_blank">h= ttps://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poisonlicious/</a><b= r> >>>>>> <br> >>>>>> I strongly support the effort, but would prefer Do= T to be mandatory, and DANE authentication to be preferred over TSIG, when = available.<br> >>>> <br> >>>> I strongly believe the security mechanism should be a matt= er of local policy<br> >>>> (and implementation defaults) rather than something enforc= ed by the Internet<br> >>>> Standard.<br> >>>> <br> >>>> So far, the DNS does not even enforce a secure transport a= nd/or authentication<br> >>>> for XFRs, so enforcing DoT/DANE/whatever for something tha= t is going to be<br> >>>> mostly used on internal networks feels over the top.<br> >>> <br> >>> Sorry, I should have said DoQ/DoT; force of habit.<br> >>> <br> >>> I hear you, but I think that as long as we make security optio= nal, 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=99s needed.=C2=A0 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 pain= ted on its back.<br> >>> <br> >>> Why should HTTP be secure-by-default, but DNS not?<br> >>> <br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -Bill<br> >>> <br> >>> _______________________________________________<br> >>> DNSOP mailing list -- <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a><br> >>> To unsubscribe send an email to <a href=3D"mailto:dnsop-leave@= ietf.org" target=3D"_blank">[email protected]</a><br> >>> <signature.asc><br> > <br> <br> _______________________________________________<br> DNSOP mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">d= [email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a><br> </blockquote></div> --0000000000006695400657b112f7-- --===============2399014632297694974== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============2399014632297694974==--