[dmarc-ietf] Re: Compatibility of "np" tag with RFC 9824 (Compact Denial of Existence in DNSSEC)

[Matteo Contrini <[e-mail]>]

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