On Thu, Feb 1, 2024 at 4:49 AM Peter Thomassen <pe...@desec.io> wrote:
> > > On 2/1/24 13:34, Edward Lewis wrote: > > The proper response will depend on the reason - more accurately the > presumed (lacking any out-of-band signals) reason - why the record is > absent. > > Barring any other information, the proper response should IMHO not depend > on the presumed reason, but assume the worst case. Anything else would > break expected security guarantees. > > Agreed, I don't think that the protocol should prescribe what to do in case of "operational error". Differentiating an "operational error" from an actual malicious interference is very likely going to be a slippery slope. That being said, I think it will be useful for adoption that resolvers provide a feature to use DELEG and fallback to NS when things are not correct. This is not something that is to be part of the protocol though. What I see could be useful is if we could signal something alike the qualifier in SPF [0]. This way an operator could onboard their zone into DELEG in "testing mode", allowing them to enable DELEG with the comfort of falling back to NS, build confidence and flip the switch. This could have the side effect of ever having DELEG delegations in "testing mode" though. [0] https://www.spf-record.com/syntax Manu > > From observations of the deployment of DNSSEC, [...] > > It’s very important that a secured protocol be able to thwart or limit > damage due to malicious behavior, but it also needs to tolerate benign > operational mistakes. If mistakes are frequent and addressed by dropping > the guard, then the security system is a wasted in investment. > > That latter sentence seems right to me, but it doesn't follow that the > protocol needs to tolerate "benign operational mistakes". > > Another approach would be to accompany protocol deployment with a suitable > set of automation tools, so that the chance of operational mistakes goes > down. That would be my main take-away from DNSSEC observations. > > In other words, perhaps we should consider a protocol incomplete if the > spec doesn't easily accommodate automation and deployment without it would > yield significant operational risk. > > Let's try to include automation aspects from the beginning. > > Peter > > -- > https://desec.io/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
