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

[Todd Herr <[e-mail]>]

On Tue, Jun 9, 2026 at 10:08 AM Matteo Contrini <matteo=
[e-mail]> wrote:

> Hi all,
>
> in RFC 9989, a domain is determined to be non-existent if the response
> code for the DNS query is NXDOMAIN. This definition is used in the "np"
> tag (non-existent subdomain policy).
>
> However, authoritative name servers doing DNSSEC online signing often
> use the so-called "NSEC Black Lies" method, now known as RFC 9824 -
> Compact Denial of Existence in DNSSEC, to authenticate non-existent
> domain responses. Instead of responding with NXDOMAIN and NSEC/NSEC3
> records, they respond with NODATA, an empty answer section, and a single
> NSEC record signaling the pseudo-record type NXNAME.
>
> A DMARC implementation following RFC 9989 would therefore never see
> NXDOMAIN and treat all domains using DNSSEC and Compact Denial of
> Existence as existent, even if they're not. The issue appears to be
> potentially significant since the NSEC Black Lies/Compact Denial of
> Existence method has been used extensively in commercial DNS providers,
> such as Cloudflare (since 2016), NS1 and Bunny DNS.
>
> My question is whether the new "np" tag is therefore to be considered
> incompatible with RFC 9824 - Compact Denial of Existence in DNSSEC, or
> if I missed something. I've looked at previous discussions in this
> mailing list but couldn't find anything relevant. I could only find
> that RFC 9091, which RFC 9989 obsoleted, had a broader non-existent
> definition which also included NODATA.
>
>
It is unknown, and perhaps unlikely, that an email message with an
RFC5322.From header domain that has neither an MX record nor an A or AAAA
record will even be considered for message acceptance, let alone DMARC
processing.

Appendix A.4 of RFC 9989 mentions this and touches on the NODATA response -
https://www.rfc-editor.org/rfc/rfc9989.html#appendix-A.4 - That section
reads, in part, "a "NODATA" response (rcode "NOERROR") means that the given
RR type queried for does not exist, but the domain name does." which seems
quite consistent with the first sentence of the Abstract of 9824 - "a
technique to generate a signed DNS response on demand for a nonexistent
name by claiming that the name exists but doesn't have any data for the
queried record type"

Worth noting too that a tag of "np=reject" does not mean "reject mail from
a non-existent subdomain"; it means "reject mail from a non-existent
subdomain if that message fails DMARC validation"

For the hypothetical message with the RFC5322.From domain
subdomain.example.com for which answers to the following queries are all
NODATA:

   - The domain's MX record
   - The domain's A or AAAA record
   - The TXT record _dmarc.subdomain.example.com (assuming it gets that far)

Assuming that such a message isn't outright rejected for there being no MX
or A (or AAAA) record, hen we must ask whether such a message could pass
DMARC validation checks or if the DMARC mechanism even applies.

The DMARC mechanism would apply if example.com has published a DMARC policy
record (or a subdomain somewhere between subdomain.example.com and
example.com, if the tree walk is in effect has published a DMARC policy
record).

If the DMARC mechanism applies, then standard DMARC validation can take
place, and if the message fails DMARC validation, then the governing DMARC
policy record would apply, with that record's p or sp tag (if it exists)
expressing the domain owner's handling preference.

If a message with an RFC5322.From domain with NODATA responses for its MX,
A, and DMARC policy records passes DMARC, it's up to the receiving site to
determine how to handle the message.

-- 
Todd