Cloudflare 1.1.1.1 事故：路由撤回与 DNS 可用性问责

摘要

Cloudflare 表示，其 1.1.1.1 公共递归 DNS 服务在 2025 年 7 月 14 日 21:52 到 22:54 UTC 期间全球不可用。大多数用户受到了影响，Gateway DNS 出现了间歇性退化。直接机制是该服务生产前缀在内部拓扑变更后被撤回，而非遭受攻击或 DNS 协议缺陷导致。[1]
因果链从 6 月 6 日开始。一个尚未上线的 Data Localization Suite 服务配置意外引用了 1.1.1.1 Resolver 服务及其前缀。该错误当时未引发任何可见流量变化。在 7 月 14 日，向该非生产服务新增测试站点后触发了全局刷新，将生产拓扑从全球站点降为一个离线站点，进而导致路由撤回。[1][8]
Cloudflare 公开了受影响的 IPv4 与 IPv6 前缀，包括 1.1.1.0/24、1.0.0.0/24、2606:4700:4700::/48 及相关 Resolver 地址空间。UDP、TCP 与 DNS over TLS 流量均明显下降。DNS over HTTPS 相对稳定，因为 cloudflare-dns.com 使用了不同的地址集合。路由通告与服务名称本身不足以界定故障边界。[1][16][17]
告警在 22:01 触发并宣布事故。Cloudflare 于 22:20 回滚该配置。路由重通告将流量恢复到约 77%，但大约 23% 的边缘服务器已移除必需 IP 绑定。完整恢复在 22:54 报告完成。[1]
在 Cloudflare 撤回路由后，出现了 Tata Communications India 对 1.1.1.0/24 的 AS 起源通告。Cloudflare 将其描述为在路由系统视角下看似劫持，但明确表明该通告并非中断原因。源验证与路由监控有证据价值，但不能证明授权运营者是否从所需位置通告服务前缀或回答 DNS 查询。[1][3][18][19]
Anycast 将服务地址分布至多个地点。RFC 4786 说明了其韧性价值与监测复杂度。该 7 月事件并未表明 Anycast 本身不安全。问题在于：若服务到前缀的全局记录错误，且路由生成功能缺少“零在线位置”硬约束，错误记录会清空所有生产覆盖范围。[9][12][13]
问责应绑定于实际控制：前缀台账、拓扑、全局刷新、路由通告、边缘绑定、告警设计、回滚权限与服务恢复证明。工单或目标配置仅能证明意图，而运行状态下的路由和完成的 DNS 回答才是现实证据。
在 Heng.lu 原则下，IP 前缀和拓扑记录应保持唯一性、准确性、安全元数据和持续性。它们是可审计台账，不是替代运营网络的主权实体。若移除 DNS、IP 前缀、Anycast、BGP 与边缘绑定这些运行事实，理论本身失去支撑，故事故可复核性也会消失。

解析器在处理 DNS 查询前可能先失效

用户描述 DNS 停运时，通常会想到解析器接收域名后返回地址失败。这是一种可能，但在 Cloudflare 的 2025 年 7 月事件中并不是第一道失败。

客户端只能在报文到达解析器服务地址后发起查询。对 1.1.1.1 来说，这些熟悉地址通过 Anycast 提供。多个 Cloudflare 站点为同一前缀宣告可达性，因特网路由会选择其一。解析软件再执行递归：使用缓存条目或必要时访问权威 nameserver。[5][6][12]

这次中断先发生于到达路径。Cloudflare 的生产站点停止了相关前缀通告。发往这些地址的流量无法到达应答边缘位置。解析器并非先对域名判断错误，而是网络先失去了服务位置。[1]

这一区别对问责至关重要，因为它指出了可控系统边界。

DNS 实施团队可验证递归、缓存、DNSSEC、重试与响应正确性，但这些测试不能证明服务地址会持续可路由。网络团队可观察 BGP 通告和边缘接口，但不能证明解析进程会应答。服务拓扑系统可记录“哪个产品使用哪些前缀和位置”，却不能证明编译后路由状态或边缘绑定符合设计。

服务成功需满足以下一致：

服务身份与正确前缀匹配。
预期生产站点与服务匹配。
路由生成系统在预期站点宣布前缀。
边缘系统保留接收流量的 IP 绑定。
解析进程支持相关传输并完成查询。
监控能足够快发现分歧并支持可控恢复。

Cloudflare 复盘显示分歧始于第一、第二层并向后扩散。一个非生产对象获得了生产解析前缀引用，后续刷新把该引用编译为路由撤回，并导致部分边缘服务器移除必需绑定。[1]

将结果称为“DNS 宕机”虽通俗，但过于粗糙。真实失败是网络基础设施中的身份与可达性问题：哪个服务拥有某地址、服务应在哪可达、记录导出的路由状态是什么、以及哪个物理或软件端点准备好接收流量。

因此状态页不能作为唯一证明。状态页可能显示某 DNS 组件可用，但其前缀可能在关键路由视图中缺失；路由采集器可能显示前缀存在，但无健康解析器绑定；进程监控可能显示守护进程存活，但无报文接收。问责控制是对这些状态的一致对账，而非某一指示灯的“绿灯”。

沉睡错误早已具备生产风险

Cloudflare 将该配置错误的引入时间定为 2025 年 6 月 6 日。公司当时正在为未来 Data Localization Suite 服务准备服务拓扑。新服务尚未上线，配置却意外包含对 1.1.1.1 Resolver 服务及其前缀的引用。[1]

当时没有可见变化：无路由变更、无流量转移、无告警。该记录在生产配置环境中静默存在。

这段静默期并不表明记录无害，而是说明系统尚未执行该记录。

配置系统常包含未激活、暂存、计划上线或关联离线站点的对象。运营者需要这些状态来表示未来服务。但当沉睡对象可在无冲突检查下主张或引用生产关键资源，并在后续操作中触发全网刷新时，就会形成风险。

因此有用的问题不是“6 月改动是否改变流量”，而是“6 月记录获得了什么控制权”。

若该记录可影响生产前缀所有权，那么即使服务仍离线，也已跨越生产风险边界。评审人或自动验证器应识别其潜在效应。短期无流量变化使常规健康告警无效，因为事件本质是状态完整性缺陷，而非服务健康缺陷。

准确的控制平面应能回答：

每个生产前缀的授权所有者是谁？
是否允许两个服务对象引用同一前缀？
若允许共享，规则如何决定最终位置集合？
非生产服务能否收窄生产前缀的全局拓扑？
下一次编译/刷新会由哪个操作触发？
该操作将产生什么路由与边缘绑定变更？
哪条不变量可阻止全局服务降为零在线位置？
谁必须批准关键公共地址的跨环境引用？

这些问题都可成为确定性检查项，而非流程性“摆样子”。

前缀所有权表应要求单一授权服务标识。拓扑编译器应在发布前算出有效位置集合。策略可拒绝零在线站点输出。变更预览应展示非生产对象影响的全部生产前缀。独立观察者可将计划输出与当前通告路由对比。

目标不是禁用沉睡配置，而是防止沉睡权威在未审查下扩展。

Cloudflare 当前 Data Localization 文档说明了为什么要控制流量处理位置，包含地理与合规导向，但无法证明 2025 年 6 月和 7 月的私有数据模型或修复状态。[8] 复盘是机制性证据的起点，文档用于说明服务位置为何是关键配置输入。

这一区分很重要：不能从当前公开文档中推断某一具体架构、数据库或部署工具。公开记录未披露这些细节。问责并不要求“补齐”未知内容，而是要求命名可观察控制要求：离线或未来服务不得在未审查时获得生产解析前缀控制权。

一次全局刷新让记录变成了运行路由状态

在 7 月 14 日，Cloudflare 向该非生产服务添加了测试站点。该站点本身未上线，但该变更触发了全局网络配置刷新。由于 6 月记录已将 1.1.1.1 前缀与该服务关联，刷新中纳入了这些前缀，解析服务的有效拓扑从全部生产站点骤减为单一离线站点，其前缀被撤回。[1]

该序列说明，变更影响半径应基于“渲染输出”评估，而非输入文本大小。

输入可描述为“给一个非生产服务新增一个测试站点”，输出却影响了公共递归解析服务和多个 IPv4/IPv6 前缀。两者都兼容，但只有输出揭示运维风险。

自动化会放大紧凑声明：一段简短配置可能为许多路由器、主机或站点生成规则。这是自动化优势，但也要求评审可见其展开后影响。

此类变更应支持的安全预览至少包括：

每个拓扑变化的服务。
每个新增、移除或重分配的前缀。
每个将开始或停止通告某前缀的站点。
每个将新增或移除的边缘绑定。
受影响的每个协议端点。
最小剩余在线站点数。
预期 BGP 通告变化。
预期 DNS 查询分布变化。

预览应由与部署同源代码与同源数据路径生成。若由不同逻辑产出的摘要与真实编译不一致，实践上会使“复核对象”与“实际代码”背离。运行优先意味着可部署候选输出本身应是复核对象，不是仅有的人工描述。

同样适用于金丝雀策略。第一步很小只有在触发故障模式时才有价值。测试站点加入离线服务看似安全，因为预期无客户流量；但若操作会调用全局路由刷新和前缀关联逻辑，金丝雀必须观察全局输出。仅做离线站点本地端点测试会遗漏关键影响。

因此 7 月事件挑战了“非生产变更”这一口径。

对象可以在客户使用中是非生产状态，但其元数据却可参与生产编译器。站点可离线，却可触发全局重算。服务可无用户，但前缀关联可改变广泛使用的公共解析。环境标签不界定真正边界，数据流与部署权限才界定。

这不意味着所有预发布记录都应按线上故障处理。组织应按系统和可变资源分类。带有生产前缀引用的非生产对象，应比孤立无路由生成权的测试对象归入更高风险。

此类分级可在有边界的证据里完成：工单可标记受影响编译器；机器预览可列出触及的生产资源；策略结果可记录不变量检查；金丝雀报告可显示路由与服务观测。留存文件比抽象声称环境隔离更有效。

Anycast 分散了服务，也集中暴露了控制错误

Anycast 通常被描述为韧性技术：同一服务地址在多个位置可达，路由将用户导向其中之一。RFC 4786 对模型做了定义，并指出由于可达性依赖客户端位置，监测更复杂。[12]

Cloudflare 广泛使用 Anycast，包括 1.1.1.1。其当前文档与公开网络材料描述了全球分布式服务与地址空间公告。[4][5][9][10][11]

7 月事件不能解释为 Anycast 天生失败。该设计创造了多条可达位置，但配置系统却将这些位置的可达性同时移除。

这一区分了数据平面冗余与控制平面独立性。

多个位置可服务同一地址。若均消化了同一错误全局拓扑记录，位置数量不能提供独立保护。队列在物理上分布，故障上却是同模态。

协议路径暴露了真实影响范围

Cloudflare 报告称，前缀撤回后，UDP、TCP 与 DNS over TLS 解析查询立即显著下降。许多用户将 1.1.1.1、1.0.0.1 或 IPv6 等价地址直接配置在本地，导致到 Cloudflare 生产服务的路由消失。[1]

DNS over HTTPS 相对稳定，因为许多用户访问 cloudflare-dns.com，该主机名使用不同地址集合。部分其他地址上的 UDP 流量也更稳定。[1]

这一差异有多条问责启示。

第一，产品可有多条交付路径且依赖不同。文档或讨论里都可能都称其为 1.1.1.1，但实际控制边界在客户端使用的端点与地址集合。

第二，多样性只有真实且可用才有价值。DoH 在本次事件中更稳，因许多客户端走了与 HTTPS 标签无关的不同地址；未来故障可能正好影响该地址或主机名解析路径。

第三，影响说明应区分路径。说“1.1.1.1 停用”可概括客户体验，但不解释为何仍有请求成功。说“所有 DNS 停用”则不准确。复盘中的传输与端点区分更有解释力。[1][16][17]

第四，客户并不总能在中断时切换协议。将字面地址写在设备上的解析配置，未必有安全、隐私、性能或策略允许的自动 DoH 路径。运营网络转发订阅查询往往有合同、隐私、性能或策略约束；文档中的备用方案并不等于在用户环境中已部署、授权和验证。

因此客户侧问题不是“为什么大家没切换”，而是关键用户是否理解解析依赖、是否具备兼容备援，并在不引发安全或策略回归下完成过测试。

服务侧问题是事故前是否识别了路径差异，并在监控与沟通中使用。有效公告应说明哪些地址和传输受损，哪些仍可用，用户可做哪些操作，以及备援行为的风险。

证据应保留：

按端点与传输细分的查询率。
代表性网络中的可达性。
解析成功、超时与错误率。
客户端重试行为。
故障转移或备用解析器启动记录。
备援路径的安全与隐私属性。
按路径划分的恢复时间。

这类记录可使影响边界可检验，也可防止将“存活路径”用于掩盖另一条主链路故障。

无关的源公告是证据而非根因

21:54，Cloudflare 自身通告已减少之后，Tata Communications India AS4755 公布了 1.1.1.0/24。Cloudflare 说明从路由角度这看起来像前缀劫持，但该公告并非本次中断原因。[1]

这一区分必须保留。

撤回导致一个其他来源可见，因为路由下出现了此前不易见的路径。该现象与为什么会有这类公告、传播方式、路由源控制适用性、以及到底有哪些流量流向相关，而不是改变根因顺序。

将两者混为一体会产出更戏剧化却更薄弱的叙事，也会把修复方向推向错误控制面。

RFC 6811 所述 RPKI 源验证允许路由器依据路由源授权判断 AS 是否被授权。[18] BGP 运维指引讨论过滤与路由卫生。 [19] 这些控制可减少部分未授权源风险。

但这些都不能代替可用性。

授权运营源可撤回其路由。合法通告也可在无运行解析器的边缘终止。正确通告可能仍只在很少位置。边缘可保留 IP 绑定但服务可能不健康。反之，异常路由也未必是初始故障原因。

7 月事件再次界定安全元数据的边界。

路由源记录回答“该源是否被授权该前缀”，但不回答：

该前缀现在是否应公告？
应通告多少个生产位置？
该路由是否导向预期服务？
边缘绑定是否存在？
解析器是否正确应答？
拓扑变更是否撤除了授权运营者自己的路由？

这与 Heng.lu 原则关于台账与记录的处理一致：台账可让身份、授权和变更历史可审计，但不能凭声明操控数据平面，路由与服务仍需真正运行。

复盘中的非因果说明本身是重要的证据实践。事故报告应将并发观察与因果链分开：标记异常何时出现、为何可见、以及已知与未知内容，帮助运营者修复触发故障链条，而非忽略新暴露路由问题。

用户失去路由后才开始监测

Cloudflare 表示 DNS 流量从 21:52 开始下降，内部告警在 22:01 开始触发并声明事故。[1]

九分钟窗口在某些场景短，在全球解析服务中不算短。关键是信号来源。

6 月错误未触发告警，因为未变更流量。7 月 14 日，在路由撤回导致入站查询下降并引发解析、代理与数据中心故障后才告警。系统是在全局刷新生效后检测到后果。

结果监测是必要的，但控制面也需要发布前及变更关联信号。

三类检测层可分离：

状态完整性检测

该层在发布前检查配置图是否内部有效，可发现重复前缀所有权、非生产服务引用生产资源、零在线位置输出，以及服务重要性与变更范围不匹配。

变更影响检测

该层观察渲染后且已部署的差异，在金丝雀窗口中比较预期与实际 BGP 通告、边缘绑定和位置集合。

服务结果检测

该层测量用户体验：可达性、DNS 查询完成、延迟、超时和响应码等协议级健康。

三层回答不同问题。状态校验可拦截已知无效输出，不必等待影响；变更影响检测可捕获编译或部署错误；服务监测可捕获配置模型未覆盖的故障。任一层单独都不足以形成完整监控。

有效配置模型可能错误实现。正确路由差异仍可能指向不健康服务。成功合成查询仍可能漏掉区域 catchment 或客户网络。公开路由采集器也可遗漏私有路径。控制目标是及时发现不一致。

对全球解析服务而言，变更闸门可要求：

关键前缀所有权无未授权变更。
生产前缀未低于最小健康站点集合。
独立 BGP 视图无未计划撤回。
边缘绑定损失在批准范围内。
查询量异常下降需有可解释的预期流量依据。
任一协议超时上升有明确告警。
管理与回滚可达性不丢失。

每项都需要明确责任人和停止动作。仅告警无权停止或回滚是观测系统；能停止但缺少独立数据的变更管道则可能阻断正常工作或固定异常状态。运行设计必须将证据与决策权连接。

重新通告只是部分恢复

Cloudflare 在 22:20 回滚触发配置。公司称这几乎立即恢复撤回前缀通告，并将解析流量恢复到约 77%，但约 23% 的边缘集群已被自动重构为移除必需 IP 绑定。[1]

剩余恢复有不同运维特征。

常规绑定恢复通常采用多小时渐进式回滚以降低引入新问题风险。事故期间，Cloudflare 在有限站点先做手工加速，再扩展执行。到 22:54 流量基本恢复到正常水平。[1]

该序列揭示了三类状态：

服务拓扑记录已回退。
BGP 前缀已重新通告。
边缘服务器恢复了接收并提供服务所需 IP 绑定。

如果在第一状态就关闭事件，会将配置意图恢复误解为完整恢复；第二状态则将通告可见误解为服务完成。第三状态仍需解析和客户路径验收。

恢复证据应分层：

回退记录与审批。
回退后的路由渲染集合。
独立观测到的重新通告。
按站点的边缘绑定清单。
解析进程健康。
按传输和区域的查询完成。
与基线边界比较的流量。
残留错误与客户反馈。
加速发布的决策与测试证据。

77% 不应被视为统一用户恢复百分比。它是按 Cloudflare 账户指标对比前流量得出的值。用户影响取决于解析配置、地域、重试与备用路径。该值价值在于显示“路由重新通告后并非立即完全恢复”，而非用户群占比。

渐进发布与紧急恢复之间存在权衡。

渐进发布在常规变更中压缩影响半径；但若故障源于缺失绑定，慢发布会拉长不可用。加速恢复可更快修复，但提升未测试全局变更风险。Cloudflare 称其在加速前已在测试站点验证手工动作。[1]

有问责性的应急流程应明确：

谁可覆盖正常发布节奏。
加速时仍需通过哪些测试。
首批恢复金丝雀包含哪些站点。
哪些指标应停止加速。
独立观察者如何确认改善。
并发变更如何锁定。
如何恢复正常部署控制。

应急路径应在故障前演练，避免组织在用户离线时才发现权限、工具和依赖关系。

问责必须覆盖完整控制链

把事件归咎于单一作者具有吸引力，但公开记录不足以支持个人归责；即使足够，分布式控制链也使该说法不完整。

实际控制存在多个层级：

服务归属

有人定义 1.1.1.1 服务的关键性、前缀、端点和站点要求。该责任方应定义不变量与可接受恢复条件。

号码资源与网络归属

有人控制生产前缀、BGP 通告、对等关系和路由系统。该责任方应保持准确身份与路由状态记录并实施独立观测。

拓扑系统归属

有人设计并运行服务拓扑与全局刷新机制。该责任方应执行环境边界、引用完整性、渲染差异审查和安全回滚。

边缘平台归属

有人控制服务地址在边缘服务器上的绑定与移除。该责任方应定义路由与绑定何时可变更及其对账证明。

解析归属

有人运营递归 DNS 软件、传输、健康检查与 SLO。该责任方应测量查询完成，而不是仅从路由状态推断。

事故指挥

有人协调检测、回退、手工加速、公告与复盘。该责任方应阻止冲突变更并保持统一时间线。

客户与网络运营依赖方归属

配置客户端或订阅网络依赖 1.1.1.1 的组织需负责其备用解析策略、测试、隐私和安全权衡。其责任并不否定提供方对故障机制的控制义务。

共享责任并不等于责任不明。每个责任方都应有可测试职责和可保留证据。

前缀所有者可证明授权服务关联唯一，拓扑负责人可证明零在线站点不变量，网络负责人可证明预期通告，边缘负责人可证明绑定，解析负责人可证明应答，事故指挥可证明编排时间线，客户可在风险场景下证明连续性测试。

这样可避免两个误区。

其一是认为服务运营商对一切负责，忽视客户架构与公共免费解析的边界。其二是认为客户应使用备用解析器故提供商不负责任，忽视对误关联、刷新、路由撤回、绑定和修复过程的控制。

问责追随预防、检测、限制、披露与恢复中的实际控制。某一方减少了暴露范围，不意味着控制失败机制的一方免除职责。

Heng.lu 现实层是可运行的服务身份

Heng.lu 现实层将台账和记录者视为“记录机构”，不把它们当作运营现实的主权创造者。它优先采用运行代码，并将号码资源视为必须具备唯一性、准确性、安全元数据和连续性的对象。

7 月事件是直接的网络示例。

1.1.1.1 前缀有身份。服务有名称。拓扑记录关联服务、前缀和位置。BGP 与 RPKI 提供额外路由和授权证据。它们都重要。一次不准确关联是失败起点。

但记录本身不决定解析器是否可达。

在自动化将记录变为路由撤回和边缘绑定变更后，状态才发生变化。恢复在路由重通告、绑定回归和查询完成后推进。运行网络才解决了意图与实际的分歧。

这不是反对台账，而是要求更强的、可执行的台账。

生产服务前缀的台账应保留：

前缀与地址族。
授权服务所有者。
预期生产站点。
路由源与授权元数据。
边缘绑定要求。
协议端点。
变更历史。
关键性与最小在岗策略。
依赖关系与恢复责任人。
最近一次路由与服务核验结果。

台账应使冲突主张可见，而不是仅因字段被填而判定成功。

运行证明应包括：

渲染后的路由输出。
路由器通告状态。
独立采集器可见性。
边缘接口与绑定状态。
解析健康。
代表性路径上完成的 DNS 查询。
恢复演练结果。

台账作为运行记录并非被动文件。高质量台账可驱动校验、授权与审计，可拒绝重复所有权或缺失元数据。它不能把声明替代报文递送。

这一原则也约束报道措辞。

它既不是要求单一中心对每条路由和配置审批，也不是主张 RPKI、RIR、监管机构或厂商成为 Cloudflare 的主权网络主导者，更不是以社区或地域标签定义合法性。

这是一条现实层主张：若某记录可撤回公共服务前缀，其权威、准确性与影响必须可对照到实际运行的路由与服务状态。

应有一条不变量，防止全球服务到达零在线位置

Cloudflare 的复盘显示，解析前缀拓扑从全部位置缩减为单个离线位置。[1] 这直接给出控制目标：关键全球服务在未显式授权的应急关闭路径下，不应可部署为零在线生产位置。

该不变量需谨慎设计。

“大于零”可能过弱；单一在线位置可能不足以承载容量或覆盖。固定最小数量也可能不兼容维护、地域限制或服务设计；禁止一切撤回则可能把路由保留在受损节点。

更强不变量可包含多维约束：

至少保留定义好的健康生产位置最小数。
覆盖多个独立故障域。
具备预期流量的充足容量。
禁止从全球范围未授权退回到局部范围。
非生产对象不应成为生产前缀的唯一拥有者。
在替代健康位置验证前不移除边缘绑定。
全局撤回必须有明确应急授权。

该约束应作用于渲染候选与当前观测状态。

若配置显示十个站点仍保留，但其中五个已离线维护，静态候选检查可通过却不代表运行结果充分；反之路由采集器可见多个通告，也不一定对应健康解析进程。门禁需引入带边界的最新健康与容量输入。

结果应保持 fail-closed。若校验器不可用，不应静默绕过；网络异常时，事故指挥可按边界授权执行有限覆盖重置。该覆盖应命名、限时并有日志与后恢复对账。

有用的不变量报告可包含：

字段	证据
候选服务到前缀映射	精确渲染配置 SHA
当前生产映射	只读快照与时间戳
预期站点	按环境与健康状态的有序列表
剩余在线站点	数量、区域、容量与故障域
路由变化	前缀与站点逐项通告/撤回
边缘绑定变化	按站点新增或移除的地址
外部观测	选定 BGP 采集器与客户路径探测
服务观测	按传输、区域和端点的 DNS 应答
覆盖状态	责任人、原因、过期时间和审批

这并不要求公开敏感拓扑。完整报告可保密。公开部分可披露控制类别、时间、范围、测试结果及尚未消除限制，不必公开具体管理地址或内部架构。

修复承诺需要可持续的运行证据

Cloudflare 复盘称其正在移除配置系统的遗留全局范围、增加 1.1.1.1 全局撤回保护、改进校验和告警，并审视遗留系统。[1]

这些方向覆盖了正确失败面。

移除全局范围可降低冲击范围；受保护前缀策略可阻止灾难性输出；改进校验可捕获引用与拓扑错误；改进告警可缩短检测；遗留系统审视可识别隐藏控制权。

但公开记录未证明每项已完成或持续生效。

这并非特例。复盘通常先给出短期修复与计划，长期效果随后验证。问责应要求后续收口分清：

拟议修复。
已上线控制。
已测试控制。
已演练控制。
控制持续运行中的例外与记录。

对该失败类别，持久性证据可能包括：

前缀关联冲突测试

一项将生产解析前缀绑定到无关非生产服务的测试应被拒绝，并记录所有权冲突责任。

零在线位置测试

若候选拓扑将解析服务置于零在线生产位置，编译器应在路由生成前拒绝。

渲染差异审查

测试站点变更应输出机器可读列表，展示所有受影响生产前缀和站点，避免仅因输入看似局部而忽视全局影响。

路由撤回金丝雀

受控演练验证在选定公开 BGP 视图出现意外撤回时，发布停止且恢复通道可用。

边缘绑定对账

系统比较变更前后意图绑定、主机状态和路由状态，识别路由已重通告但绑定未恢复的 77% 场景。

协议路径探测

UDP、TCP、DoT 与 DoH 探测使用与真实客户端一致的端点选择，记录备援路径是否真正独立。

应急加速演练

运营方恢复绑定时，验证加速金丝雀通过、冲突变更被锁定，并重新回到常规渐进流程。

该证据包的价值在于证明故障类型被界定、可观察、可恢复，而不是承诺“再无事故”。

一套可落地的证据清单

董事会、客户、监管方和技术审查者无需全部私有命令即可评估控制模型；但需要机制级证据。

控制项	保留证据	运行测试	局限
前缀所有权	服务-前缀台账、所有者、历史与授权	重复或跨环境主张被拒绝	唯一记录仍可能错误
拓扑完整性	渲染后的服务-站点图	关键服务保留批准的健康生产范围	健康数据可能过期
全局风险预览	精确的路由和绑定差异	小输入展示全部生产输出	编译缺陷可影响预览与发布
受保护前缀不变量	版本化关键前缀策略	阻止关键前缀出现零在线输出	应急撤回仍需专门通路
变更金丝雀	代表性编译、路由与边缘绑定结果	独立观察前后应一致	单点金丝雀不能覆盖全部 catchment
BGP 观测	路由日志与独立采集器	预期通告保持可见	采集器不覆盖全部路径
边缘绑定清单	按站点的主机绑定状态	路由与绑定状态对账	绑定不等于解析健康
解析服务证明	按端点、传输、区域的查询完成	真实问题在边界内可回答	合成测试仍有限制
回滚权限	事故锁定、责任人和命令台账	单次恢复序列不可被覆盖	人工介入可绕开自动化
应急发布	覆盖、金丝雀、停止标准和到期	加速恢复可被验证	紧急性会增加运行风险
客户连续性	依赖关系图与备援路径测试	关键服务可在一定解析损失下存活	备用路径可能共享相同依赖
修复持续性	定期演练与例外记录	已知失败类型持续可控	测试不能覆盖全部未来行为

每项区分的是“记录”与“结果”。

台账必要，但不充分；拓扑图必要，但不充分；BGP 视图必要，但不充分；DNS 应答必要，但不充分用于所有路径。

当以下状态一致时，证据链才可信：

批准记录有独立责任人。
渲染输出满足关键不变量。
发布路由与渲染结果一致。
边缘绑定与路由终止一致。
解析进程在预期传输中完成应答。
代表性用户可达服务。
恢复证据关闭所有受影响层。

敏感细节可保护。具体路由配置、管理地址、内部服务名与安全控制属于高敏场景。独立评审可在保密框架下访问。公开证据可披露控制类型、时序、范围、测试结果与未解决限制。

运营者、客户与审查者的问题

网络和平台运营者应问：

哪套系统是服务-前缀所有权的权威？
非生产对象是否可引用或收窄生产前缀？
评审是否显示渲染后的全局路由和绑定差异？
是否存在零健康生产位置的阻断不变量？
谁可根据独立观察停止发布？
路由、边缘绑定与解析健康是否对账？
故障时能否在拓扑系统故障下继续恢复？
谁持有事故变更锁？
应急发布如何加速并回归常规？
这种失败类别最后一次演练是什么时候？

客户和转发网络运营者应问：

哪些关键服务直接配置为 1.1.1.1 地址？
哪些使用 cloudflare-dns.com 或其他路径？
是否已配置兼容且测试过的备用解析器？
故障切换是否保留隐私、过滤和安全策略？
本地缓存或架构是否减少依赖，且不引入过期/不安全回答？
哪些日志显示实际影响，而非单一运营商公告假设？
当选定解析器不可用时，运营沟通是否持续？

审查者应问：

六月记录是否已有生产风险的潜在控制权？
七月预览是否识别了解析前缀撤回？
金丝雀是否覆盖全局刷新路径？
受保护前缀策略是否使用最新站点健康状态？
路由恢复、绑定恢复和查询恢复何时分别发生？
证据是否将非因果的 Tata 公告与根因严格分离？
哪些修复承诺已有当前测试结果？
哪些限制仍保留为私有或未知？

这些问题并不要求“零故障”，而要求控制与后果关系清晰且可验证。

比较边界同样重要

Cloudflare 已发布多起涉及路由或 1.1.1.1 的事件，不能按“同类故障”一概而论，否则会抹去差异。

2022 年 6 月故障涉及 BGP 导出策略顺序、Multi-Colo PoP 架构和分阶段变更治理，并已有一篇独立的 Daniel Kade 文章说明。2025 年 7 月事件是服务拓扑误关联导致解析前缀全局撤回。

2024 年 6 月 1.1.1.1 事件是路由劫持与泄露。机制与本次不同。

7 月出现的 Tata Communications India 公告是并发且非因果的，依据 Cloudflare 说明不应与 2024 对照或作为解析器消失的直接原因。

Cloudflare 的这次配置失败涉及不同服务与控制路径。泛化“全球配置”不能使两个事件等价。

本次事件的边界是明确的：不准确的服务-前缀所有权、全局拓扑刷新、路由撤回、边缘绑定移除以及公共递归 DNS 服务的分层恢复。

来源限制

Cloudflare 复盘是该事件机制、时间线、受影响前缀、路径差异、恢复与修复机制最详细的公开来源，属于第一方说明。公开记录未披露完整配置图、编译器、私有路由状态、全部边缘主机、变更审批、全部告警、客户影响明细和内部决策记录。[1]

Cloudflare Radar 提供公共 DNS 与路由视图，由 Cloudflare 运营，采集源与网络覆盖有限，因此不能代表所有路由、递归器、运营商或用户路径。[2][3]

当前 Cloudflare 文档说明公共解析、上游解析、网络运营者使用、Data Localization Suite、IP 地址与对等关系。文档持续更新，不能证明 2025 年 7 月私有架构或修复状态的完整情况。[4]-[11]

RFC 规范定义 DNS、Anycast、BGP、加密 DNS、源验证及运维实践，但不能界定 Cloudflare 的私有实现、合同责任或法律尽职标准。[12]-[19]

2024 年 6 月复盘只用于边界对比，不能据此推断本次 2025 年事件存在同一行为体或控制链。[20]

文章未给出恶意、掩盖、过失、刑责、监管违规、客户损失总量或个体过错的断言，也未断言 RPKI 可防止该中断，或所有修复措施均已实施并有效。

77% 与 23% 两个数值分别指 Cloudflare 账户的路由重通告后流量恢复比例与已移除绑定的边缘服务器比例，不是用户人数比例或用户影响人数。

这些限制不削弱问责分析，而是定义从详细复盘到持续控制证明所需的下一步证据。

结论

Cloudflare 的 2025 年 1.1.1.1 停运始于不准确记录，当自动化将其转为路由输出后才在全球层面中断。非生产服务的拓扑记录关联到生产解析前缀，之后一次测试位置刷新触发了全球重算，解析拓扑收敛到单一离线位置，生产路由被撤回，部分边缘移除必要绑定。[1]

这一事件既是 DNS 层面的服务中断，也是路由层面的状态故障。两者都成立。解析器可达性丢失时，用户自然无法完成查询；不同传输和端点集合决定了不同实际结果。路由重通告先恢复了部分流量，但完整恢复直到绑定与服务状态对齐后才实现。[1]

可问责控制不是泛化“更认真审核配置”，而是具体证据链：

每个生产服务前缀有唯一责任人。
全局路由与绑定影响有可渲染预览。
关键场景禁止零在线生产位置。
代表性金丝雀覆盖真实编译与刷新路径。
独立 BGP 与客户路径观测。
路由、边缘绑定和解析状态可对账。
单一事故修改责任人与可验证应急恢复路径。
修复持续性有当下测试结果。

RPKI、路由采集、拓扑台账、工单和状态页都能贡献，但不能替代实际运行服务。授权并不等于可达，路由并不等于查询成功，健康进程并不等于可达，意图拓扑并不等于部署状态。

这就是 Heng.lu 现实层。号码资源和服务记录应保持唯一、准确、安全和连续，以便运行可被审计。它们是台账，而非让报文到达的主权命令。最终证明仍是：前缀持续从健康位置公告，边缘仍绑定，解析器可应答，且当普通控制平面出现问题时，恢复路径依然可执行。

Cloudflare 的复盘提供清晰因果链和相关修复方向，下一步应是可持续证据：拒绝同类跨环境绑定、阻断零在线输出、对账路由与绑定、演练恢复并长期记录例外。

全球基础设施将持续依赖紧凑配置来管理大规模网络。正确做法不是放弃自动化或 Anycast，而是让它们的权威可见。小输入要在发布前显示全球输出；记录必须说明它控制哪些资源；金丝雀应代表可失败系统；恢复仅当用户可完成服务时才算结束。

Cloudflare 的 2025 年 1.1.1.1 事故：路由撤回成为 DNS 问责测试

为何重要

摘要