What are bind plans about Section 5 of RFC 9824?

[Alessandro Vesely]

Hi,

I'm puzzled by RFC 9824's distortion of NXDOMAIN return code.  That RFC seems 
to provide ways to restore the response code; however, their "should" and 
"recommended" words are all spelled lowercase in Section 5.  In addition, the 
forwarded message below says BIND9 doesn't appear to be doing such restoration.

Any forecast on how this topic is going to evolve?

TIA
Ale


-------- Forwarded Message --------
Subject: [dmarc-ietf] Re: Compatibility of "np" tag with RFC 9824 (Compact 
Denial of Existence in DNSSEC)
Date: Thu, 11 Jun 2026 12:33:37 +0200
From: Matteo Contrini <matteo at dmarcwise.io>
To: dmarc at ietf.org

On 11/06/2026 10:57, John R. Levine wrote:
> Please see my response to your erratum.
>
> RFC 9824 section 5 explains how resolvers recover the correct NXDOMAIN 
> response so they don't break every application that expects NXDOMAIN 
> to work.  We debated this at great length while writing the RFC.
>
> R's,
> John 

Thanks for the answer, John. For the record, I'm not the author of that erratum.

I've read Section 5 of RC 9824 multiple times, let me try to rephrase what it 
says and provide my observations:

- For DNS queries that don't have the DO bit set ("DNSSEC answer OK"), it says 
that authoritative nameservers could simply return NXDOMAIN. It also says that 
this is unlikely to be useful since queries usually go to a recursive 
resolvers, and modern resolvers are all DNSSEC aware, so this doesn't apply. Fine.

- A recursive resolver that understands the NXNAME signal and receives a query 
from a client without the DO bit set can decide to replace the NOERROR response 
code with NXDOMAIN. This mechanism is however optional, and I see no indication 
that it's being applied in the real world so far.

I've checked 8.8.8.8 and 1.1.1.1, I've looked at the source code of BIND9, 
Unbound and PowerDNS and unless I missed something they don't appear to be 
doing this. In my experience, DNS libraries usually don't set the DO bit by 
default (nor does "dig"), so most implementations will likely fall in this 
category of queries and in the current state won't see NXDOMAIN.

- A resolver that receives a query with the DO bit set won't do any replacement 
and respond with NOERROR + NXNAME, if that's the case. The client will 
therefore need to read the NXNAME bit to infer non-existence. Is this correct 
or I'm reading it wrong? If so, RFC 9989 makes no mention of this and assumes 
you can just check for NXDOMAIN.

- According to Section 5.1 of RFC 9824 a resolver can also request an 
authoritative server to respond with NXDOMAIN even when compact NSEC is used, 
with the CO flag. At the moment, Cloudflare and NS1 authoritative servers don't 
appear to support this, while Bunny DNS does. For this to be useful, however, 
the CO flag needs to be set by both the resolver and the query client 
(otherwise the NXDOMAIN would be reverted to NOERROR). DNS libraries don't set 
this bit by default (nor does "dig"), so an implementation needs to be aware 
that they should set also the CO flag when they use the DO flag.

Did I get this right? If so, I still think that RFC 9989 is at least missing 
some guidance for developers:

- If an implementation doesn't set the DO bit, it currently receives a NODATA 
response with most (or all?) resolvers. Replacement of NOERROR with NXDOMAIN by 
resolvers is optional and isn't happening at the moment.

- If an implementation sets the DO bit, they need to be aware of RFC 9824 and 
read the NSEC NXNAME bit because no replacement is done by default. RFC 9989 
makes no mention of this possibility and assumes you can always read NXDOMAIN.

- If an implementation sets both the DO flag and the CO flag, most of the time 
it falls back to the previous point, currently. Hopefully this will improve, 
but support for the flag is optional.

Happy to be shown wrong!

--
Matteo


_______________________________________________
dmarc mailing list -- dmarc at ietf.org
To unsubscribe send an email to dmarc-leave at ietf.org