DMARC新NP标签与DNSSEC的不兼容性：技术解析与影响评估

DMARC新标准中的NP标签因DNSSEC的“不存在证明”机制冲突，导致策略执行失败。

背景：DMARC的演进与NP标签的引入

2026年5月，IETF发布了DMARC规范的最新版本（RFC 9989），其中引入了名为np的新标签。这个标签的全称是“non-existent subdomain policy”（不存在的子域策略）。在DMARC记录中，它看起来像这样：

v=DMARC1; p=none; sp=quarantine; np=reject;

• p标签：应用于发布DMARC记录的主域的策略。
• sp标签：应用于存在但未发布自己DMARC记录的子域的策略。
• np标签：应用于不存在的子域的策略。

这种区分非常实用：你可以对不存在的子域（即恶意攻击者可能利用的域名）设置最严格的策略（如reject），同时对自己真正使用的子域保持较宽松的策略（如none或quarantine），从而在安全性和灵活性之间取得平衡。

DNS中“不存在域名”的定义

RFC 9989对“不存在的域名”的定义引用了RFC 8020：

对于DMARC目的而言，不存在的域名与该术语在RFC 8020中的含义一致。即，如果对某个域名的查询返回的响应码是NXDOMAIN，则该域名及其所有可能的子域名都不存在。

这是DNS中最直观的定义。当DNS服务器返回NXDOMAIN状态码时，意味着被查询的域名以及它的所有子域名都不存在——没有任何DNS记录与之关联。

示例1：真正的NXDOMAIN
bash
~ ❯ dig non-existent-subdomain.rai.it +noall +comments +answer
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17031
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

示例2：NODATA（域名存在，但无特定记录类型）
bash
~ ❯ dig news.rai.it MX +noall +comments +answer
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37891
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

这里的关键区别是：

• NXDOMAIN：域名本身不存在，所有子域名也不存在。
• NOERROR + 空回答（NODATA）：域名存在，但请求的特定记录类型（如MX）不存在。

值得注意的是，DMARC的早期实验性扩展（RFC 9091）曾采用更宽泛的定义：不存在的域名是指对A、AAAA和MX记录查询都返回NXDOMAIN或NODATA的域名。但RFC 9989最终收窄了定义，严格遵循RFC 8020。

DNSSEC的“否认存在”机制

DNSSEC（DNS Security Extensions）通过为DNS记录添加加密签名，让解析器能够验证应答的真实性和完整性。但在处理“域名不存在”的场景时，标准DNS的NXDOMAIN响应（空回答区）带来了一个根本性问题：空回答区没有任何记录，所以没有任何东西可以签名。

DNSSEC的解决方案是引入NSEC（Next Secure）记录类型。其核心思想是：

不直接对“不存在的域名”签名，而是找出DNS规范排序中紧邻该域名的前一个存在域名和后一个存在域名，并签名证明“在它们之间没有其他域名存在”。

NSEC的工作原理示例：
假设一个DNS区域只包含两个域名：

• a.example.com
• z.example.com

当我们查询f.example.com（不存在）时，DNSSEC启用的解析器会收到：

a.example.com 300 IN NSEC z.example.com. A RRSIG NSEC

这条NSEC记录的含义是：

• a.example.com是存在的。
• 在DNS规范排序中，a.example.com的下一个域名是z.example.com。
• 因此，在a.example.com和z.example.com之间没有其他域名存在，f.example.com自然也不存在。

实际场景更复杂：

1. 还需要第二条NSEC记录来证明没有通配符（wildcard）记录会覆盖f.example.com。
2. 如果域名存在但缺少特定记录类型，只需一条NSEC记录列出所有存在的记录类型即可。

NSEC3：更复杂的变体

为了防御“区域遍历”（zone walking）攻击——攻击者可以通过NSEC记录枚举区域内所有域名——现代DNS服务器多采用NSEC3。NSEC3对域名进行哈希处理，使得无法直接从响应中恢复原始域名。

但NSEC3引入了额外的复杂性：

• 需要第三条NSEC3记录来证明“最近封闭器”（closest encloser）存在。
• 在最坏情况下，一个NXDOMAIN响应可能需要多达8条记录：
  • 1条SOA记录
  • 1条SOA RRSIG签名
  • 3条NSEC3记录
  • 3条NSEC3 RRSIG签名

这8条记录的总大小可能接近DNS UDP包的大小限制（通常为1232字节），导致响应被截断（truncated），迫使解析器回退到TCP连接，增加延迟和复杂性。

实际NSEC3响应示例：
bash
~ ❯ dig non-existent.rcodezero.at +dnssec +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28077
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

冲突的核心：NP标签为何失效？

问题在于DMARC的np标签依赖的是标准DNS语义——即NXDOMAIN响应码来表示域名不存在。但在DNSSEC启用的环境中，DNSSEC验证器（validator）并不直接输出NXDOMAIN。

DNSSEC解析器的工作流程是：

1. 向权威服务器发起查询。
2. 权威服务器返回NSEC/NSEC3记录集（伴随NXDOMAIN状态码）。
3. 解析器验证这些记录的签名。
4. 验证通过后，解析器才返回NXDOMAIN给上层应用。

但这里存在一个关键问题：DMARC检查器（通常运行在邮件接收服务器上）可能不执行DNSSEC验证，或者它依赖的DNS解析器没有正确传递DNSSEC验证结果。更严重的是，某些DNSSEC实现（如Cloudflare、NS1、AWS Route 53、Azure）在处理不存在的子域名时，可能会因为NSEC3记录的复杂性而返回不完整或格式异常的NXDOMAIN响应，导致DMARC检查器无法正确识别“域名不存在”的状态。

具体故障模式：

• 情况A：DNSSEC解析器返回NXDOMAIN，但附带大量NSEC3记录。DMARC检查器可能因为响应过大（超过UDP限制）而只处理了截断后的数据，误判为“域名存在但无记录”（NODATA）。
• 情况B：某些权威服务器在NSEC3链不完整时，返回的是SERVFAIL或REFUSED，而不是NXDOMAIN。
• 情况C：DNSSEC验证失败时，解析器可能返回SERVFAIL，DMARC检查器无法确定域名是否存在，可能采取默认的宽松策略（p=none），而不是np=reject。

影响评估与现状

虽然DNSSEC的部署率仍然不高（全球约30-40%的顶级域名启用了DNSSEC），但所有使用DNSSEC的域名都可能受到影响，尤其是那些依赖主流DNS提供商（Cloudflare、NS1、AWS Route 53、Azure）的域名。

作者已向IETF的DMARC工作组报告了此问题。工作组承认了问题的存在，但尚未达成任何解决方案。这意味着：

• 短期内，如果你同时使用DNSSEC和DMARC np标签，你的np=reject策略可能无法对不存在的子域生效。
• 恶意邮件发送者可以利用这个漏洞，通过伪造不存在的子域来绕过DMARC检查。

建议与缓解措施

1. 监控DNSSEC解析器行为：确保你的邮件服务器使用的DNS解析器能够正确、完整地传递DNSSEC验证结果，特别是NXDOMAIN状态。
2. 考虑暂时不使用np标签：如果你的域名启用了DNSSEC，在问题解决前，可以依赖sp标签（针对存在的子域）来提供基本保护。
3. 保持DNS响应在UDP限制内：优化NSEC3参数（如减少哈希迭代次数、使用更短的哈希长度）以减小响应大小，避免UDP截断。
4. 关注IETF进展：跟踪DMARC和DNSSEC工作组的更新，等待官方解决方案（可能包括修改np标签的定义，或引入新的DNSSEC感知的查询方式）。

总结

DMARC的np标签本意是填补安全空白，让域主能够对不存在的子域实施最严格的邮件策略。然而，它与DNSSEC的“否认存在”机制（NSEC/NSEC3）存在根本性的语义冲突：DNSSEC用复杂的签名链证明不存在，而DMARC期望一个简单的NXDOMAIN状态码。这种不兼容性导致np标签在DNSSEC启用的环境中可能完全失效。

对于已经部署了DNSSEC的组织，这个问题不容忽视——它直接削弱了DMARC提供的反钓鱼保护。随着DNSSEC部署率的逐渐上升，这种冲突的影响只会越来越大。

---

原文链接：https://dmarcwise.io/blog/dmarc-np-incompatibility-with-dnssec