On Wed, Jul 29, 2026 at 12:34 AM Michael Richardson <[email protected]> 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 insecure > channel? > 2. that the other resolver should refuse to send synchronization data over > 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, the > 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 certain > 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ř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] > >> > > > ---------------------------------------------------- > > Alternatives: > > > ---------------------------------------------------- > > _______________________________________________ DNSOP mailing list -- > > [email protected] To unsubscribe send an email to [email protected] > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
