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?
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*
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
