[dmarc-ietf] [Technical Errata Reported] RFC9989 (8995)

[[e-mail]]

The following errata report has been submitted for RFC9989,
"Domain-Based Message Authentication, Reporting, and Conformance (DMARC)"

--------------------------------------
You may review the report below and at:
https://errata.rfc-editor.org/eid8995/

--------------------------------------
Type: Technical
Reported by: Johnathon Mihalop <[e-mail]>

Section Appendix A.4. says:

Original Text
-------------
If the response code received for a query for a domain name is NXDOMAIN, then the name and all the names under it do not exist.

Corrected Text
--------------
If the response received for a query for a domain name proves that the queried name does not exist, then the name and all names under it are considered non-existent for the purposes of this specification. This proof can be conveyed by an NXDOMAIN response, or by a DNSSEC-validated denial-of-existence response that otherwise indicates non-existence of the queried name, such as an RFC 9824 Compact Denial response containing the NXNAME type in the relevant NSEC bitmap.

Notes
-----
RFC 9824 (Compact Denial of Existence in DNSSEC) is a Proposed Standard that defines a way to reduce the size and signing cost of DNSSEC denial-of-existence responses. For a non-existent name, Compact Denial can return a NODATA-shaped response, i.e. RCODE=NOERROR with an empty Answer section, while signalling non-existence using the NXNAME RR type (TYPE128) in the NSEC/NSEC3 type bitmap.

RFC 9989 describes non-existent domains only in terms of NXDOMAIN. This is incomplete for DNSSEC-validated responses from zones using RFC 9824 Compact Denial. A receiver that only treats RCODE=NXDOMAIN as proof of non-existence may fail to recognize an RFC 9824 NXNAME denial proof and may therefore fail to apply the DMARC np= policy for a non-existent Author Domain.

Instructions:
-------------
This erratum is currently posted as "Reported". Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC9989 (draft-ietf-dmarc-dmarcbis)
--------------------------------------
Title               : Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
Publication Date    : May 2026
Author(s)           : T. Herr, Ed., J. Levine, Ed.
Category            : Proposed Standard
Source              : dmarc (art)
Stream              : IETF
Verifying Party     : IESG