全球DNS服务重大故障：一行代码变更引发互联网连锁反应

【编辑导读】 Cloudflare的例行代码优化意外引发全球DNS解析危机，核心争议在于互联网基础协议RFC 1034对CNAME记录排序的模糊表述。此次事件导致Linux系统及思科网络设备出现解析异常，暴露出互联网底层技术对历史协议的深度依赖。尽管中国用户未受显著影响，但事件揭示的协议兼容性风险对我国关键信息基础设施具有重要警示价值。

故障始末 2025年12月，Cloudflare工程师在优化1.1.1.1 DNS服务内存使用时，将CNAME记录的插入逻辑从"前置添加"改为"后置追加"。这项看似微小的代码变更（2026年1月7日全球部署），导致部分DNS客户端解析失败。受影响最严重的包括：

• Linux系统glibc库的getaddrinfo函数
• 思科三款以太网交换机的DNSC进程（引发设备重启循环）

技术解析 DNS协议通过CNAME记录实现域名别名解析，典型流程如下：

www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1

传统实现要求CNAME记录必须出现在应答报文首位，但RFC 1034规范仅模糊表述为"可能前置"。Cloudflare的变更使CNAME记录出现在应答末尾，导致依赖顺序解析的客户端出现：

1. 忽略有效A记录
2. 无法完成别名解析链
3. 最终返回空响应

协议困境 尽管RFC 1034第4.3.1节提及CNAME记录应"前置"，但未使用RFC 2119标准中的"必须"（MUST）等规范性措辞。这种模糊性导致：

• 现代解析器（如systemd-resolved）可智能处理乱序记录
• 传统实现（如glibc）严格依赖记录顺序

中国视角 我国虽未大规模部署受影响设备，但事件揭示的风险值得关注：

1. 关键基础设施中老旧网络设备的协议兼容性
2. DNS服务自主可控的重要性
3. 参与国际协议修订的必要性

Cloudflare已回滚变更并推动IETF制定新RFC草案（draft-jabley-dnsop-ordered-answer-section），旨在明确CNAME记录排序规范。目前全球DNS解析服务已恢复正常，但事件暴露的底层协议风险将持续影响互联网技术治理领域。