[DNSOP] Re: How black are black lies, really?

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]