Cloudflare 的 1.1.1.1 公共解析器现在能够使用 NIST 后量子算法 ML-DSA-44 验证 DNSSEC 签名。这不只是替换一个密码学算法：单个签名达到 2,420 字节，已经超过许多 DNS 服务为避免 IP 分片而采用的 1,232 字节 UDP 响应预算。
真正困难的部分，是让这些大签名穿过现实网络，并且在失败时不把“兼容性回退”变成绕过验证的降级通道。
变化发生在验证链，而不只是算法列表
DNSSEC 解析器需要从根区开始，沿着 DS、DNSKEY 和 RRSIG 构成的信任链验证响应。支持 ML-DSA-44，意味着验证器能够识别相应算法，并在授权链要求它时检查后量子签名。
这里要区分两个概念：
- 解析器支持 ML-DSA-44，不代表所有通过 1.1.1.1 查询的域名都已经使用它签名。
- 验证成功也不等于响应只包含一个签名。密钥轮换、算法迁移和不同记录集都可能让同一响应携带多个 DNSKEY 或 RRSIG。
因此，2,420 字节并不是整个 DNS 包的上限，而只是单个 ML-DSA-44 签名带来的主要负载。算上 DNS 头、名称、记录字段、密钥以及其他签名，完整响应还会更大。
UDP 不再是理所当然的单包运输
传统 DNS 优先使用 UDP。EDNS(0) 允许客户端声明更大的接收缓冲区，但“允许发送”不代表中间网络一定能可靠传递。大包可能遭遇 IP 分片、分片丢失、防火墙过滤，或者被设备按旧的 DNS 尺寸假设直接丢弃。
实践中常见的策略是把 UDP 载荷控制在约 1,232 字节，以适应 IPv6 最小 MTU，并在响应被截断时通过 TC 标志引导客户端改用 TCP。面对 2,420 字节的签名，TCP 回退会从偶发路径变成必须认真容量规划的路径。
运维侧需要关注的不只是平均查询延迟，还包括：
- UDP 截断率与 TCP 重试率；
- TCP 建连、并发连接和文件描述符压力；
- 大型 DNSKEY、DS、RRSIG 响应的超时比例；
- 特定运营商、地区或网络设备导致的黑洞现象；
- 缓存命中率能否抵消更昂贵的验证和传输成本。
可以这样检查自己的解析链路
下面的脚本要求系统已安装 dig。Ubuntu/Debian 可安装 dnsutils，macOS 可通过 Homebrew 安装 bind。将参数替换成你的测试域名；普通域名可以验证 UDP/TCP 行为，但只有实际部署了 ML-DSA-44 的测试区才能证明后量子验证路径。
#!/usr/bin/env bash
set -euo pipefail
DOMAIN="${1:-cloudflare.com}"
RESOLVER="${RESOLVER:-1.1.1.1}"
echo "== UDP with a 1232-byte EDNS budget =="
dig "@${RESOLVER}" "${DOMAIN}" DNSKEY \
+dnssec +bufsize=1232 +comments +stats
echo
echo "== Forced TCP =="
dig "@${RESOLVER}" "${DOMAIN}" DNSKEY \
+dnssec +tcp +comments +stats
echo
echo "Check status, flags, MSG SIZE, and whether the UDP response contains tc."
运行方式：
chmod +x check-dnssec.sh
./check-dnssec.sh example.com
重点观察输出中的 status、flags 和 MSG SIZE：
ad表示递归解析器认为响应通过了 DNSSEC 验证；它不是客户端自行验证的证明。tc表示 UDP 响应被截断，客户端应通过 TCP 重试。SERVFAIL可能来自签名无效、信任链问题或网络传输失败，需要结合解析器日志和 TCP 查询继续定位。
如果要测试应用程序而不是命令行工具，还要确认所用 DNS 库确实处理了截断和 TCP 重试。不要假设操作系统、本地转发器、容器 DNS 代理和上游递归解析器拥有完全相同的行为。
降级必须是密码学决策，而不是超时后的猜测
算法迁移期间通常需要兼容旧验证器，但兼容不能演变成“新算法验证失败，就把域名当成未签名”。攻击者可能主动丢弃大响应、阻断 TCP，或利用中间设备制造超时。如果系统把网络失败解释为可以跳过 DNSSEC，后量子保护就会被降级路径抵消。
更稳妥的原则是：是否必须验证，应由已经认证的父区 DS 和 DNSSEC 状态决定。网络超时、未知算法、签名错误和真正的未签名委派应当是不同状态，并分别记录指标。只有协议明确允许的替代验证链才能作为回退，不能因为另一条链更小或更容易传输就自动信任它。
上线前的工程检查表
引入后量子 DNSSEC 时，可以按以下顺序推进：
- 先确认权威服务器、递归解析器、转发器和客户端库都能处理大型响应及 TCP 回退。
- 在受控测试区启用新算法，分别测试冷缓存、热缓存、UDP、TCP、IPv4 和 IPv6。
- 对
TC、TCP 查询、SERVFAIL、验证失败和响应尺寸建立分维度监控。 - 明确算法迁移期的信任规则，避免把未知算法或网络超时静默视为“不需要验证”。
- 做区域化灰度，特别关注老旧防火墙、企业 DNS 代理和存在 MTU 问题的网络。
ML-DSA-44 把 DNSSEC 带入后量子验证阶段，也把长期存在的大包、分片和 TCP 兼容问题推到了主路径上。算法支持只是起点；真正可用的部署，还需要传输、容量、可观测性和降级策略共同成立。