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

[Matteo Contrini <[e-mail]>]

Thanks for the answer, Todd.

On 09/06/2026 17:17, Todd Herr wrote:
> 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.

We can agree on that, but the "np" tag was introduced nonetheless, so I 
suppose it was deemed realistic that a mail receiver reaches the point 
where the "np" policy is evaluated even with those premises.

> 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"
True, but RFC 9824 also provides a way to distinguish between "no data 
for this RR type" and a non-existent domain name: 
https://datatracker.ietf.org/doc/html/rfc9824#name-distinguishing-nonexistent-

Section 6 also states that:

 > [...] tools that rely on accurately determining nonexistent names 
will need to infer them from the presence of the NXNAME RR type in the 
Type Bit Maps field of the NSEC record in NODATA responses from these 
servers.

> For the hypothetical message with the RFC5322.From domain 
> subdomain.example.com <http://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
>     <http://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 <http://example.com> 
> has published a DMARC policy record (or a subdomain somewhere between 
> subdomain.example.com <http://subdomain.example.com> and example.com 
> <http://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.

Isn't that precisely the problem here? A domain owner has the 
expectation that "np" would be used in this case, not "p" or "sp". 
NXDOMAIN and NSEC NXNAME mean the exact same thing, i.e. that the domain 
is non-existent, so "np" should apply in both cases.

If the DMARC spec, and therefore implementors, don't take this into 
account, isn't this an interoperability issue, especially now that RFC 
9824 is a Proposed Standard with already significant real-world usage 
(see Cloudflare, NS1, etc.)?

I know it's way too late to raise this, but I'm wondering if this can 
either fit as an erratum or if we can agree it's something the WG should 
take into consideration in the next DMARC revision (if any, and likely 
in a decade :-)).

>
> -- 
> Todd

--
Matteo