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 PM Simon Jackson <simon= [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 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řej Surý <[email protected]> wrote: > > > > Absolutely, the draft should say that the backchannel SHOULD be > authenticated and secure. I am just against enforcing specific means to > achieve this. > > > > Ondrej > > -- > > Ondřej Surý (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= > [email protected]> wrote: > >> > >> Perhaps clear use of the verbs MUST, SHOULD, MAY, COULD… > >> Simon > >> > >>>> On 28 Jul 2026, at 10:19, Bill Woodcock <[email protected]> wrote: > >>> > >>> > >>> > >>>>> On Jul 28, 2026, at 14:38, Ondřej Surý <[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= > [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 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’t bother, and then a lot of people writing code won’t > prioritize it, and then it won’t work when it’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’t 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]
