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? - Deji on the Go On Mon, Jun 15, 2026 at 8:53 PM 左鹏 <[email protected]> wrote: > I agree that the deployment reality is an important consideration.If many > resolvers do not perform NXDOMAIN restoration, applications that need to > determine non-existence may indeed need to examine NXNAME directly. > > > > But there is also a deployment-cost consideration. The number of > applications is likely much larger than the number of resolver. If support > for NXNAME is added primarily at the application layer, the overall > deployment cost may be much higher. It may be worth considering whether to > optimize for the cost of changing resolvers, or for the cost of changing > applications. > > > > I think the key issue is how to convey the semantics of non-exist domain to > resolvers. Different mechanisms may be used to represent or validate > non-existence information. RFC 9824 uses compact denial proofs, while other > approaches have explored compressed representations of zone membership > information, including Bloom-filter-based techniques. > > > > > -----原始邮件----- > *发件人:* "Shumon Huque" <[email protected]> > *发送时间:* 2026-06-13 20:32:35 (星期六) > *收件人:* "John R Levine" <[email protected]> > *抄送:* [email protected] > *主题:* [DNSOP] Re: How black are black lies, really? > > On Fri, Jun 12, 2026 at 11:42 PM John R Levine <[email protected]> wrote: > >> RFC 9824 on Compact Denial of Existence in DNSSEC says how to generate >> miniallly covering DNSSEC signatures on the fly which works great so long >> as the name exists. If it doesn't, we invented the NXNAME psedudo-RRtype >> as a flag to say this response is really an NXDOMAIN. Section 5 >> describes >> that and encourages resolvers to return a real NXDOMAIN. >> >> Over in another working group I got an proposed errata for RFC9989 saying >> that where it says applications check for NXDOMAIN, they also have to >> check for NXNAME, for resolvers that don't recover the NXDOMAIN. I >> rejected it but he insists claiming that (approximately) the resolvers >> he's seen don't actually recover NXDOMAIN. >> > > Yes, this is largely true today. The NXDOMAIN restoration feature isn't > implemented by any mainstream resolver that I'm aware of. From private > communication, I know that a couple of them plan to implement it in the > future, or are contemplating it. > > It seems to me that's a bug in the resolver, that's the whole point of the >> CO flag and NXNAME. The alternative is to file a similar erratum on >> every >> RFC that mentions NXDOMAIN. What do you think? >> > > That depends on your point of view. Remember, that there was significant > controversy about this mechanism when it was first deployed in the field > due > to the unilateral disappearance of the NXDOMAIN signal. The IETF work > recovered that signal in an alternative way with the NXNAME pseudo type, > which can be implemented entirely on the side of the authoritative servers > that have implemented RFC9824. Restoring the NXDOMAIN type code > value into the actual response code field requires the additional active > cooperation of the resolver (to set the CO EDNS header flag and perform > attendant processing). And some resolver operators were adamant that they > were not going to make any changes to their code to accommodate 9824, so > this part of the spec had to remain optional. > > As a practical matter, that means (at least today) if applications need to > conclusively determine non-existence of a domain name at zones that > implement Compact Denial of Existence, they will need to examine the > NXNAME signal. (We have several specialized inhouse applications that > already do this). > > Shumon. > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
