[DNSOP] Re: Synchronizing caches of DNS resolvers ("pois onlicious" draft)
Tim Wicinski <[email protected]> Wed, 29 Jul 2026 00:49:13 -0400
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <CADyWQ+FvkvOqVLWaoOWc1+P6Y3Ez2gnqkt6vmht6KbbBd_YUdw@mail.gmail.com> |
--===============3153857087550230614== Content-Type: multipart/alternative; boundary="00000000000010c7590657b8aece" --00000000000010c7590657b8aece Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2026 at 12:34=E2=80=AFAM Michael Richardson <mcr+ietf@sande= lman.ca> wrote: > > 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 insecur= e > channel? > 2. that the other resolver should refuse to send synchronization data ove= r > an > insecure channel? > Sorry I was agreeing that if you are synchronizing DNS records across multiple providers, etc, those records should be DNSSEC signed records only. How the resolvers communicate is a decision they can make. I was suggesting that if I control all the resolvers, I should be OK with synchronizing DNS records not signed by DNSSEC. tim > It seems that we are conflating "locus of control" with secure channel, t= he > assumption being that if you control a resolver that you can secure the > channel? > > 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 certai= n > 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/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 S= HOULD be > >> authenticated and secure. I am just against enforcing specific mea= ns > >> to achieve this. > >> > > >> > Ondrej > >> > -- > >> > Ond=C5=99ej Sur=C3=BD (He/Him) > >> > > >> > A gentle nudge is always appreciated if I take a little longer t= o > >> 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, COUL= D=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@sur= y.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-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 going to be >>>> mostly used on internal network= s > >> 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 wri= ting code > >> won=E2=80=99t prioritize it, and then it won=E2=80=99t work when i= t=E2=80=99s needed. > Whereas > >> if everything is as secure as our current standards facilitate, al= l > >> 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 it= s 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]= g > >> > > > ---------------------------------------------------- > > Alternatives: > > > ---------------------------------------------------- > > _______________________________________________ DNSOP mailing list = -- > > [email protected] To unsubscribe send an email to [email protected] > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -=3D IPv6 IoT consulting =3D- *I*LIKE*TRAINS* > > > > --00000000000010c7590657b8aece Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><br></div></div><br><div class=3D"gmail_quote gmail_quo= te_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 29, 2026 at= 12:34=E2=80=AFAM Michael Richardson <<a href=3D"mailto:mcr%2Bietf@sande= lman.ca">[email protected]</a>> wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex"><br> Tim Wicinski <<a href=3D"mailto:[email protected]" target=3D"_blank">tj= [email protected]</a>> wrote:<br> =C2=A0 =C2=A0 > But I SHOULD NOT be allowed to<br> =C2=A0 =C2=A0 > synchronize unsigned DNS records from resolvers not unde= r my locus of<br> =C2=A0 =C2=A0 > control.<br> <br> Is it:<br> 1. that your cache should refuse to accept to synchronize over an insecure = channel?<br> 2. that the other resolver should refuse to send synchronization data over = an<br> =C2=A0 =C2=A0insecure channel?<br></blockquote><div><br></div><div class=3D= "gmail_default" style=3D"font-family:monospace">Sorry I was agreeing that i= f you are=C2=A0synchronizing DNS records=C2=A0across multiple providers, et= c, those records should=C2=A0be DNSSEC signed records only.=C2=A0</div><div= class=3D"gmail_default" style=3D"font-family:monospace">How the=C2=A0resol= vers communicate is a decision they can make.=C2=A0</div><div class=3D"gmai= l_default" style=3D"font-family:monospace">I was suggesting that if I contr= ol all the resolvers, I should be OK with=C2=A0synchronizing DNS records no= t signed by DNSSEC.=C2=A0</div><div class=3D"gmail_default" style=3D"font-f= amily:monospace"><br></div><div class=3D"gmail_default" style=3D"font-famil= y:monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:mo= nospace"><br></div><div class=3D"gmail_default" style=3D"font-family:monosp= ace">tim</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><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> It seems that we are conflating "locus of control" with secure ch= annel, the<br> assumption being that if you control a resolver that you can secure the cha= nnel?<br> <br> I can see lots of debug situations where it would be useful to yank the<br> current cache over a channel for later debugging.=C2=A0 =C2=A0How that'= s secured seems<br> a local concern; I can well see IP/v6 acceptlists (and ::1) being considere= d<br> secure.<br> <br> So, I think it's really (1), not (2)?<br> <br> (I can *also* see situations where I might want to load a specific cache<br= > contents into a resolver in order to replicate how it behaves when certain<= br> conditions occur.=C2=A0 Debug.=C2=A0 Compile. Restart.=C2=A0 Up-arrow Retur= n)<br> <br> =C2=A0 =C2=A0 >> I agree entirely.<br> =C2=A0 =C2=A0 >><br> =C2=A0 =C2=A0 >> We are dealing with Key-Value paired parameters, rig= ht?<br> =C2=A0 =C2=A0 >><br> =C2=A0 =C2=A0 >> Perhaps an unspecified configuration (where the admi= nistrator has not<br> =C2=A0 =C2=A0 >> set key and value) must be declared by the RFC stand= ard by<br> =C2=A0 =C2=A0 >> default. This would leave administrators the option = to upgrade/replace<br> =C2=A0 =C2=A0 >> (should/may) choose to override each security parame= ter (key-value<br> =C2=A0 =C2=A0 >> pair), selecting from the approved list of values.<b= r> =C2=A0 =C2=A0 >><br> =C2=A0 =C2=A0 >> > 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> =C2=A0 =C2=A0 >> ><br> =C2=A0 =C2=A0 >> > =EF=BB=BFAbsolutely, the draft should say that = the backchannel SHOULD be<br> =C2=A0 =C2=A0 >> authenticated and secure. I am just against enforcin= g specific means<br> =C2=A0 =C2=A0 >> to achieve this.<br> =C2=A0 =C2=A0 >> ><br> =C2=A0 =C2=A0 >> > Ondrej<br> =C2=A0 =C2=A0 >> > --<br> =C2=A0 =C2=A0 >> > Ond=C5=99ej Sur=C3=BD (He/Him)<br> =C2=A0 =C2=A0 >> ><br> =C2=A0 =C2=A0 >> > A gentle nudge is always appreciated if I take = a little longer to<br> =C2=A0 =C2=A0 >> reply.<br> =C2=A0 =C2=A0 >> ><br> =C2=A0 =C2=A0 >> >> On 28. 7. 2026, at 12:38, Simon Jackson <= ;simon=3D<br> =C2=A0 =C2=A0 >> <a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a>> wrote:<br> =C2=A0 =C2=A0 >> >><br> =C2=A0 =C2=A0 >> >> =EF=BB=BFPerhaps clear use of the verbs MUS= T, SHOULD, MAY, COULD=E2=80=A6=C2=A0 >> Simon<br> =C2=A0 =C2=A0 >> >><br> =C2=A0 =C2=A0 >> >>>> On 28 Jul 2026, at 10:19, Bill Wood= cock <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</= a>> wrote:<br> =C2=A0 =C2=A0 >> >>><br> =C2=A0 =C2=A0 >> >>> =EF=BB=BF<br> =C2=A0 =C2=A0 >> >>><br> =C2=A0 =C2=A0 >> >>>>> 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> =C2=A0 =C2=A0 >> >>>>><br> =C2=A0 =C2=A0 >> >>>>>> On 27. 7. 2026, at 07:54, B= ill Woodcock <<a href=3D"mailto:[email protected]" target=3D"_blank">woody@p= ch.net</a>> wrote:<br> =C2=A0 =C2=A0 >> >>>>><br> =C2=A0 =C2=A0 >> >>>>><br> =C2=A0 =C2=A0 >> >>>>><br> =C2=A0 =C2=A0 >> >>>>>>> On Jul 20, 2026, at 17:= 55, Stephane Bortzmeyer <bortzmeyer=3D<br> =C2=A0 =C2=A0 >> <a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>> wrote:<br> =C2=A0 =C2=A0 >> >>>>>>><br> =C2=A0 =C2=A0 >> <a href=3D"https://datatracker.ietf.org/doc/draft-bo= rtzmeyer-dnsop-poisonlicious/" rel=3D"noreferrer" target=3D"_blank">https:/= /datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poisonlicious/</a><br> =C2=A0 =C2=A0 >> >>>>>><br> =C2=A0 =C2=A0 >> >>>>>> I strongly support the effo= rt, but would prefer DoT to be<br> =C2=A0 =C2=A0 >> mandatory, and DANE authentication to be preferred o= ver TSIG, when<br> =C2=A0 =C2=A0 >> available.<br> =C2=A0 =C2=A0 >> >>>><br> =C2=A0 =C2=A0 >> >>>> I strongly believe the security mec= hanism should be a matter of<br> =C2=A0 =C2=A0 >> local policy >>>> (and implementation de= faults) rather than something<br> =C2=A0 =C2=A0 >> enforced by the Internet >>>> Standard.<= br> =C2=A0 =C2=A0 >> >>>><br> =C2=A0 =C2=A0 >> >>>> So far, the DNS does not even enfor= ce a secure transport and/or<br> =C2=A0 =C2=A0 >> authentication >>>> for XFRs, so enforci= ng DoT/DANE/whatever for<br> =C2=A0 =C2=A0 >> something that is going to be >>>> mostl= y used on internal networks<br> =C2=A0 =C2=A0 >> feels over the top.<br> =C2=A0 =C2=A0 >> >>><br> =C2=A0 =C2=A0 >> >>> Sorry, I should have said DoQ/DoT; forc= e of habit.<br> =C2=A0 =C2=A0 >> >>><br> =C2=A0 =C2=A0 >> >>> I hear you, but I think that as long as= we make security optional,<br> =C2=A0 =C2=A0 >> a lot of people won=E2=80=99t bother, and then a lot= of people writing code<br> =C2=A0 =C2=A0 >> won=E2=80=99t prioritize it, and then it won=E2=80= =99t work when it=E2=80=99s needed.=C2=A0 Whereas<br> =C2=A0 =C2=A0 >> if everything is as secure as our current standards = facilitate, all<br> =C2=A0 =C2=A0 >> the time, we only have a single build target and tes= t case and the<br> =C2=A0 =C2=A0 >> most-sensitive traffic doesn=E2=80=99t have a target= painted on its back.<br> =C2=A0 =C2=A0 >> >>><br> =C2=A0 =C2=A0 >> >>> Why should HTTP be secure-by-default, b= ut DNS not?<br> =C2=A0 =C2=A0 >> >>><br> =C2=A0 =C2=A0 >> >>> -Bill<br> =C2=A0 =C2=A0 >> >>><br> =C2=A0 =C2=A0 >> >>> _______________________________________= ________ >>> DNSOP mailing<br> =C2=A0 =C2=A0 >> list -- <a href=3D"mailto:[email protected]" target=3D"= _blank">[email protected]</a> >>> To unsubscribe send an email to<br> =C2=A0 =C2=A0 >> <a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a> >>> <signature.asc><br> =C2=A0 =C2=A0 >> ><br> =C2=A0 =C2=A0 >><br> =C2=A0 =C2=A0 >> _______________________________________________ DNSO= P mailing list --<br> =C2=A0 =C2=A0 >> <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a> To unsubscribe send an email to <a href=3D"mailto:dnsop-= [email protected]" target=3D"_blank">[email protected]</a><br> =C2=A0 =C2=A0 >><br> <br> =C2=A0 =C2=A0 > ----------------------------------------------------<br> =C2=A0 =C2=A0 > Alternatives:<br> <br> =C2=A0 =C2=A0 > ----------------------------------------------------<br> =C2=A0 =C2=A0 > _______________________________________________ DNSOP ma= iling list --<br> =C2=A0 =C2=A0 > <a href=3D"mailto:[email protected]" target=3D"_blank">dnso= [email protected]</a> To unsubscribe send an email to <a href=3D"mailto:dnsop-leav= [email protected]" target=3D"_blank">[email protected]</a><br> <br> --<br> Michael Richardson <<a href=3D"mailto:mcr%[email protected]" target=3D= "_blank">[email protected]</a>>, Sandelman Software Works<br> =C2=A0-=3D IPv6 IoT consulting =3D-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *I*LIKE*TRAINS*<br> <br> <br> <br> </blockquote></div></div> --00000000000010c7590657b8aece-- --===============3153857087550230614== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============3153857087550230614==--