DMARC新NP标签在DNSSEC环境下可能失效

背景

2026年5月，IETF发布了更新版的DMARC规范（RFC 9989），其中引入了一个新的DMARC记录标签 np，用于指定当发件人域是发布DMARC记录的域的一个不存在子域时，接收方应应用的策略。该标签的初衷是帮助组织在不使用子域上阻断恶意邮件，同时保持其他子域的策略较为宽松。

然而，作者发现RFC 9989中对“不存在域”的定义与另一项近期规范——RFC 9824（称为“DNSSEC中的紧凑拒绝存在”）存在冲突。这导致 np 标签并非总能按预期工作。尽管DNSSEC的使用尚未普及，但该问题影响所有使用DNSSEC的域，包括Cloudflare、NS1、AWS Route 53和Azure等主流DNS提供商。作者已向负责DMARC的IETF工作组报告了该问题，工作组承认了问题，但未达成任何解决方案。

核心内容

新的 np 标签

在DMARC记录中，np 标签按如下方式出现：

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

• p 标签：适用于发布记录的域本身。
• sp 标签：适用于不发布自己DMARC记录的现有子域。
• np 标签：适用于不存在的子域（即该子域名在DNS中不存在）。

通过为不存在的子域设置更严格的策略（如 reject），可以阻止攻击者利用这些未使用的子域发送恶意邮件。

DNS中的非存在子域

DMARC RFC对“非存在域”的定义与RFC 8020一致：如果对域名查询的响应码是 NXDOMAIN，则该域名及其任何可能的子域都不存在。这是DNS中的常见概念。

示例：

~ ❯ dig non-existent-subdomain.rai.it +noall +comments +answer
;; status: NXDOMAIN

这表明 non-existent-subdomain.rai.it 及其所有子域都不存在。

与之对比的是域存在但特定记录类型不存在的情况，此时DNS服务器返回 NOERROR 并附空应答部分（即 NODATA）。例如：

~ ❯ dig news.rai.it MX +noall +comments +answer
;; status: NOERROR

这表明 news.rai.it 域存在（有其它记录），只是没有MX记录。

值得注意的是，之前的DMARC实验性扩展（RFC 9091）对“非存在子域”的定义更宽泛，要求对A、AAAA、MX记录都返回 NXDOMAIN 或 NODATA。但该定义在纳入RFC 9989时被修改为严格遵循RFC 8020的 NXDOMAIN 定义。

DNSSEC中的否定存在

DNSSEC通过添加加密签名来保证DNS应答的真实性。查询时，应答中会包含 RRSIG 记录。对于不存在的域名，标准DNS返回空应答，这无法签名。DNSSEC因此引入了 NSEC 记录类型：它标识按规范DNS顺序排列的、紧挨在被查询域名之前和之后的两个现有域名，从而证明被查询域名不存在于它们之间。NSEC 记录本身被签名，保证完整性。此时DNS响应码仍然是 NXDOMAIN。

现在许多DNS服务器使用 NSEC3（一种变体），它使用哈希名称而不是原始名称，以防止攻击者遍历DNS区域枚举所有域名。为了证明不存在，通常需要多个 NSEC3 记录（最坏情况可达8条记录），这可能接近UDP数据包大小上限，导致截断并回退到TCP。

示例（使用dig查询不存在的域名，显示8条权威记录）：

~ ❯ dig non-existent.rcodezero.at +dnssec +noall +comments +authority
;; status: NXDOMAIN
;; AUTHORITY SECTION: (包含SOA、RRSIG及三条NSEC3记录及其RRSIG)

冲突所在

RFC 9989将“非存在子域”定义为必须收到 NXDOMAIN 响应。然而，RFC 9824（DNSSEC中的紧凑拒绝存在）允许一种更高效的否定存在证明方式，这种方式在某些情况下可能不返回 NXDOMAIN，而是返回 NOERROR 并附上证明不存在的 NSEC3 记录。这导致DMARC接收方无法判断该子域是否真的不存在，从而无法正确应用 np 标签——它可能错误地认为子域存在（因为没有收到 NXDOMAIN），进而应用 sp 标签而不是 np 标签。

作者指出，这一冲突影响所有启用了DNSSEC的域，尤其在使用主流DNS提供商时，问题更易暴露。问题已报告给IETF工作组，但至今未达成解决方案。

关键要点

• np 标签用途：针对不存在的子域设置DMARC策略（如 reject），以增强邮件安全。
• 定义冲突：RFC 9989要求不存在子域返回 NXDOMAIN，但RFC 9824的紧凑否定存在可能返回 NOERROR 并附NSEC3记录，导致DMARC接收方误判。
• 影响范围：所有使用DNSSEC的域（特别是Cloudflare、NS1、AWS Route 53、Azure等）都可能受影响；虽然DNSSEC普及率不高，但涉及的用户群不可忽视。
• 现状：IETF工作组承认了问题，但未达成任何修复方案，当前规范状态存在不兼容性。
• 历史演变：之前的实验性扩展（RFC 9091）使用了更宽泛的定义（包含NODATA），但标准版反而收窄了定义，加剧了与DNSSEC的冲突。

意义与影响

此冲突揭示了标准制定中不同工作组（DMARC与DNSSEC）之间的协调缺失，可能导致实际部署中的安全漏洞。对于已经或计划部署 np 标签的邮件域，若同时启用DNSSEC，则 np 标签可能无法按预期生效，攻击者可能利用这一不确定性绕过策略。域名所有者和邮件服务商需要意识到这一潜在风险，并考虑在DNSSEC环境下临时回退到更保守的定义（例如沿用RFC 9091的宽泛定义）或等待IETF的官方解决方案。此外，该问题也提醒标准化社区：跨协议互操作性的验证应在规范发布前充分进行，避免后期才发现根本性冲突。对于大规模邮件基础设施（如大型邮件提供商），此问题可能导致误判邮件来源，影响送达率和安全性。