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 <[email protected]>
To: [email protected]
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 -- [email protected]
To unsubscribe send an email to [email protected]
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
