Azure 2021 年 DNS 缓存缺陷让重试放大成为问责考验

摘要

2021 年 4 月 1 日 21:21 UTC 至 22:00 UTC 期间，Azure DNS 发生服务可用性问题。Microsoft 表示大部分依赖服务已在 22:30 UTC 前恢复。其当时的社区公告使用了约 21:30 至 22:30 的影响时间窗，而独立监控在大约 21:20 报告了告警。这些是不同的观测结果，并不一定相互矛盾。[1][2]
Microsoft 描述了一次来自全球各地、针对一组托管在 Azure 上的域名的异常 DNS 查询激增。该公司没有公开确认攻击者、意图、僵尸网络或经证实的分布式拒绝服务攻击活动。除 Microsoft 的描述外，引发此次激增的原因仍不明确。[2][4][5]
Microsoft 表示，一个特定事件序列暴露了一个代码缺陷，降低了 Azure DNS 边缘缓存的效率。公开记录并未披露代码路径、缓存键、命中率、受影响的边缘节点范围或每次未命中引发的后端工作量。[2][4][5]
随着 DNS 服务过载，客户端以更高频率重试请求。Microsoft 表示，流量尖峰缓解系统认为这些重试属于合法流量，因此没有丢弃它们。这支持重试放大反馈回路的推测，但不能用于精确重建数据包层面的过程。[2][4]
Microsoft 表示监控检测到可用性下降，工程师介入，DNS 服务于 22:00 UTC 自动恢复。该公司承认恢复时间超过了设计目标。随后，它调整了缓解逻辑以防范过量重试，并列出缓存缺陷修复和更完善的异常流量检测作为后续步骤。[2][4][5]
该事件影响的是网络控制平面，而非单一应用程序。用户在解析 Azure、Dynamics、Xbox Live 及其他 Microsoft 服务所使用的名称时出现间歇性困难。当运行中的权威解析路径无法返回可靠答案时，即使服务记录正确也无济于事。[1][3][6]
当前的 Azure 文档描述了一个全球任播 DNS 网络、可靠性功能及客户控制选项。这些材料说明了架构和责任，但不能作为 2021 年具体实现或修复完成的证据。[7]-[13]
DNS 标准将权威服务与递归解析区分开，并记录了缓存、无响应和重试如何影响负载。RFC 4697 尤其相关，因为解析器的重试行为可能给权威服务器带来过多工作。但标准并未说明本次事件中哪些客户端或解析器贡献了多少流量份额。[14]-[22]
责任随控制权而定。Azure DNS 工程团队控制了缓存代码、边缘容量、流量整形、缓解分类和恢复自动化。Microsoft 各服务团队控制着共享的 DNS 依赖。解析器和客户端运营方控制着重试与缓存行为。客户可以控制部分监控和委派选择，但无法检查或修复 Azure 的内部缺陷。
可信的修复需要有时限的证据：按查询类型划分的缓存命中率、重试率、边缘节点饱和情况、任播覆盖范围变化、缓解规则行为、已知有效解析探测、各服务恢复情况以及复发测试。这些都不能仅凭一个状态标签来推断。

时间线中包含多个时钟

事件报告往往会随着时间推移而变得“更干净”。Azure DNS 的记录应当避免这种清理抹去有用的区别。

Microsoft 后来发布的事件说明将 Azure DNS 服务可用性问题定在 2021 年 4 月 1 日 21:21 UTC 至 22:00 UTC 之间，并表示大部分服务在 22:30 UTC 前恢复。Exoprise 转载了这一说明，并报告其自身的 DNS 和服务器监控在大约 21:20 发出了告警。[2] Microsoft 的一名员工在响应仍在进行时发布的社区公告中，将客户影响描述为大约 21:30 UTC 至 22:30 UTC 之间。同一页面稍后另一名 Microsoft 员工的更新称，Microsoft DNS 服务器出现了流量激增，并已启用弹性 DNS 能力。[1]

这些时间戳衡量的是不同的事物：

外部监控器首次观察到故障的时间；
提供商后来认定的 DNS 服务状况开始时间；
提供商认为 DNS 自动恢复的时间；
客户经历间歇性访问的时间段；
大部分依赖服务恢复的时间点。

The Register 当时的报道引用约 21:30 UTC 的开始时间，并称 Microsoft 在调查期间将流量重新路由到弹性 DNS 能力。报道描述了主要地理区域受到的影响，同时将 Microsoft 政府云和中国服务排除在所述范围之外。[3] TechCrunch 则单独报道了多个 Microsoft 产品出现故障，并引用 Microsoft 承认存在 Azure 门户和 Azure 服务问题的说法。[6]

公开证据无法为所有名称、解析器、区域或服务确定一个统一的恢复时刻。DNS 缓存可能让故障与恢复在不同时间显现。拥有热缓存答案的解析器可能在权威服务可用性下降后仍持续提供某个名称的解析；而冷缓存的解析器则可能立即失败。当权威服务恢复后，客户端和中间解析器上残留的否定或失败状态仍可能延迟可见恢复。Microsoft 自身也将 DNS 自动恢复时间 22:00 与大部分服务恢复时间 22:30 区分开来。[2]

这种区分对问责至关重要。如果用户仍无法解析关键名称，提供商就不应仅以内部服务器指标来定义恢复。同样，也不应自动将外部告警视为根本原因的开始时间。一份协调一致的时间线至少需要四条轨道：权威服务健康、递归解析器结果、依赖服务恢复以及用户可见可达性。

异常激增不等于已证实的攻击

Microsoft 表示，Azure DNS 收到了来自全球各地、针对一组托管在 Azure 上的域名的异常查询激增。[2][4] 这是对流量规模与目标分布的描述，本身不能确定是谁制造了流量、是否存在恶意意图、源地址是否被伪造，或者该事件是否符合某种拒绝服务分类。

一些报道使用了攻击性措辞。本文所引用的技术记录并未提供数据包样本、归因报告或 Microsoft 指明 DDoS 攻击活动的声明。因此，未来的证据标准应当收窄：

Microsoft 所述已确认：一次全球查询激增针对一组托管在 Azure 上的域名。
Microsoft 所述已确认：服务正常的缓存和流量整形机制本应缓解此类激增。
Microsoft 所述已确认：一个代码缺陷在特定事件序列下降低了边缘缓存效率。
未知：是什么引发了这次激增。
未知：是否有协调行动者意图拒绝服务。
未知：流量是被伪造、反射、由受感染设备产生、由软件行为造成，还是多种来源叠加。
未知：涉及的名称、查询类型、速率和地理分布。

这种边界并非为了语义谨慎而设置。修复取决于机制。源地址验证可以约束伪造流量，但不能阻止合法客户端重试。速率限制可以抑制高流量，但可能拒绝有效解析。增加缓存容量有助于重复查询，但未必能应对以唯一名称或绕过缓存的查询组合为主的工作负载。更好的任播分布可以分散工作，同时也可能在边缘节点之间转移过载。

在没有证据的情况下将激增称为攻击，会让某一种解释看起来已经定论，并可能将责任导向外部。Microsoft 自己的说明无论初始流量是否恶意，都承认存在内部缺陷和缓解分类的缺口。即使最初的流量是恶意的，服务仍然必须处理这种受支持的失败模式：缓存效率降低，紧接着是合法重试，而其流量控制没有移除这些重试。

缓存缺陷改变每次查询的成本

在权威 DNS 中，缓存不仅是性能优化，它决定边缘节点为重复查询完成多少工作，以及多少负载会到达更深层的服务组件。

Microsoft 表示，DNS 边缘缓存效率的下降，是因为一个特定事件序列暴露了一个代码缺陷。[2][4][5] 这一表述具有信息量，但并不完整。它没有说明受影响的查询是错过了应答缓存、绕过了否定缓存、引发重复后端查找、在共享状态上发生争用、使条目失效，还是消耗了其他稀缺资源。它也没有说明是所有边缘节点都易受影响，还是只有通过特定任播路径到达的部分节点。

负责任的重建应当避免自行填充这些细节，但仍可以说明效率为何重要。

假设一个简化的边缘节点接收重复查询。在缓存命中率较高时，大部分答案都可以从已有状态中提供，每次查询的边际工作相对较低。如果某个缺陷将更多查询推向更慢的路径，每个请求就可能消耗更多 CPU 时间、内存、同步、网络工作或后端容量。延迟上升，客户端等待更久或收不到应答，于是重试。即使原始激增不再增长，重试流量也会推高到达速率。

这就是由 Microsoft 叙述所支持的核心反馈回路：

异常查询激增到达 Azure DNS。
特定序列暴露缓存效率缺陷。
更多请求需要更高成本的处理或等待更长时间。
DNS 服务可用性下降。
客户端重试未获应答的请求。
流量系统将这些重试视为合法流量。
重试流量给本已受损的服务增加更多负载。

这个回路不要求任何单个客户端行为不合理。一次重试单独看可能合理，系统性失败源于聚合行为，以及运营商无法安全地对这些工作进行分类或整形。

RFC 1034 和 RFC 1035 将缓存确立为 DNS 运行的基本组成部分。[17][18] RFC 2308 定义了否定缓存，使解析器不会无限制地反复询问同一个不存在的问题。[19] 后续标准如 RFC 8020 和 RFC 8198 描述了在特定条件下减少不必要否定查询流量的方法。[21][22] 这些文档都不能证明 Azure 的缺陷与否定应答相关，它们只是表明查询复用、缓存状态和重复未命中是公认的运行变量。

合法重试在总量上仍可能不安全

Microsoft 最重要的承认是：客户端重试被视为合法 DNS 流量，因此流量尖峰缓解系统没有将其丢弃。[2][4]

“合法”可以有多重含义。数据包可能有合理来源；查询可能符合协议；客户端可能被授权使用递归解析器；所请求的域可能存在。但这些都不能保证一个无界的聚合重试流对受损的权威服务是安全的。

RFC 4697 记录了可能给权威服务器带来过多查询负载的解析器行为，包括解析器过度激进重试、查询多个服务器或在更克制的响应本可降低负载时继续工作。[20] 该文档比 Azure 事件早很多年。其相关性不在于 Azure 必然违反了某个规定算法，而在于它确立了“解析器—权威边界上的重试放大”是一个已知的运行失败类别。

Azure 的记录留下了若干未回答的问题：

哪些客户端或递归实现进行了重试？
重试是否集中在 Microsoft 运营的服务组件、公共解析器、企业解析器或终端用户设备上？
什么响应或超时触发下一次尝试？
重试间隔是随机化还是同步的？
客户端是在不同任播地址之间切换，还是反复指向同一个到达的边缘节点？
缓存缺陷出现后，哪些查询类别产生了最高成本？
有效的重试能否通过名称、时序、来源网络或先前响应与初始激增区分开来？

缺少这些测量时，“过量重试”是一个有用的类别，但不是完整诊断。

缓解的挑战也是真实的。丢弃所有重试可能延长故障，并拒绝那些首个数据包只是丢失的客户端；允许每一次重试则可能持续过载。运营商需要一种有边界的准入机制：在限制消耗不成比例资源的模式的同时，保护足够多已知有效的工作以维持恢复。

Microsoft 表示，事件发生后立即更新了流量缓解逻辑，以保护 DNS 服务免受过量重试的影响。[2][4] 可核实的说明应当展示改变了什么信号，新规则如何区分无害重试与有害的聚合行为，运行了哪些误报测试，以及当控制阻断合法名称时运营商如何禁用或调整该控制。

权威服务与递归解析属于不同的控制域

用户的 DNS 查询跨越由不同方运营的系统。

设备上的存根解析器通常会向递归解析器发出请求。递归解析器可能从缓存中作答；如果没有可用答案，它会沿着委派路径向相关区域的权威服务器查询。RFC 1034 和 RFC 1035 定义了这些角色及它们之间的消息交换。[17][18]

Azure DNS 运营着受影响 Azure 托管域名的权威层，控制着服务的边缘实现、缓存行为、容量、流量整形和权威响应。递归解析器控制缓存状态、服务器选择、超时解释和重试行为。应用程序控制自身调用在名称解析失败后是否以及如何重试。接入网络和互联网路由则影响任播查询到达哪个 Azure 边缘节点。

因此，同一症状可能有不同原因：

解析器超时，可能是因为到达的权威边缘节点过载。
即使边缘节点健康，路径也可能丢包。
权威服务恢复后，解析器仍可能保留否定结果或耗尽的重试状态。
一个应用程序可能把一次解析器失败变成大量并行重试。
状态页面本身可能难以访问，因为其主机名依赖受损的层级。

RFC 8906 说明，从解析器的角度看，无响应的权威服务器可能与数据包丢失难以区分。[16] 这种模糊性既影响自动化行为，也影响事件沟通。解析器可能合理地尝试另一个权威地址，但许多解析器做出相同决定时，就可能转移或放大负载。

问责不应抹平这些角色。Azure 无法控制每个客户端算法；解析器运营方无法修复 Azure 的缓存代码；客户无法查看内部边缘遥测。但 Azure 确实控制着接收查询的服务边界，以及对重试流量进行分类的缓解逻辑。这赋予它首要责任，去证明权威服务能够在退化时，不会把有效的恢复行为变成持续过载。

任播分配查询，但并不能让每个边缘节点等价

当前的 Microsoft 文档称，Azure DNS 使用全球名称服务器网络和任播，将每个查询导向就近可用的 DNS 服务器。[7] Microsoft 的 Windows Server 任播指南解释了通用模式：多个位置宣告相同的服务地址，由路由选择路径。[9]

这些文档描述的是当前架构和通用实践，并不能证明 2021 年的确切拓扑、路由策略或撤销行为。这一时间边界应当明确。

RFC 9199 解释了为什么大型权威服务常用多台服务器、任播和负载均衡，同时也提醒不要假设存在一种通用部署模型。解析器位置、路由、对等互连和覆盖范围都会影响哪个实例接收流量。[14]

在查询激增期间，任播可以分散负载，也可能产生不均衡的体验：

某个覆盖区域可能接收到更大份额的目标工作负载；
路由变化可能同时把敌对和合法查询转移到另一个边缘节点；
一个节点虽然仍可达，但其应用层可能已经过载；
撤销可能保护一个站点，却把流量集中到别处；
不同网络中的递归解析器可能到达不同边缘节点，并报告不同的可用性。

Microsoft 的公开根本原因分析（RCA）没有披露缓存缺陷是否影响所有边缘节点、路由是否发生变化、“弹性 DNS 能力”是否意味着覆盖范围迁移，或者某些服务器是否比其他服务器具有更好的缓存效率。[1][2]

“将流量重新路由到我们的弹性 DNS 能力”这一表述出现在当时的状态报告中。[3] 它过于笼统，无法确定发生了什么变化。可信的技术说明应当把该表述与证据联系起来：

哪些路由或服务端点发生了变化；
哪些覆盖范围发生了迁移；
缓存状态是否随之迁移或预热；
每一步的应答率和超时率如何变化；
该变化是否减少了重试量；
哪些外部探测确认了恢复。

任播是基础设施，不是免罪符。其价值取决于实际工作负载下观测到的连续性。

提供过期数据是一种选项，不是必然的解决方案

当权威服务器无法应答时，递归解析器可能拥有一份先前有效响应的过期副本。RFC 8767 定义了在特定条件下提供过期数据以增强韧性的有界方法。[15]

该机制与连续性相关，但不应被当作事件中缺失的控制手段引入。公开来源没有说明哪些解析器持有过期答案、哪些记录足够稳定可供提供、响应是否已过期，或者是否启用了过期数据提供。

提供过期数据涉及权衡：

它可以在短暂的权威故障期间保持稳定的服务名称可达。
它可能保留运营商急需更改的地址。
它可能对部分用户掩盖权威服务持续受损的事实。
它对没有缓存答案的首次查询没有帮助。
它不能修复权威边缘节点或降低所有查询类别的负载。
其有效性取决于先前的缓存状态和配置限制。

否定缓存也有类似边界。RFC 2308 减少针对已知否定答案的重复查询；RFC 8020 允许解析器在已验证的 NXDOMAIN 分支之下停止查询；RFC 8198 允许主动使用经 DNSSEC 验证的否定记录来合成更多否定答案。[19][21][22]

这些机制可以减少不必要的上游工作，但并不能证明 Azure 的激增由随机不存在的名称组成，或暴露的缺陷涉及否定缓存。在不知道查询分布和 DNSSEC 状态的情况下，也不能安全地推荐这些机制。

基于证据的问题不是“为什么每个解析器都未能提供过期数据”，而是：

哪些受影响名称拥有可用的缓存答案？
多少重试流量来自冷缓存、正向、否定或过期缓存状态？
哪些韧性行为在降低权威工作量的同时，没有保留不安全的过期状态？
当解析器返回过期、失败或延迟答案时，应用程序表现如何？

这些测量能把一般性的标准讨论转化为针对特定事件的控制决策。

依赖集中让一次 DNS 故障看起来像许多服务故障

事件之所以在 Azure、Dynamics、Xbox Live 及其他 Microsoft 服务中可见，是因为名称解析位于多条服务路径之下。Microsoft 的问答公告点名了 Azure、Dynamics 和 Xbox Live。[1] Exoprise 转载了一条 Microsoft 365 通告，其中列出 Teams 和更广泛的依赖产品。[2] The Register 和 TechCrunch 独立描述了 Microsoft 各产品线上广泛出现的访问投诉。[3][6]

证据并未表明每个底层应用都发生了故障。用户无法解析服务名称，就会体验到服务不可用，即使计算、存储和应用程序进程仍然健康。这一区别对诊断和恢复都很重要。

DNS 是网络身份的一部分，它将用户和软件使用的名称映射到可达端点。即使应答该名称的服务不可用，记录本身仍可能被正确保存，但如果没有任何响应返回，用户就无法从正确记录中获得实际收益。

共享依赖引出若干问责问题：

公开状态、支持、管理和身份验证路径是否依赖同一权威 DNS 层？
内部响应人员能否访问诊断和沟通所需的工具？
哪些服务团队从 Microsoft 网络之外独立监控过 DNS？
哪些服务所有者知道自己的名称共享同一个边缘缓存实现？
受影响命名空间之外是否存在静态的应急通信路径？
服务恢复是否依赖解析器缓存在权威恢复后过期或刷新？

Exoprise 报告事件期间 Azure 状态页面访问困难，并称 Microsoft 引导用户改用备用状态界面。[2] 该报告应被视为一项独立观察，而不是所有状态端点都因同一原因失败的证据。它仍然暴露了一个治理问题：事件沟通渠道不应与它所报告的服务共享未经检查的依赖。

修复并不一定需要为每个名称引入第二个 DNS 提供商，而应始于准确的依赖图和独立观测。Microsoft 服务所有者需要知道哪些名称、权威路径、递归解析器和控制平面动作仍然共用。

监控检测到退化，但检测不等于遏制

Microsoft 表示，服务可用性下降触发了监控系统并让工程师介入。[2] Exoprise 称其外部监控在大约 21:20 发出告警，接近后来确定的 21:21 DNS 时间窗起点。[2]

这一时间关系表明检测并不是唯一的问题。服务在 22:00 自动恢复，但 Microsoft 承认持续时间超过了设计目标。于是相关问题变成：检测之后，运营商能做什么。

一个有效的检测系统至少应区分以下信号：

到达查询速率；
按查询类型的缓存命中与未命中率；
每个已应答或失败请求的成本；
队列深度和服务器饱和；
有效应答率；
来自外部解析器的超时与错误率；
重试量及重试来源分布；
任播覆盖范围变化；
各服务名称解析成功率。

聚合流量告警可能错过每次查询工作量的变化；缓存缺陷可能把熟悉的查询速率变成容量问题；可用性告警可能只有在用户已经失败之后才触发；流量检测器可能把重试分类为有效流量，而其聚合效应却阻碍恢复。

公开说明称，工程师准备了额外的服务容量，以及“如果进一步行动必要，可由流量缓解系统应答 DNS 查询”的能力。[2] 但它没有说明在自动恢复前是否实际执行了其中任何一步，什么阈值会触发这些步骤，或者额外容量是否本可打破反馈回路。

这是一种控制上的区分：

检测回答的是“是否出了问题”。
诊断确定机制。
遏制限制有害反馈。
恢复恢复有效解析。
验证显示外部用户和依赖服务已经恢复。

快速告警不能成为遏制不力的借口，自动恢复也不能证明服务可以可靠地从更长或重复的激增中恢复。

恢复超过了设计目标

Microsoft 承认恢复时间超过设计目标，这一说法特别有用，因为它揭示了一个内部标准，却没有披露具体数值目标。[2][5]

这一说法引出四个问题。

第一，设计目标衡量的是什么？它可能指权威应答可用性、自动恢复时间、人工干预时间或端到端服务恢复时间，而这些并非可互换。

第二，预期由哪个机制实现目标？负载下降时缓存可能恢复；任播站点可能撤销；容量可能增加；缓解规则可能改变。如果没有控制责任人和触发条件，“设计目标”就仍然只是愿望。

第三，该目标是否针对组合故障进行过测试？常规负载测试可能在健康缓存效率下测量查询容量；缓存测试可能没有包括同步重试；流量缓解测试可能模拟恶意数据包，却允许合法重试无限制通过。2021 年的事件把这些条件叠加在了一起。

第四，如何验证修复？Microsoft 列出了“修复代码缺陷，使请求能在缓存中被高效处理”和“改进自动检测与异常流量缓解”。[2][4] 工作清单本身不是修复完成的证据。

恰当的收尾应当把每项措施与测试绑定：

措施	所需证据
缓存缺陷修复	针对触发序列的复现测试、修复前后缓存效率、代码和部署标识
重试保护	受控重试工作负载、合法应答保留、误报率、回滚阈值
异常检测	各类查询的检测延迟、敏感性和误报证据
边缘容量	缓存效率降低情况下每个边缘节点的饱和余量
自动恢复	反复故障注入运行及恢复时间分布
服务恢复	跨解析器网络对代表性 Microsoft 和客户名称的外部探测

没有这些证据，读者能知道 Microsoft 打算改进什么，却不知道消除了多少风险。

SLA 不能替代事件证据

Azure 为 DNS 区域发布了 SLA。当前文档定义了服务可用性以及在特定合同条件下可能提供的服务积分。[13] 它有助于识别当前的法律和商业边界。

但它不能确定 2021 年适用哪些合同、某个客户是否满足索赔条件、所测停机时间是否超过阈值、或 Microsoft 是否负有法律责任。本资料包中的公开来源没有包含任何客户特定索赔、监管决定或法院裁决。

SLA 的衡量对象也可能比客户损害更窄。DNS 可用性计算可能没有涵盖应用恢复延迟、状态页面访问、运维人力，或因解析器无法获得答案而丢失的交易。反过来，客户报告服务困难也不自动证明 SLA 被违反。

因此，问责记录应把三本账分开：

技术可用性：权威和递归系统返回了什么。
客户影响：哪些功能失败、影响哪些人、持续多久。
合同救济：适用哪些条款、测量和索赔程序。

混为一谈要么夸大责任，要么淡化损害。因此，各自界限比选择单一指标作为整个事件更关键。

客户控制架构，但不控制 Azure 的缺陷

当前 Azure 可靠性指南描述了提供商与客户的责任。Azure 运营 DNS 平台，客户配置区域、记录、委派及部分韧性选择。[8][12]

客户可以采取有用步骤：

从 Azure 之外的解析器和网络监控关键名称；
盘点哪些控制面和用户路径依赖 Azure 托管区域；
有意识地选择 TTL；
测试解析失败时应用程序的行为；
保留应急访问和沟通路径；
对值得承担复杂性的系统评估权威提供商多样性；
如果使用 DNSSEC 和委派操作，理解其运作。

这些控制并不会把 Azure 缓存缺陷的责任转移给客户。客户无法查看边缘实现、改变流量分类或增加提供商容量，也不应被告知某一种架构普遍正确。

多提供商权威 DNS 可以减少一种常见模式，但会增加区域同步、委派、DNSSEC、访问控制和故障转移风险。RFC 9199 强调情境而非规定单一设计。[14] 一个与现有提供商共享路由、注册局访问、自动化或运维人员的第二提供商，可能在关键维度上并不独立。

客户的相关决策应当是文档化的风险接受：

服务必须承受哪些名称解析失败？
哪些故障域真正相互独立？
委派或提供商状态变化能多快完成？
故障转移可能制造哪些过期或冲突状态？
谁有权执行和撤回变更？
什么测试能证明路径在真实用户网络中有效？

客户韧性是一层防御，不是基础设施运营商不衡量自身缺陷和缓解行为的借口。

责任随控制权与证据访问能力而定

公开记录支持基于控制权分配责任。

Azure DNS 工程团队

Azure DNS 工程团队控制权威服务、缓存实现、边缘部署、流量整形、流量缓解逻辑和恢复自动化。它拥有查询分布、缓存指标和服务器状态的最佳访问权。其职责不是阻止每一次查询激增，而是设计和测试退化行为，使单个缓存缺陷不会让合法重试维持过载，并保留记录以显示发生了什么。

Microsoft 事件管理

事件管理控制升级、协调和公开沟通。调查期间，初步“流量尖峰”更新与后续缓存缺陷说明出现差异是合理的，但记录应当显示发生了什么变化。它应保留按时间戳排列的假设、证据和纠正措施序列，而不是把最终叙述表现得像一开始就已明了。

Microsoft 服务所有者

运行 Azure、Dynamics、Xbox Live、Microsoft 365 及相关控制面的团队控制着依赖设计和外部监控。他们没有控制 DNS 缺陷，但可以识别关键名称、状态页面和恢复工具是否共享同一条权威路径。

递归解析器与客户端运营方

解析器和客户端开发人员控制重试间隔、缓存行为和故障处理。RFC 4697 说明重试纪律是一项早已被公认的共同责任。[20] 记录没有指明哪些实现产生了最多流量，因此不应指控任何特定运营商。完整的复盘应当提供聚合分布，让整个生态能够修复有害模式。

客户

客户控制着部分区域、TTL、监控和提供商多样性选择。其责任取决于服务的关键程度、可用的合同选项以及独立 DNS 的可行性。客户不具备修复 Azure 边缘缓存或缓解分类器所需的信息或权限。

这种分配是不对称的，因为控制权和证据也是不对称的。Azure 掌握着核心运行证据和改变故障服务的手段。

反事实分析显示哪些控制更重要

反事实分析有助于区分触发因素、促成条件和修复。

如果异常激增发生，但没有缓存缺陷

Microsoft 表示正常缓存和流量整形本可缓解激增。[2][4] 如果这一说法正确，服务本应保持更高的缓存效率和更低的每次查询工作量。这使缺陷成为促成条件或根因候选，而不仅仅是背景缺陷。

如果缓存缺陷出现，但没有激增

服务可能有足够剩余容量吸收效率下降，这会让激增成为触发条件。公开记录没有揭示余量，因此将交互关系作为更可辩护的结论，优于将单一因素定性为全部根因。

如果一开始就有界重试

反馈回路可能被削弱，但过宽的重试过滤也可能拒绝合法恢复流量。正确的控制需要保留代表性有效请求，并证明较低的误报率。

如果每个解析器都提供过期答案

部分稳定名称可能保持可达，但冷缓存用户和已变更记录仍会失败。普遍提供过期数据还可能保存不安全状态。这不是完整的反事实修复。

如果客户使用两个权威提供商

部分名称可能保留独立路径，前提是委派、区域数据、DNSSEC 和健康策略协调一致。其他共享依赖或解析器行为仍可能失败。多样性是可通过测试验证的架构，不是口号。

如果具备更多边缘容量

容量可以推迟饱和，但不一定消除缓存缺陷或对重试进行分类。具有相同反馈回路的更大系统可能更晚、在更大规模上失败。

这些反事实支持一个分层结论：初始激增触发了事件；缓存缺陷增加了每次查询的工作；重试行为放大了负载；缓解分类未能打破回路；依赖集中传播了影响；恢复控制所用时间超过了提供商的设计目标。

公开证据仍无法证明的事项

来源勾勒出有用的轮廓，但决定性的内部记录仍然缺失。

它们无法证明：

初始查询激增的来源、意图或归属；
激增是否是协同攻击；
查询量、数据包速率或查询类型分布；
受攻击的域名和记录；
发生故障的缓存实现或代码路径；
事件前、中、后的缓存命中率；
受影响的 DNS 边缘节点数量或位置；
路由或任播覆盖范围变化；
哪些递归解析器或客户端产生了重试；
重试间隔、同步或放大系数；
修复前后的确切流量缓解规则；
按服务和按区域的影响；
客户损失、SLA 积分或法律责任；
修复完成日期及独立验证；
此后是否测试过相同的触发序列。

当前 Microsoft 文档无法填补这些历史空白。它们描述的是今天的服务和推荐实践。[7]-[13] RFC 定义协议行为和运行选项。[14]-[22] 独立报道保存了声明和症状，但不拥有 Azure 的内部遥测。[2]-[6]

公开细节的缺失并不证明隐瞒或疏忽，但限制了对因果或法律结论的信心。最强的结论是：Microsoft 自己的说明承认了一项内部缓存缺陷、一个合法重试反馈回路和一处缓解缺口。在 Microsoft 所控制服务之外的精确责任分布仍部分未知。

修复应当作为可审计的序列

可验证的修复计划应当保留一个共同的事件测试，而不是一系列彼此脱节的改进。

复现

创建一个与相关查询和缓存状态序列匹配的安全工作负载。记录软件版本、区域形状、记录类型、缓存状态和边缘拓扑。证明修复前系统确实表现出效率下降。

测量

捕获缓存命中与未命中率、每次查询成本、响应延迟、超时率、队列深度、边缘饱和和重试量。在证据允许的情况下，将初始流量与重试分开。

遏制

应用有界重试整形和异常流量控制。测试已知有效名称、冷缓存和热缓存状态、否定应答、DNSSEC 响应及多种解析器行为。测量误报。

恢复

证明权威可用性在设计目标内恢复，而不只是等待外部流量下降。在独立网络上确认任播和路由行为。

验证依赖服务

从多个递归解析器和接入网络探测代表性 Azure、Microsoft 控制面和客户名称。区分 DNS 恢复与应用恢复。

回滚

展示应急控制有责任人、到期条件和可逆配置。长期保留的缓解措施本身可能成为新的拒绝来源。

保留证据

将测试结果绑定到代码、部署和配置标识。发布有边界的摘要，提供足够测量以表明该特定反馈回路已被移除，同时不暴露敏感基础设施细节。

这一序列回答的核心问题是：不是 Microsoft 是否增加了“更多韧性”，而是相同的缓存—重试交互是否仍可能越过故障阈值。

结论

2021 年 4 月 Azure DNS 故障并非仅凭流量规模就能解释。

Microsoft 表示，一次异常查询激增暴露了一个代码缺陷，降低了 DNS 边缘缓存效率。服务退化使客户端重试；这些重试属于合法流量，因此流量缓解最初没有将其丢弃。服务最终自动恢复，但没有在设计目标内完成。Microsoft 随后调整了重试保护，并表示将修复缓存缺陷并改进异常检测。[2][4][5]

这一序列揭示了一个多层次的网络基础设施问责问题：

激增是 Microsoft 描述的触发因素，但不是已证实的攻击归因。
缓存缺陷是增加工作量的内部促成条件。
合法重试行为在解析器—权威边界上放大了负载。
缓解逻辑最初未能遏制这种聚合后的有效流量。
共享 DNS 依赖让一次解析失败表现为许多明显的服务故障。
恢复指标并没有清晰地映射到每个用户的体验。

负责任的结论不是说 DNS 重试不好、任播失败或客户应始终使用第二提供商。这些主张都超出了证据。

更强的标准是可测量的退化行为。权威 DNS 运营商应当知道异常查询序列下缓存效率如何变化、合法重试如何影响容量、哪些缓解保护有效答案、任播覆盖范围如何响应，以及哪些外部探测能证明恢复。解析器和客户端运营方应当限制重试和缓存行为。服务所有者应当识别关键命名依赖并保留独立的事件沟通渠道。客户应当测试他们真正能够控制的连续性决策。

记录、服务描述和状态通知是证据的一部分，但它们不是正在运行的服务。2021 年 4 月 1 日，名称仍可能保持正确配置，用户却无法可靠解析。问责就从这两种状态出现分歧的地方开始。

最终证明是绑定到实际修复的可重复测试：重现序列，测量缓存效率，诱导有界重试，激活缓解，保留已知有效答案，在设计目标内恢复，并从独立网络确认结果。没有这些证据，公众得到的只是一个看似合理的叙述；有了这些证据，运营商才能表明反馈回路已经闭合。

摘要