[DNSOP] Re: Synchronizing caches of DNS resolvers ("pois onlicious" draft)
George Michaelson <[email protected]> Wed, 29 Jul 2026 08:19:41 +1000
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <CAKr6gn0K-Dpot4Ls9Npj4mkE1VM2uZBe1jh+pqOhrEyiy2Lm5g@mail.gmail.com> |
--===============6396184912469807521== Content-Type: multipart/alternative; boundary="000000000000f26c250657b33c4c" --000000000000f26c250657b33c4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can you state clearly why? What is the primary concern here? I think a proscriptive direction should provide reasoning. -G On Wed, Jul 29, 2026 at 5:45=E2=80=AFAM Tim Wicinski <[email protected]> w= rote: > 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 t= o > 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 se= t >> key and value) must be declared by the RFC standard by default. This wou= ld >> leave administrators the option to upgrade/replace (should/may) choose t= o >> 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]> wrot= e: >> > >> > =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. >> > >> > Ondrej >> > -- >> > Ond=C5=99ej Sur=C3=BD (He/Him) >> > >> > A gentle nudge is always appreciated if I take a little longer to repl= y. >> > >> >> 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 >> 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 goin= g >> 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 cod= e 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 tim= e, >> 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] >> > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --000000000000f26c250657b33c4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Can you state clearly why? What is the primary concern her= e? I think a proscriptive direction should provide reasoning.<div><br></div= ><div>-G</div></div><br><div class=3D"gmail_quote gmail_quote_container"><d= iv dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 29, 2026 at 5:45=E2=80=AFAM= Tim Wicinski <<a href=3D"mailto:[email protected]">[email protected]<= /a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><= div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospace= ">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"><div dir=3D"ltr" class=3D"gmail_attr">On T= ue, Jul 28, 2026 at 2:43=E2=80=AFPM Simon Jackson <simon=3D<a href=3D"ma= ilto:[email protected]" target=3D"_blank">40jacksonfamily.m= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-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> _______________________________________________<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> --000000000000f26c250657b33c4c-- --===============6396184912469807521== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============6396184912469807521==--