2002 年根 DNS 攻击使分布式服务韧性成为问责考验

摘要

2002 年 10 月 21 日，一次分布式拒绝服务攻击严重恶化了通往 DNS 根服务器系统的重要路径。CAIDA 从指定监测位置观察到往返时间突然变化，持续时间因逻辑根标识而异。[1]
ICANN 后来描述 13 个逻辑根服务器地址中有 9 个被“淹没”。这一有出处的表述是攻击广度的证据，并不能证明全球有九个完整服务消失，也不能证明每个解析器和用户都失败。[5]
CAIDA 得出结论，对全球网络运行的可见影响轻微。递归缓存、重试行为和多个逻辑根标识有助于将严重的服务器与路径压力同普遍的事务失败区分开来。[1][20][21]
CAIDA 的数据包分析覆盖了事件开始后不久以十分钟为间隔的 E、I、K、M 根链路。这些观察是受监测链路的直接证据，而不是对每个根实例、解析器、路由或应用的全面普查。[2][3]
RFC 2870 和 RFC 3258 表明，容量、多样化连接、日志记录、协作和分布式权威服务在攻击前已是公认的控制措施。但它们不能证明每个运营商在攻击当天都已部署了所有控制措施。[8][9]
后来的任播、RSSAC、SSAC 以及大型权威服务指南提供了修复和测量标准。它们是后来的对照材料，既不是追溯性的法律义务，也不能证明 2002 年的确切拓扑。[6][10]-[16]
责任分布在根服务器运营商、传输与接入网络、解析器运营商以及协调机构之间。没有任何单一机构控制每一台服务器、每条路由、每个缓存、每项过滤或每笔用户事务。
问责标准是运营性的：记录标明了权威，而可达的路由、正确的应答、解析器的连续性、有边界的缓解以及多观测点的恢复证据共同证明服务的连续性。

权威记录并非服务保障

根提示条目可以告诉递归解析器应在哪里找到 DNS 根服务器。根区记录可以标明对某委派负责的权威机构。但这两类记录都无法让数据包穿越拥塞的路由、迫使权威实例应答、在洪流下保留容量，或证明用户的某笔事务已完成。

这一区别在 2002 年 10 月 21 日具有了运营意义；当天，一次分布式拒绝服务攻击向 DNS 根服务器系统的逻辑地址发送了大量流量。该事件常被压缩成一个耸动的服务器数量。ICANN 后来描述 13 个逻辑根服务器地址中有 9 个被“淹没”。这一表述很重要，但并不能完整说明服务可用性。它既不能证明九个完整服务在所有位置都消失，不能证明每个递归解析器都需要在同一时刻访问根，也不能证明用户经历了普遍故障。[5]

因此，问责问题比仅仅询问某个地址是否遭到攻击更为严格。它要求区分几个容易被混为一谈的层面：到达服务器链路的流量、从特定网络路径可见的响应、缓存状态不同的递归解析器的行为，以及已完成用户事务的成功或失败。每个层面都有自己的运营商、证据和故障边界。

权威记录之所以重要，是因为它们确定了解析器应使用哪些服务标识。它们是委派和权威的重要台账。但台账并非正在运行的系统。运营连续性取决于能够正确应答的权威实例、保持可达的路由、足够的容量、跨故障域的分布、有效使用缓存信息的解析器、在可能范围内限制有害流量的网络，以及能够协调缓解和恢复的运营商。

若从事件中移除根 DNS 可达性，就不存在服务连续性问题。若移除解析器缓存，服务器压力就很容易被误认为同等的用户损害。若移除权威服务分布，就无法评估韧性设计。若移除路由多样性，分析就会忽略需求如何到达正常容量。若移除源地址过滤，流量源头边缘的责任就会消失。若移除测量观测点，局部观察就会变成没有根据的全局主张。若移除运营商协调，就无法可信地说明分布式服务如何检测、缓解并宣布恢复。

2002 年的攻击使这些依赖关系变得可见。它并没有表明某个机构拥有排他性控制权。它表明用户所体验的服务由记录、运行中的代码、路由、缓存和自主运营决策组合而成。问责必须跟随这些实际控制措施以及每个控制者能够提供的证据。

2002 年 10 月 21 日观察到什么

CAIDA 当时发布的测量记录报告了大约在 UTC 时间 22:00 出现的往返时间突然恶化。从 UCSD 观测点来看，除 I 和 M 外，所有受监测的根都出现了性能变化，但持续时间并不一致。CAIDA 报告 F、G、L 的影响持续约一小时，A、B 约为五到十分钟，J 略超过十分钟。[1]

这些观察为严重事件提供了证据，但并未提供来自每个网络的根服务普遍图景。测量依赖于圣迭戈和圣何塞的监测点，因此描述的是从特定位置经特定路径可见的服务。一个监测点响应不佳的根地址，对使用另一上游、路由或地理路径的解析器而言，可能会呈现不同的状况。反过来，从测量站点看似有响应的根，从另一网络可能仍然难以到达。

这一局限并非 CAIDA 独有。它是分布式服务测量的基本属性。监测器记录的是其路径允许其看到的内容。只有同时说明位置、指标、时间间隔和目标，其结果才具有广泛意义。

CAIDA 还得出结论，对全球网络运行的可见影响轻微。[1] 这一发现限制了任何对攻击的复述。它排除了将严重流量和根服务器性能变化自动视为普遍用户失败的证明。它还需要一种解释：DNS 架构在权威根地址和单笔事务之间包含缓冲，最显著的是递归缓存和多个根服务标识的可用性。

D 根的运营商历史独立地将 2002 年 10 月 21 日确定为大规模攻击日期，并指出运营商随后编写了对事件的分析。[4] 该记录证实了日期以及对该事件的运营确认。它本身并不能证明每个根标识或每个物理实例都存在相同状况。

CAIDA 后来的数据包分析提供了另一种有边界的视角。它检查了攻击开始后不久从服务 E、I、K、M 根的链路收集的流量，并将观察结果按十分钟间隔分组。其请求和观察到的客户端分布是对这些链路的直接测量。[2] 更广泛的 CAIDA 根流量工作说明了这些观察所在的数据集和方法论。[3]

E、I、K、M 链路数据不能被当作对每个根标识、物理实例、解析器、接入网络或应用的普查。它是在攻击开始后采集的，覆盖指定的链路，并使用定义的观察间隔。它之所以有价值，正是因为它有可知的边界。正确使用这些证据的方式是说明受监测链路上何时出现了什么，而不是将这些样本变成对整个系统没有根据的总量。

因此，三种来源各自的描述可以无矛盾地并存：

CAIDA 从其监测位置观察到路径性能变化，其持续时间因根标识而异。[1]
CAIDA 后来分析了 E、I、K、M 选定链路上的数据包和明显客户端，间隔为十分钟。[2]
ICANN 2007 年的比较描述 2002 年攻击期间 13 个逻辑根服务器地址中有 9 个被淹没。[5]

它们观察的是不同对象。一个涉及测量到的路径性能，另一个涉及选定链路上的数据包，第三个是围绕逻辑地址的后来机构性总结。负责任的分析会保留这些区别。

为什么“13 个中的 9 个”只是调查的起点

数字 13 指的是逻辑根服务器标识。逻辑标识并不必然等同于一台机器、一个站点或一条路由。它的运营实现取决于负责的运营商如何部署权威容量并通告服务地址。

即使 2002 年的物理和拓扑分布不如根系统后来部署得广泛，这一点依然成立。现有的公开证据没有逐一列出攻击当天每个物理实例、活动路由或本地缓解安排。因此，它无法支持对哪些硬件或站点同时从互联网各处可达做出精确重建。

ICANN 的表述应保留其有出处的形式：13 个逻辑根服务器地址中有 9 个被描述为“被淹没”。[5] “被淹没”传达的是攻击压垮了重要服务路径或容量。它并不定义一个普遍中断边界。它并没有说与每个地址相关的所有权威容量都在所有地方失败。它也没有揭示每个解析器的重试决策或缓存状态，更没有统计已完成的事务。

只统计服务器地址至少忽略了四个维度。

第一，它忽略了观测点。可达性是相对的：解析器通过特定网络中的特定路由到达一个地址。在加利福尼亚观察到的响应失败是关于该路径和时间的证据，而不是来自欧洲、非洲、亚洲或另一北美网络的直接观察。

第二，它忽略了时间。CAIDA 报告的各个性能变化持续时间并不都相同。[1] 没有时间间隔的计数可能将一个地址的短暂恶化与另一个地址的较长时间状况合并，使它们看起来在运营上相同。

第三，它忽略了服务分布。当采用分布式寻址设计时，一个逻辑标识可以由多个服务位置代表。必须证明讨论的日期和标识下存在何种分布、范围和行为，而不能从后来的拓扑推断。

第四，它忽略了解析器层面。递归解析器可能使用尚未过期的有效缓存委派来回答，而不需要为每个用户请求向根发送查询。另一个解析器可能需要新信息、重试不同的根标识，或遇到不同路径。服务器地址标题无法解决这些差异。

因此，这一计数是攻击严重性的证据，而不是衡量用户损害的充分依据。正确的问题不是是否应淡化这个数字，而是这个数字测量了什么、忽略了什么，还需要哪些额外证据才能将其转化为服务结论。

这种区分保护而非削弱问责。如果把每个过载地址都随意等同于普遍的服务消失，运营商就无法判断哪些控制真正遏制了损害。缓存、备用权威容量、路由多样性和协调都会变得不可见。如果因为许多事务仍成功而轻视该计数，又会低估攻击对关键基础设施的压力。可靠的说明必须同时抓住两个事实：攻击严重恶化了重要的根服务路径，但现有证据无法证明普遍故障。

解析器缓存将基础设施压力与用户损害区分开来

DNS 解析过程并不要求每个用户查询都到达根服务器。递归解析器会在允许的缓存生存期内保留 DNS 信息。当解析器已经持有继续解析所需的委派信息时，它可以在该事务中直接使用尚未过期的信息，而无需联系根服务器。[20], [21]

因此，缓存改变了针对权威基础设施的攻击与用户可见体验之间的关系。它创造了一种临时服务缓冲。这种缓冲既不是无限的，也不是均匀的。

两个解析器可能遭遇同样的攻击，却经历不同的结果，因为它们的缓存中包含不同的记录，剩余生存期也不同。一个解析器可能已拥有热门域名所需的委派信息。另一个可能需要就未缓存或缓存副本已过期的信息向根查询。它们的上游路由也可能不同。即使它们联系同一个逻辑根地址，也可能观察到不同的响应状况。

这解释了为什么针对根服务器地址的严重攻击不一定会导致各应用出现同等严重且同时发生的故障。这也解释了为什么仅凭服务器遥测无法回答用户影响的问题。根运营商可以证明流量激增或实例响应恶化。这一证据至关重要，但它不能说明在间隔期内哪些递归解析器需要受影响的服务，也不能说明哪些用户事务失败了。

反向推断同样不安全。即时用户可见损害有限，并不意味着基础设施事件无关紧要。缓存数据会老化。权威服务长期不可达，会逐渐暴露那些需要本地已无可用信息的解析器。该架构可以吸收冲击，但不会使冲击变得无关紧要。

缓存之所以属于问责图谱，是因为递归解析器运营商控制着这一缓冲的重要方面。它们管理缓存行为、重试、根提示和面向用户的监测。它们的证据可以表明解析器是否继续应答、是否在不同根标识之间转移查询、是否遇到超时，或是否耗尽了有用的缓存信息。没有解析器侧数据，评估就会停留在服务器困境和零散用户体验之间。

根服务器系统和递归解析器群体也运行在不同的时钟上。根实例可能立即遭遇流量飙升。监测器可能在数秒或数分钟后观察到往返时间增加。解析器所受影响取决于缓存状态和重试行为。用户事务还会叠加应用特有的计时和容忍度。把这些时钟合并成“DNS 宕机了”这样一句话，会抹去因果链条。

CAIDA 报告的有边界结论——对全球网络运行的可见影响轻微——正符合这种分层模型。[1] 它不应被泛化为什么用户都没有受到影响的说法，因为并不存在精确的用户级失败率。它也不应被丢弃，以换取一个耸动的地址计数。它是证据，表明更广泛的系统（包括缓存和剩余的可达权威服务）在巨大压力下仍然提供了大量服务。

因此，问责既需要压力证据，也需要连续性证据。前者显示基础设施何处承压。后者显示解析器和事务是否继续获得及时、正确的答案。两者不能互相替代。

分布式运营改变了韧性的归属

DNS 根服务器系统不仅在拓扑上是分布式的，在运营权限上也是分布式的。各根服务器运营商控制自己的实例、容量规划、上游连接、本地过滤、监测和事件响应。传输与接入网络控制路径的其他部分。递归解析器运营商控制缓存和重试。协调与咨询机构连接这些领域，但并不能抹去它们的自主性。

这意味着责任不能被简化为与根区相关的组织，或后来发布情况说明的机构。ICANN、IANA 职能和与 RSSAC 相关的结构具有根区、协调和咨询角色。它们并不构成在 2002 年攻击中运营每个根实例的单一指挥系统。

记录保管者与运营商之间的区别至关重要。根区和根提示记录标明哪些逻辑服务持有权威。这些记录的准确性不可或缺：错误的权威信息会把解析器引向错误的服务。但正确的记录并不能确保路由可用、实例有容量，或上游网络会过滤有害流量。

运营连续性由控制这些层面的各方共同创造。根运营商可以增加容量、分布服务、多样化上游并收集实例遥测。传输提供商可以在其域内配置路径、管理拥塞并实施源地址有效性控制。接入网络可以限制离开客户网络的不合理源流量。解析器运营商可以维持可靠的缓存和重试行为。协调机构可以建立共同的预期和证据格式。没有任何一个角色能替代所有其他角色。

这种分布阻止了对排他性责任的简单分配，但并未消除问责。相反，它使问责更加精确。每个运营商都应根据其实际拥有的控制措施、当时可用的证据，以及在不攫取他方权力的前提下能够合理采取的行动来接受评估。

对根运营商而言，相关问题包括：合法查询是否能够到达可用的权威容量；连接是否足够多样以避免单一路径瓶颈；监测能否区分实例问题与更广泛的路由问题；能否从运营商自身网络之外证明恢复。

对传输与接入网络而言，问题涉及路径容量、路由行为和网络边缘的控制。根运营商无法直接验证每个始发接入网络上的源地址。接入提供商也无法规定每个根服务如何分配容量。它们的职责不同，因为它们的控制措施不同。

对解析器运营商而言，问题涉及对用户的持续服务、缓存行为、重试结果，以及区分上游根困境与本地解析器或接入故障的能力。

对协调机构而言，问责关乎共同预期、信息交换、事件分析和可比较指标的质量——而不是对每个独立运营服务发布即时命令的虚构权力。

用户处于最弱势的位置。他们可以观察到缓慢或失败的事务，但通常无法检查根链路负载、路由变化、缓存内容或运营商协调。把举证责任压给用户会颠倒控制结构。证据应来自拥有相关遥测数据的运营商。

因此，分布式责任既不是中央集权，也不是运营模糊。它是一张控制图谱。这张图谱让我们可以追问：谁能观察到某种状况，谁能改变它，谁依赖另一方，以及哪些证据应该留存以供日后审查。

容量和多样性在攻击前已是公认的控制措施

2002 年的事件并非发生在概念真空之中。在攻击前发布的 RFC 2870 列出了根名称服务器的运营要求。它涉及符合标准的服务、高于实测峰值需求的容量、多样化连接、仅权威运营、日志记录以及安全分析中的合作。[8]

这些期望与攻击直接相关，因为它们指明了使权威基础设施更具韧性的控制类型。容量余量可以在一定程度上吸收异常需求。多样化连接可以减少对单一提供商或路径的依赖。仅权威运营缩小了服务角色。日志记录和协作分析支持检测和重建。

然而，该文档不能证明每个运营商在 2002 年 10 月 21 日的部署状态。RFC 中的运营要求并不是证据，不能表明每个根标识都实现了相同的架构、拥有相同的容量或记录了相同的遥测。它也不构成法律义务、过失或违约。这些结论需要此处技术记录之外的证据。

RFC 2870 最好用作事件前的背景。它表明容量、连接多样性、日志记录和协作已被理解为重要的运营控制措施。[8] 它允许对这些方面展开问责调查，而无需假装后来的架构当时已经普遍存在。但它本身无法回答这一调查。

2002 年 4 月发布的 RFC 3258 描述了使用共享单播地址来分布权威名称服务。[9] 该设计允许从多个位置通告同一服务地址，由路由决定哪个位置接收查询。它也引入了自身的运营边界：位置很重要，路由行为很重要，权威数据必须在分布式服务中保持一致。

时间点很重要，但必须谨慎处理。RFC 3258 表明通过路由实现分布式权威服务在 10 月攻击前已有文档记录。它并不表明每个根标识都已部署该技术、所有部署都相同，也不表明根系统当时已具备后来的任播覆盖。

容量和分布解决的是不同问题。在单一位置增加容量可能承受更大的本地洪流，但仍依赖于服务该位置的路由和上游链路。更多位置可以分散需求并减少共同故障，但只有当路由把合法查询导向可达容量且实例提供一致答案时，分布才有用。没有足够服务容量的路由多样性只会暴露更多过载路径。没有路由多样性的服务容量可能仍然不可达。

因此，攻击考验的是一条链条，而不是单一控制项：

权威记录必须标明正确的逻辑服务。
路由必须把查询送到可运营的实例。
路径和实例必须有足够的可用容量。
分布式实例必须返回一致的权威答案。
解析器行为必须有效利用可用服务。
监测必须揭示链条上哪一环受损。
当受损环节跨越组织边界时，运营商必须协调。

每一环都有证据要求。配置文件可以证明预期的权威。路由观察可以显示通告的可达性。实例遥测可以显示负载和响应行为。解析器测量可以显示实际解析。事务测试可以显示面向用户的完成情况。可信的事后说明不应把其中一类证据当作所有其他类的替代。

共享单播与重写攻击当天拓扑的危险

后来的韧性改进可能使早期系统看起来比实际更简单。根服务器系统随后通过任播进行的扩展尤其容易造成这种扭曲。

RFC 4786 后来定义了任播运营模型，即同一服务地址从多个分散位置通告。[10] RFC 7094 进一步提出了关于任播分布的架构考虑，包括拓扑、路由和服务行为之间的关系。[11] RFC 7720 后来描述了根名称服务的协议和部署要求。[12]

这些出版物提供了有用的对照标准。它们解释了为什么逻辑服务地址不应被自动解释为一台物理机器，以及为什么路由是服务交付的一部分。它们还有助于识别运营风险：位置可能不均衡，路由可能转移需求，站点可能具有不同容量，分布式实例需要一致的服务行为。

但它们不是把后来的部署向后投射的许可。证据既不支持 2002 年 10 月 21 日已普遍存在根任播的说法，也不支持逐标识给出攻击当天分布的完整图谱。RFC 3258 在事件前的发布表明共享单播分布是一项已有文档记录的技术。[9] 但它并不表明普遍实施。

ICANN 2007 年的情况说明将后来的根攻击与 2002 年事件进行比较，并把后来攻击用户影响较低部分归因于任播部署和 2002 年后改进的运营商协调。[5] 该比较支持以下结论：分布和协调成为更重要的韧性控制。但它并不把后来的控制变成追溯性义务，也不证明某项补救措施独自解释了两个事件之间的所有差异。

负责任的比较是因果性的，也是有限的。分布式服务可以使针对一个逻辑地址的洪流更难耗尽所有相关容量，因为路由可能把流量分送到多个位置。路由和上游多样性可以隔离某些故障。更多观测点可以揭示区域差异。协调可以帮助运营商交换攻击指标并保护合法流量。

但任播不是咒语。同一地址出现在多个站点，并不保证相同的可达性、均衡负载、独立上游或充足容量。路由策略决定流量去向。位置糟糕或供给不足的站点仍会受损。路由变化可能重定向需求。把所有实例聚成一个逻辑标签的监测可能掩盖局部困境。

因此，分布的问责价值在于可证明的结果。运营商应能显示哪些实例为一个地址提供服务、哪些路由暴露了它们、流量如何转移、合法响应是否保持及时正确，以及故障是否被控制在局部。仅有任播标签是不够的。

这使分析回到运行中的服务。根提示中列出的逻辑地址标明服务应在哪里可用。分布式部署创造了更多实现该标识的方式。只有测量才能显示在攻击期间从不同网络看，这一实现是否奏效。

测量必须标明时间、层面和观测点

2002 年的证据表明，基础设施问责需要严谨的测量语言。关于“根”的陈述至少可能指向五个不同对象：

测量层面	能单独确定什么	不能单独确定什么
链路与数据包负载	定义间隔内受监测链路上可见的流量量和明显客户端	每条根链路的状况或用户事务是否成功
路径性能	从指定监测器到逻辑地址的可达性或响应恶化	每个解析器或区域的可达性
权威服务	被观察实例是否返回及时、正确的 DNS 答案	下游解析器的缓存状态和行为
递归解析器	解析是否通过缓存、重试和可用根得以继续	每个应用或用户经历的状况
已完成事务	特定面向用户的操作是否从定义网络成功完成	每个底层 DNS 组件的全球健康状况

CAIDA 的事件记录主要位于路径性能层面。它报告了 UTC 时间 22:00 左右往返时间的变化，以及受监测根之间不同的表观持续时间。[1] 这些测量在被表述为来自所述站点的观察时是强有力的证据。如果把它们转化为全球可用性主张，就会变弱。

后来的 E、I、K、M 分析位于链路与数据包层面。其十分钟分组提供了时钟，受监测链路提供了范围。[2] 数据集背景解释了这些根流量观察是如何汇总的。[3] 该分析可以刻画这些链路看到的内容。它无法确定每个物理来源、每条路由或每个解析器结果。

ICANN 的“13 个中的 9 个”叙述是逻辑地址层面的总结。[5] 它捕捉到了指定服务承受压力的广度，但不能替代路径、实例、解析器或事务证据。

因此，可信的事件重建应为每个重要陈述附上四个限定条件：

对象：观察关乎逻辑地址、物理或拓扑实例、链路、路由、解析器还是事务？
观测点：从哪个网络或监测位置观察？
指标：证据是流量量、往返时间、响应率、正确性、超时行为还是已完成解析？
间隔：状况何时开始，持续时间如何测量，恢复何时得到确认？

没有这些限定条件，不同的测量就可能看起来相互矛盾，而实际上它们描述的是不同层面。根链路可能严重过载，而解析器仍从缓存继续应答。监测器可能看到一条路由的响应恶化，而另一条路由仍可用。一笔事务可能成功，即使一次权威查询超时，重试到达了另一个服务标识。

后来的 RSSAC 出版物为使根服务预期和测量更一致提供了对照标准。RSSAC 的服务预期工作从所交付服务的角度框定根服务器系统，而其通用测量框架寻求跨运营商的可比较证据。[13], [14] RFC 9199 同样为大型权威 DNS 服务器系统提供了后来的运营考量。[16]

这些后来的文档不应被描述为 2002 年约束每个运营商的义务。它们的价值是回顾性和前瞻性的：它们展示可以如何组织证据，以便未来事件更容易宣告、比较和结束。

测量问责同样适用于恢复。运营商内部曲线恢复正常很有用，但如果外部解析器仍无法获得答案，那就还不够。一个监测器恢复并不能证明处处恢复。解析器成功一次并不能证明持续稳定。恢复应由多个层面支持：实例健康、路由可达性、权威正确性、解析器成功，以及地理或拓扑上多样化的外部观察。

目标不是不可能的全球普查。分布式系统很少提供这种普查。目标是有边界的证据，其范围足够明确，使决策者能够判断哪些已知、哪些是推断、哪些仍然未知。

实际控制决定实际问责

分布式服务需要一种跟随实际控制的责任模型。该模型可以在不指责任何过失的情况下陈述。

角色	主要控制项	预期证据
根服务器运营商	实例位置、权威容量、上游多样性、本地过滤、监测和事件响应	逐实例和逐链路的健康、响应行为、路由背景、缓解时间与恢复证据
传输与对等网络	路径容量、路由传播、拥塞管理和网络域内过滤	路由和流量变化、受影响路径、过滤措施以及相关网络可达性
接入网络	客户边缘控制和其域内源地址合理性	部署范围、例外情况、验证结果和可用时的攻击相关观察
递归解析器运营商	缓存行为、重试、根提示和面向用户的解析监测	依赖缓存的成功、超时和重试模式、根选择结果以及解析器恢复
协调与咨询机构	共同预期、信息交换、证据格式和事后分析	及时通知、通用术语、可比较测量、记录在案的决策和有边界的发现
最终用户	应用请求和本地观察	事务症状，而不期望用户重建隐藏的基础设施状态

根运营商对权威服务拥有最直接的控制，但无法控制每个数据包路径。它们可以分配容量、选择上游、监测实例并实施本地缓解。它们无法单独阻止每个始发网络发出有害流量。

传输与对等网络控制流量能否经特定路径到达权威容量。它们可以影响拥塞、路由可用性和站点间需求的移动。所提供的证据并未重建 2002 年攻击期间的每条路由或对等决策，因此不应推断任何具体路由干预。缺乏完整路由记录本身就是一条问责教训：服务声明应伴随足够的路由证据，以区分实例耗尽与路径故障。

接入网络拥有不同的控制。它们有能力评估离开其域的流量是否使用与其域相符的源地址。这并不使它们成为根系统的控制者。它使它们对受攻击服务器在目的地无法完全强制的一个风险边界负责。

递归解析器运营商控制着最接近日常 DNS 使用的组件。缓存可以保持连续性，重试可以找到剩余服务，监测可以揭示根压力是否正在转化为解析失败。解析器运营商不控制根容量，但可以提供关于用户影响传播的决定性证据。

ICANN 及相关协调结构处于另一层面。根区和机构角色使 ICANN 与服务生态系统和后来的分析相关，但并不等同于对独立运营的根服务拥有排他性运营控制。咨询结构也是如此：它们可以定义预期、促进协调并改进证据，而不直接运营每个实例。

SSAC 关于 DDoS 风险和协调 DNS 控制的咨询意见，以及响应这项工作的机构记录，展示了这一协调层后来的发展。[6], [7] 根服务器运营商威胁缓解框架同样反映了一种分布式模型：韧性来自运营商控制和合作，而不是单一指挥点。[15]

控制所有权应通过三个问题来评估。

第一，谁能观察到该状况？根运营商看到实例和链路遥测。传输网络看到其域内的流量和路由。解析器运营商看到超时、缓存使用和重试。用户看到事务症状。

第二，谁能改变该状况？根运营商可以增加或重新分配服务容量。上游可以改变路由或缓解措施。接入网络可以限制不合理的源流量。解析器运营商可以维持稳健的重试和缓存行为。协调机构可以统一沟通，但不能替代这些运营行动。

第三，谁能证明恢复？没有任何单一行动者拥有所有部分。根运营商可以显示服务恢复，网络可以显示路由和流量正常化，解析器运营商可以显示解析再度成功，外部监测器可以测试可达性。可信的收尾应把这些记录连接起来，而不假装它们来自同一个控制者。

这种模型把问责变成一门工程学科。它避免两个极端：因一个机构并未排他运营的系统而指责它，以及把分布式运营当成无人需要解释结果的理由。

入口过滤是上游的责任，而不是万能药

源地址过滤之所以属于分析范围，是因为拒绝服务流量可以利用远离受害服务的弱点。RFC 2827 描述了旨在减少携带伪造源地址流量的入口过滤。[17] RFC 3704 展开了过滤考量，包括多宿主网络和不对称路由带来的复杂情况。[18] RFC 4732 把拒绝服务视为全互联网范围的工程问题，要求在网络的多个部分加以关注。[19]

这些文档指明了一个控制边界。一个知道哪些源地址应合法地源于其客户或下游的网络，比在数据包经过多个网络后才收到它们的根服务器更有可能拒绝不合理的流量。

这一原则并不证明 2002 年的攻击依赖某种特定欺骗方法。所提供的公开证据没有确定完整的来源群体、攻击者、动机或数据包生成方法。从反欺骗标准的存在推断这些事实是不妥当的。

入口过滤也不是对抗分布式洪流的单一网络疗法。在一个接入网络过滤伪造源地址，并不能阻止其他网络的有害流量，也不能阻止使用有效源地址的流量。其有效性取决于相关始发边缘的部署、准确的策略以及对合法路由复杂性的容纳。

该控制仍然重要，因为目的端防御无法修复源头边缘的所有弱点。如果允许伪造源流量离开接入网络，受害服务会在更具判别力的执行点之后才看到症状。反过来，过宽的过滤可能损害合法的多宿主流量。问责要求有证据表明控制措施既能有效对抗不合理来源，又足够精确以保留合法连接。

因此，适当的问题是有限的：

网络是否在其实际能治理的域内部署了源地址有效性控制？
是否理解并测试了多宿主和不对称路径的例外？
运营商是否收集了证据，显示控制措施接受或拒绝了什么？
过滤变化能否与合法服务的改善相关联？
缓解是否把有害流量转移到别处，或制造了新的可达性故障？

这些问题都没有指认 2002 年的攻击者。也没有把排他责任分配给接入网络。它们只是确保分析不会在相关控制存在于上游时，把全部负担压在权威服务器上。

路由多样性、对等和传输容量应与过滤并置。根实例可能有足够的计算容量，但如果其上游路径饱和，仍可能不可达。另一个实例可能健康，但因路由不把受影响解析器引向它而几乎收不到流量。过滤减少某些流量风险；多样性保留备用交付路径；服务分布创造额外容量端点。这些控制相互补充，但不能互换。

协调是运营控制，而不是中央指挥的主张

分布式运营商模式依赖协调，正是因为没有任何一方控制整个系统。在快速演变的攻击中，运营商需要对所观察内容有共同术语、交换有边界证据的渠道，以及区分本地缓解与全系统恢复的方法。

协调不应被混同于许可。根运营商必须能够保护自己的服务，而无需等待中央机构指挥每个技术行动。传输网络必须在其域内行动。解析器运营商必须保持本地服务。当这些自主行动影响共同结果时，协调才变得有价值。

2002 年的记录显示共同证据为何重要。CAIDA 描述了来自指定监测器的路径性能。[1] 其后来分析描述了选定根链路上的数据包。[2] ICANN 总结了逻辑地址。[5] D-Root 在运营商历史中记录了该事件。[4] 每份记录都有用，但它们不同的对象必须被谨慎调和。

后来的 SSAC、RSSAC 和运营商出版物可以被视为对该证据问题的回应。它们强调协调控制、服务预期、共享测量和威胁缓解。[6], [13]-[15] 它们的相关性在于改善未来的可观测性和响应。不应利用它们宣告所有这些机制在 2002 年 10 月都是强制性的或已经部署。

有效协调有可衡量的产出。运营商可以记录何时识别出共同事件、哪些服务标识或实例受影响、路由和过滤发生了哪些变化、用于宣布恢复的证据，以及对范围的分歧。只产生一个全局标签——“正常”或“故障”——的协调过程，并不能捕捉分布式系统。

公开结论应比内部确定性更窄。如果运营商拥有不完整的可见性，正确的声明是有边界的：服务已在指定实例和外部观测点恢复，而其他区域仍未验证。明确的比不支持的普遍性更符合问责。

可衡量的韧性与恢复测试

攻击的核心教训并不是后来的某一种技术解决了根 DNS 风险，而是韧性声明必须转化为覆盖整个服务路径的证据。

一个可辩护的问责测试可以组织成七个相连的阶段。

1. 权威完整性

第一个问题是解析器是否拥有准确记录，标明预期的根服务标识。根区和根提示信息履行这一台账职能。如果这些记录错误，正确目的地的运行容量可能永远无法到达。

权威完整性是必要条件，但不充分。通过这一阶段证明系统指向预期服务，并不能证明这些服务可达。

2. 来自多样化网络的可达性

第二阶段测试逻辑地址能否从多个相互独立的网络位置到达。测量应标明其观测点、可用时的路由、指标和间隔。

CAIDA 的观察表明这种严谨为何重要。所报告的往返时间变化是来自特定监测器的真实测量。[1] 现代韧性评估应扩展此类视角的数量和多样性，但必须避免声称超过监测器覆盖范围的地理范围。

通过这一阶段并不要求每个探针报告相同性能。它要求运营商理解服务在哪里健康、恶化或未经验证，并避免把区域故障隐藏在全局平均值之后。

3. 可用的权威服务

可达性必须带来及时、正确的权威答案。一条到达地址的路由如果没有任何可用响应，就不算交付连续性。运营商应区分链路饱和、实例耗尽、错误答案和误伤合法流量的本地缓解。

在披露操作安全允许的范围内，分布应在实例层面描述。相关证据包括哪些服务位置保持可用、容量是否足够独立以避免共同瓶颈，以及是否在各位置交付相同的权威数据。

RFC 2870 提供了关于容量、多样化连接、日志记录和合作的事件前背景。[8] RFC 3258 提供了早期的分布式服务模型及其路由和一致性问题。[9] 后来的任播和根服务文档细化了对照标准。[10]-[12] 它们都不能替代特定于攻击的遥测。

4. 解析器连续性

第四阶段测试递归解析器能否通过缓存、重试和可达的根标识继续获得答案。这一阶段防止评估把服务器困境等同于事务失败。

解析器结果应尽可能按缓存状况分开。热缓存证明架构的缓冲有效。需要未缓存或已过期信息的查询更直接地测试当前权威可达性。两者都很重要，但它们回答的是不同问题。

RFC 1034 和 RFC 1035 为创建这一边界的解析器和缓存行为提供了基础。[20], [21] 2002 年事件期间全球解析器群体的确切缓存状态仍然未知，因此无法仅凭服务器数据重建。

5. 合法事务完成

第五阶段测量真实或有代表性的面向用户的解析是否完成。事务证据应说明接入网络和时间窗口，而不是把少数成功测试当作全球证明。

这一阶段是基础设施性能转化为用户影响的地方。它仍需谨慎解读。事务可能因本地解析器、接入路径、根以下的权威依赖或应用超时而失败。归因于根的前提是需要证据把失败与相关根服务状况连接起来。

CAIDA 关于全球运营可见影响轻微的结论是重要的事件特定边界。[1] 它没有量化每个用户体验，但阻止了普遍瘫痪的主张。

6. 流量来源与路由控制

第六阶段测试权威服务之外的控制。网络应能解释其源地址验证姿态、路径容量以及相关路由或过滤变化。

RFC 2827 和 RFC 3704 标明入口过滤原则及其运营限制。[17], [18] RFC 4732 把拒绝服务缓解置于分布式工程背景中。[19] 这一阶段的证据不应假设所有攻击流量都使用伪造源。它应显示有哪些控制可用、应用于何处，以及变化是否保留了合法流量。

路由多样性也必须经过测试，而不是口头声称。多个上游名称不能证明独立的故障域。多条路由不能保证受影响解析器到达健康容量。有用的评估应把路由观察与服务结果连接起来。

7. 协调宣告与恢复

最后阶段询问运营商能否说明事件何时被宣告、哪些服务边界受影响、发生了什么变化，以及恢复如何得到验证。

后来的 RSSAC 测量工作为可比较的根系统证据提供了框架，而运营商威胁缓解和大型权威服务指南提供了额外对照点。[13]-[16] 这些后来的材料应指导当前预期，而不应被误述为追溯性的攻击当天义务。

恢复需要多个指标之间取得一致：

受影响实例的流量和响应状况已经稳定。
路由使健康服务可从多样化的外部网络到达。
权威答案保持正确和及时。
解析器测试在相关缓存条件下成功。
合法事务测试恢复。
缓解没有制造等效的可达性故障。
明确记录仍然未知的区域或服务标识。

没有任何单一指标能证明整条链条。它们合在一起可以支持有边界、可复现的宣告。

该框架使补救可衡量。“增加任播”“提高容量”或“改善协调”都是不完整的承诺。补救措施应说明它针对哪个故障边界，以及哪些证据将证明它奏效。额外实例应改善可达性或故障隔离。更多容量应增加指定路径的可用余量。过滤应在不排除合法来源的情况下减少有害流量。协调应缩短检测时间、统一范围并产生可比较的恢复证据。

攻击暴露的是连续性问题，而不是主权问题

2002 年事件可能被误解为一场关于哪个机构控制根的争夺。这种框架漏掉了运营故障边界。

根记录标明了预期应答的逻辑服务。攻击主要挑战的并不是这些记录的存在。它挑战的是解析器能否通过可用网络到达正在运行的权威容量。

这一区别很重要，因为记录和服务具有不同的问责属性。记录可以审计其准确性和经授权的更改。服务必须测试其可达性、正确性、容量和连续性。维护或协调记录的机构并不自动控制实现该记录的每条路由和每台服务器。

根服务器运营商的实际自主性因此不是问责的障碍。它是问责设计必须反映的事实。每个运营商都应能为自己的实例提供证据，并协作形成系统级视图。传输与接入网络应为其路径和边缘控制负责。解析器运营商应为呈现给用户的连续性负责。协调机构应保存共同记录，而无需假装指挥每一项运营行动。

这种现实层次方法比治理口号更严格。它追问系统是否运行、在哪里可达、哪些控制吸收了攻击，以及恢复如何得到证明。它还防止权威记录被当作魔法保证。台账中的正确名称并不能让数据包动起来。

同样的方法也约束关于预防的主张。所提供的证据没有显示某一家运营商或机构可以单独阻止该攻击。在一个根增加容量并不能控制其他根的流量。在一个接入网络过滤并不能约束所有来源。解析器缓存并不能无限期保存数据。协调本身也不能创造容量。韧性来自多项控制措施的结合效果。

因此，问责测试是多元的，但并不含糊。它要求每个控制者在其运营的层面提供证据，并要求系统作为整体证明跨这些层面的连续性。

公开证据无法确定的事实

从所提供的记录来看，若干重要事实仍然未知。

攻击者的身份和动机没有被确定。所涉系统或来源的完整群体也不可知。证据并不能将攻击归于某个具名个人、组织或行为者类别。

每个根标识和物理实例的精确数据包速率不可得。CAIDA 的数据包工作覆盖了攻击开始后不久 E、I、K、M 链路，并将观察按十分钟间隔组织。[2] 这些数据不应推广到未监测的链路。

攻击当天的每条路由和缓解变化也未知。公开证据没有提供每个根运营商完整的 BGP、对等或传输重建。它不能支持某一具体路由决策导致或结束了事件的主张，除非另有独立记录。

2002 年 10 月 21 日活跃的完整物理拓扑没有被枚举。后来的任播扩展无法填补这一空白。把后来的分布模式描述为攻击期间普遍存在是不准确的。

解析器缓存状态和精确的用户可见失败率不可得。CAIDA 的轻微影响结论是一个重要边界，但不是对每个解析器或用户的普查。[1] 某些事务可能失败；记录并没有对其进行普遍量化。

完整的内部运营商时间线、协调记录、成本和法律分配也在证据之外。技术标准和后来的咨询文档标明工程控制措施，但并不能确定过失、非法、违约或法律责任。这些结论需要此处不存在的事实和法律分析。

同样不能假设每项事后补救都有效。ICANN 后来的比较把 2007 年攻击中用户影响降低部分与 2002 年后的任播部署和运营商协调联系起来。[5] 这支持有限的比较，而不是主张每一项后来的控制在所有条件下都同样有效。

这些未知应保持可见。对不确定性的精确是基础设施问责的一部分，因为它防止局部观察、机构总结或后来的设计改进被转化为没有根据的历史确定性。

关键问责教训

2002 年根 DNS 攻击之所以严重，是因为它把协调压力施加在递归解析器用于导航 DNS 层级的依赖基础设施之上。其重要性并不要求声称互联网几乎停止或每个用户都失去了服务。

CAIDA 观察到 UTC 时间 22:00 左右出现突然性能恶化，并从其观测点报告了受监测根标识之间不同的持续时间。[1] 其后来数据包分析记录了选定 E、I、K、M 链路上的流量。[2] D-Root 的历史证实了该事件的运营意义。[4] ICANN 后来把攻击的广度总结为 13 个逻辑根服务器地址中有 9 个被淹没。[5] CAIDA 仍然得出结论，全球运营可见影响轻微。[1]

当把系统作为一条链条来检查时，这些事实彼此吻合。逻辑地址标识服务；它们并不等同于完整的物理部署。路由决定解析器可以到达哪些容量。分布式权威实例创造替代选择，但依赖拓扑和一致性。递归缓存减少了对实时根查询的即时依赖。传输与接入网络控制部分流量路径和源地址有效性边界。测量决定结论是局部的、区域的，还是全系统的。协调把自主运营商在缓解和恢复中连接起来。

因此，攻击使韧性成为问责测试。它要求的证据不只是记录完好，或某台服务器在某个地方应答了。它要求证明正确的权威服务仍然足够可达——从足够多的路径——以维持解析器和事务的连续性。

后来的任播、RSSAC 测量和威胁缓解工作可以被评估为对该测试的回应。[10]-[16] 它们不应被变成攻击当天的神话或追溯性法律义务。它们的价值在于使控制和证据更加明确。

持久的原则很简单：记录标明权威；运行中的、可达的服务证明连续性。一个有韧性的分布式服务必须能够同时展示两者。它的运营商必须证明他们控制了什么、观察到了什么、如何协调，以及如何知道恢复是真实的。否则，只剩下一个准确的台账，指向一个可用性无法证明的服务。