Summary

  • 11 月 5 日的个人草案建议：涉及 CNAME 的 DNS 应答先放查询名称的别名记录，再按链路顺序放后续别名，最后放目标地址记录。相比早期版本，它把规则收窄到了实际发生互操作故障的情形。
  • 草案记录了 1 月一次解析器发布后的故障：CNAME 应答顺序变化，glibc 名称查询失败，一些以名称查询 NTP 服务器的以太网交换机重启。Cisco 官方支持文档列出受影响设备系列和 DNSC 进程致命错误。

惹事的不是新字段，而是旧字段的排队方式。递归解析器回答一个别名时，可以在同一 Answer 区段放入最初的 CNAME、下一跳 CNAME 和最终 A 记录。RFC 1034把 CNAME 描述为答案前可能出现的“前言”，也要求把记录复制进应答，却没有明确把“复制”写成有序追加。一端把记录集合当无序包裹，另一端按顺序读取。2026 年 1 月 8 日，一次解析器软件变更改变了 CNAME 应答里的 RRSet 顺序。IETF 草案附录称，回归测试漏掉了它，因为测试把顺序视为无关紧要。随后 glibc 查询失败，一些交换机在解析配置好的 NTP 名称时重启。

Cisco 的支持记录列出 Catalyst 1200/1300、CBS 250/350 及具体固件版本，故障表现为 DNSC 进程致命错误。厂商认为某些 DNS 应答格式可能触发问题，并提出更换 DNS、停用名称查询或设置静态映射的临时办法。这是设备厂商的故障记录，不是全网受影响数量。IETF 作者把事件与 CNAME 顺序变更联系起来；官方材料没有提供整个设备群的损失测量。

11 月的 02 版提出更窄的修补：服务器构造 CNAME 链应答时，先追加原查询名称的 CNAME，再按链路顺序追加后续 CNAME，最后给出目标记录。同一 RRSet 内的单条记录顺序仍无意义。客户端应该接受不同的 CNAME RRSet 顺序，但服务器不得依赖客户端这种宽容。8 月的 01 版曾要求更广泛的 DNS 区段排序；收到工作组反馈后，02 版收窄范围。IETF 跟踪页仍将其列为个人草案，只有获批才会更新 RFC 1034。

标准要分配的是旧软件的成本。服务器保持保守顺序，能让暂时无法升级的设备继续工作；客户端学会容忍顺序变化，能减少下一次依赖。测试记录应同时保存解析器版本、两种应答字节、CNAME 链、glibc 结果、NTP 查询及交换机日志。一个成功的 DNS 响应码，不能证明交换机没有重启。