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]
