APNIC 解读 IETF 126 DNS 热点：解析器、后量子 DNSSEC 与乐观 DNS
2026 年 7 月底在维也纳举行的 IETF 126 会议上，DNS 相关工作组讨论了大量议题。APNIC 首席科学家 Geoff Huston 在会后撰文梳理了其中最值得关注的几个方向：递归解析器的真实查询行为、后量子 DNSSEC 的可行实验、乐观 DNS（Optimistic DNS）的争议，以及根区的本地化部署。对正在做域名解析、建站或网络运维的团队来说，这些讨论直接影响 DNS 架构与配置决策。
递归解析器：一次解析到底要查多少次
ISC 的 Ondřej Surý 展示了一个"冷缓存"实验：递归解析器从空缓存启动解析一个 IPv6 反向 PTR 记录，BIND 2.18 竟然发了 329 次查询。原因包括名字中的委派层级数量、带外（out-of-bailiwick）权威服务器名称、CNAME 链以及 DNSSEC 校验带来的额外查询。
更关键的是"传递信任"问题：解析 www.example.com 表面上是 4 次查询，但实际上根区 13 台根服务器、.com 的 13 台服务器以及根服务器所在的 .net 域都要被隐式信任；而 glue 记录在历史上曾被用于 DNS 缓存投毒，现在解析器必须坚持严格的 in-bailiwick 校验。
对运维者的建议很明确：
- 委派时优先使用域内权威服务器名称；
- 使用托管 DNS 服务时最多选两家，多了只有成本没有收益；
- 尽量避免过长的 CNAME 链，每一条 CNAME 都是一次新的解析；
- 递归解析器尽量开启 aggressive NSEC caching；
- 没有特殊原因时使用较长的 TTL，发挥本地缓存的价值。
把 329 次查询换算成体验更直观：一次冷启动解析的耗时可以从几十毫秒膨胀到数百毫秒，如果正好落在首屏的请求链路上，会直接拖累 LCP。这也是 Google Public DNS、Cloudflare 1.1.1.1 这类公共解析器愿意投入大量工程做预取与缓存预热的原因——它们把“首次查询慢”的问题前置解决，让多数用户只承担热缓存命中那一跳的延迟。
后量子 DNSSEC：三组实验给出务实的路径
DNS 与传输层加密不同：密钥一旦轮换就基本失效，因此"密钥生命周期是否落入量子计算机破解窗口"才是关键。Johan Stenstam 展示的三组 PQ-DNSSEC 实验很有参考价值：
- 高频轮换 KSK：用 DSYNC 每 10 分钟轮换一次 ED25519 KSK，运行三个月，只预发布 DS 哈希。Shor 算法破解需要的时间远大于密钥生命周期，攻击者拿到旧密钥也没有价值。
- 分离 KSK/ZSK 算法：KSK 用"大"的后量子算法保护 DNSKEY，ZSK 用签名更小的算法服务日常应答，把大响应体只留在校验路径上。
- 巨型 CSK：单个 23,843 字节的 DNSKEY 响应仍能放进 TCP 响应（小于 64K），配合大缓冲区补丁即可工作。
三组实验放在一起对比，能更清楚地看到各自的落地节奏：
| 实验方案 | 密钥轮换节奏 | 签名算法组合 | 主要代价 | 适合阶段 |
|---|---|---|---|---|
| 高频轮换 KSK | 每 10 分钟（DSYNC） | ED25519 | 仅预发布 DS 哈希 | 技术验证 |
| 分离 KSK/ZSK | 常规轮换 | KSK 后量子大算法 + ZSK 小签名 | 校验路径响应变大 | 小范围试点 |
| 巨型 CSK | 常规轮换 | 单一后量子算法 | 20KB+ 响应，依赖 TCP 与大缓冲 | 远期 |
结论是：与其在 UDP 里硬塞大数据，不如让解析器在识别到大签名算法后直接走 DoT、DoQ 或 DoH 等流式传输，代价远低于想象。
乐观 DNS 与根区本地化
乐观 DNS 允许解析器在 TTL 过期后短暂使用过期缓存并同时发起刷新，支持者认为能降低延迟，反对者（包括作者本人）认为这绕过了域名所有者设定的 TTL 语义，且缺乏"可用过期程度"的明确阈值。根区方面，本地根（local root，RFC 7706/8806）把完整根区拷贝到递归解析器本地，正被提议设为公共互联网的默认行为。
对建站与运维的启示
DNS 是网站可达性的地基。无论你是自建权威解析还是使用托管 DNS，都建议优先采用上面提到的委派与 TTL 最佳实践。想要为域名加上完整性校验，可以参考DNSSEC 配置指南；排查解析异常可以看域名解析故障排查。更多网络与 CDN 相关内容请查看CDN/网络分类。
如果今天就想动手，建议按下面的顺序走一遍：先在托管 DNS 面板里把委派信息收敛到域内权威服务器（或不超过两家的托管商），再开启 DNSSEC（多数托管商一键完成），随后把关键记录的 TTL 从 300 秒提高到 86400 秒——前提是近期没有迁移计划，最后确认递归解析器是否开启了 aggressive NSEC caching。每一步都可以独立验证、单独回滚，不必等协议标准升级，也不依赖任何一家厂商。
参考：IETF 126 会议议程 https://datatracker.ietf.org/meeting/126/proceedings/
参考：RFC 8806 本地根部署 https://www.rfc-editor.org/rfc/rfc8806
16IDC 观察
IETF 126 的 DNS 讨论再次印证了一个朴素的道理：越基础的协议，改动代价越大。无论是后量子 DNSSEC 还是乐观 DNS，落地的关键都不是单点技术，而是解析器、权威服务器、注册商与浏览器生态的协同演进。对普通站长，建议把精力放在可控范围内：合理的 TTL、精简的 CNAME 链、稳定的托管 DNS 以及必要的 DNSSEC 校验。当上层协议走向后量子时，这些基础配置的合理性会直接决定你的网站能否平稳过渡。
原文来源：https://blog.apnic.net/2026/07/29/dns-topics-at-ietf-126/