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.
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
