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-existdomain 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]
