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 >> <[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 >>>>>>> <[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]
