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 AM Tim Wicinski <[email protected]> wrote: > 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] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
