> 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.
One thing that is sub-optimal is the current design is how alias-mode works. When alias-mode is used and the target of the alias cannot be resolved then the alias-mode DELEG provides zero information. So one path forward is to have extra information in alias-mode. For example whether fallback to NS/DS is encouraged by the operator of the zone. If DELEG is mainly used to signal that a secure transport, such as DoT, DoH, or DoQ, is available then falling back to NS/DS might be preferred (by the zone operator) over failure. On the other hand, if there is no DS record, but the service mode DELEG does have the equivalent of DS, then fallback to just NS is not desired. So maybe alias-mode DELEG should be allowed to have its own set of key/value pairs focussed on fallback issues. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
