[DNSOP] Re: How black are black lies, really?
Petr Špaček <[email protected]>
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
On 16. 06. 26 6:53, Ẹnitàn wrote: > I have one concern regarding the treatment of NXDOMAIN restoration. > > RFC 9824 correctly preserves proof of nonexistence, but it changes the > observable semantics from NXDOMAIN to NOERROR/NODATA unless restoration > is performed. Section 5.1 makes restoration optional, yet many > operational and security systems rely on NXDOMAIN itself as a signal > rather than on DNSSEC proof semantics. > > As written, deployments may become DNSSEC-equivalent while no longer > being operationally equivalent. > > Would it make sense to strengthen the recommendation around NXDOMAIN > restoration, perhaps making it a SHOULD rather than an optional > capability, in order to better preserve compatibility with existing > consumers of NXDOMAIN signals? I can see three ways to read the current situation: a) Maybe we have specs (do we?) which depends on NXDOMAIN in specific situations but they did not account for RFC 9824. Sounds like bug in these hypothetical specs because restoration is not mandatory in any way. Possible course of action: Fix outside of this group. b) RFC 9824 style RCODE restoration is not normative for resolvers and thus the specs from previous paragraph are correct. Consequently, implementations which depend on using RFC 9824 are not interoperable with specs from point (a). Possible course of action: Say RFC 9824 is a bad idea. c) Update RFC 9824 to make RCODE restoration mandatory and wait a decade or two to get it deployed. Keep in mind - even if we fix this in BIND today, there will be years long deployment lag, and that ignores the operational reality where we decided to postpone new feature releases to deal with LLM generated reports. I would not be surprised if other implementations had similar problem. Either way, this points to lack of running code and real-world experimentation. dnsop exactly how we like it - again? -- Petr Špaček _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]