Spamhaus 2013 年 DDoS 如何把开放 DNS 递归变成网络责任测试

摘要

Cloudflare 称，Spamhaus 最初遭遇约 10 Gbit/s 的流量，之后出现约 75—90 Gbit/s、120 Gbit/s，并在提供商侧叙述中出现约 300 Gbit/s 的观测值；这些数字均须归属于 Cloudflare 的特定观测位置，不能当作互联网整体峰值。[1][2]
事件边界是 2013 年 3 月 18 日至 27 日：攻击先影响 Spamhaus 网站及其接入，随后压力扩展到 Cloudflare 使用的上游和互联路径，但公开材料不能证明发生了全球互联网中断。[1][2]
可执行攻击路径由伪造源地址、面向任意外部客户开放的递归解析器、被放大的 DNS 响应，以及通往受害者或缓解网络的共享链路组成；递归 DNS 与权威 DNS 必须严格区分。[4][10]
Cloudflare 报告其观测中有超过 30,000 个解析器参与，并估计特定查询与响应形态接近百倍放大；这不是对所有解析器、数据包或来源网络的完整普查。[1][2]
RFC 5358 在事件发生前已建议限制递归服务，BCP 38 与 BCP 84 也已把源地址验证责任落实到客户、接入和多宿网络边缘；关闭递归与拦截伪造源地址是两项独立控制。[4][5][6]
Spamhaus 网站及支撑网络受到干扰，不等于其分布式 DNSBL 数据在全球停止提供；服务可用性判断必须指明端点、路径、地点和观测时间。[3]
Anycast 可以分散负载，却不能消除 BGP 路径、对等互联、转接容量和站点余量形成的约束；不能在缺少路径证据时虚构某个互联网交换点发生整体故障。[2]
网络责任的最终检验是可审计修复：限制非预期递归、验证源地址、保存路由与缓解变更、记录跨运营者协调过程，并从受影响路径之外复测结果。[14][15][16][17][18][19]

责任问题必须落到实际运行的路径

Spamhaus 事件经常被压缩成一个戏剧化数字，或者被讲成攻击者与受害者之间的单线冲突。这样的叙述忽略了真正使攻击得以执行的网络结构。2013 年 3 月 18 日至 27 日之间，攻击流量穿过了多个彼此独立管理的系统：某处网络允许带有伪造源地址的 UDP 请求离开；某些递归解析器接受了任意外部地址提交的查询；解析器生成比请求更大的响应；BGP 选择的转接或对等路径把这些响应送往目标；缓解服务则通过 Anycast、清洗和路由调整接管或重新分布压力。[1][2]

这些环节没有一个能够单独解释整个事件。开放递归不会自动指定攻击目标，源地址伪造也不会自动产生放大响应；只有当二者与可放大的查询、足够多的解析器以及通往同一目标的网络路径结合时，才形成反射式洪泛。相应地，责任不能仅根据某个组织在事件中的知名度分配，也不能因为一条链路承载了攻击流量，就推定链路运营者制造了这些流量。

更可靠的责任框架首先询问实际控制能力。递归解析器运营者能决定谁有权使用递归服务；接入网络能决定客户是否可以发出不属于其地址范围的源地址；缓解服务能决定路由、清洗、容量和测量方法；上游及对等方能管理自己的接口和拥塞响应；Spamhaus 能管理自身服务架构、依赖关系与恢复沟通。每一方都只应对自己能够配置、观察和修复的环节承担可证明的责任。

这也意味着，网络责任不能由机构地位、公共声誉或对 Spamhaus 黑名单政策的赞同与否决定。本文既不为该机构的政策角色辩护，也不对其作价值裁决。研究对象是更窄、更可验证的命题：哪些正在运行的配置使反射流量得以形成，哪些运营者拥有改变这些配置的能力，以及事后能否证明修复真实生效。

事件边界：2013 年 3 月 18 日至 27 日

Cloudflare 的同期叙述为事件提供了有限但重要的时间和测量边界。其称，Spamhaus 在连接被攻击流量占满、网站无法访问后寻求缓解。Cloudflare 在早期阶段报告了约 10 Gbit/s 的流量，随后描述了约 75—90 Gbit/s 的波次，并把其中大量流量归因于开放递归 DNS 解析器产生的反射响应。[1]

在后续叙述中，Cloudflare 称压力上升至约 120 Gbit/s，并从最初受保护的客户地址逐渐转向其提供商和互联相关路径。约 300 Gbit/s 的著名数字也来自这份提供商侧叙述。[2] 这些数字可以构成事件记录的一部分，但不能被合并成一条连续、统一、由同一测量点记录的增长曲线。客户接口、缓解站点、上游链路和互联边缘看到的是不同位置上的流量，它们可能对应不同时间、不同方向和不同故障域。

因此，约 10、75—90、120 和 300 Gbit/s 都必须附带相同的限定：它们是 Cloudflare 归属的观测值，不是对公共互联网全部流量的同步测量。公开材料没有提供覆盖所有相关网络、经过统一校准的测量系统，也没有建立所谓“全网峰值”。把提供商侧看到的峰值直接写成“互联网承受了 300 Gbit/s”，会把一个有明确观察者和位置的事实扩张成证据并不支持的普遍结论。

“几乎摧毁互联网”同样只能被理解为当时的宣传性表达，包括 Cloudflare 后续文章标题形成的公共传播框架。[2] 它不是全球互联网发生整体中断的技术结论。现有材料也不足以证明某个特定互联网交换点发生整体故障，不能把互联相关链路受压自动改写成交换平台全面中断。

事件边界还排除了另一种常见扩张：把后来的逮捕信息当作所有技术和法律归因问题的终局答案。Spamhaus 后来公布的相关信息可以作为背景，但不足以确定每个数据包的实际发送者、完整来源网络、各运营者事前知情程度、法律责任或者各方因果份额。[3] 在没有进一步裁判和路径证据的情况下，攻击者身份及法律责任必须保持审慎表述。

数字首先属于观测点

DDoS 报道最容易失去的不是数字，而是数字所依附的观测语境。一个缓解平台可能分别记录入口收到的流量、被清洗丢弃的流量、经过聚合后的采样值和最终交付给客户的流量。一个转接商看到的是进入特定接口的负载；一个对等方看到的是一条邻接关系上的流量；受害者看到的则可能只是连接已经饱和后的残余。即使所有测量都准确，它们仍不一定在回答同一个问题。

Cloudflare 报告的约 10 Gbit/s 与 75—90 Gbit/s 来自其客户缓解叙述；约 120 Gbit/s 和广泛传播的约 300 Gbit/s 则属于后续提供商侧记录。[1][2] 负责任的写法需要同时保留观察者、阶段和位置，不能从一个入口读数推导所有互联网路径都经历了相同负载。更不能因为某个数字巨大，就推定每一个相关网络都受到同等影响。

同样的纪律适用于“超过 30,000 个解析器”。Cloudflare 称其观测中出现了超过 30,000 个参与反射的解析器，并估计所观察查询与响应形态的放大比例接近一百。[1][2] 这足以说明分布式聚合的规模，却不是全球开放解析器普查，也没有给出完整的来源自治系统分布。解析器地址数量不等于独立运营者数量，更不等于已经证明每名运营者知道其设备正在参与攻击。

测量记录若要支撑责任判断，至少需要说明采样方法、去重方法、观察接口、时间窗口、收到与丢弃流量的区别、路由变化以及是否存在重复计数。没有这些信息，峰值仍可作为提供商陈述引用，却不能承担普遍因果结论。精确归属并不会削弱事件的重要性；相反，它能避免夸张掩盖真正可修复的配置问题。

反射放大的可执行路径

反射路径始于 IP 报头中的一项虚假信息。攻击请求使用 UDP 向 DNS 服务发送较小的查询，却把源地址伪装成 Spamhaus 或后续承载缓解服务的地址。由于 UDP 在响应前不建立类似 TCP 的端到端连接，接收查询的服务会把答复发送到报头中声称的来源。实际发起者只需提供小请求，较大的响应则由第三方 DNS 设备发送到受害地址。

公开材料把中间环节指向开放递归解析器。它们接受来自任意互联网地址的递归查询，沿 DNS 层级查找所需信息，然后把结果返回给表面上的客户。Cloudflare 称攻击查询涉及 ripe.net 数据，观察到超过 30,000 个解析器，并估计特定请求与响应形态接近百倍放大。[1][2] 这些数字描述其可见范围内的机制和规模，不是对每个请求、每个解析器或所有网络的完整清点。

单个解析器发送的流量可能很小，单个源网络看到的伪造请求也可能低于告警阈值。但大量请求能够并行触发大量响应，并让它们汇聚到同一目的地址或同一组缓解入口。压力可能在到达应用服务器之前就占满客户接入、转接线路、对等端口或某个 Anycast 站点的入口。由此产生的故障首先是网络容量和路径问题，而不一定是应用处理能力问题。

扩展 DNS 消息能力可能改变响应尺寸和分片等运行特征，但消息扩展本身不等于开放递归，也不能替代访问边界。[11] UDP 及其中间设备行为会影响数据包如何通过网络和如何被观察，却不会凭空提供可靠的攻击者身份。[12] 因而，一份反射响应只能证明某个 DNS 服务向伪造地址发送了答复；它不能单独揭示最初控制请求的主体、完整的来源 AS 分布或整个互联网的总负载。

可执行链可以被分成几个独立检验点：源网络是否允许不可能属于客户的地址离开；解析器是否向未授权外部客户提供递归；查询是否产生明显大于请求的响应；响应通过哪些 BGP 选择的路径到达目标；缓解系统在哪个位置接收、清洗或重新路由流量；最终哪些具体服务在何处失去可用性。每个检验点都需要不同运营者提供证据。

递归 DNS 不等于权威 DNS

权威 DNS 服务器发布其所负责区域的数据。递归解析器则代表客户追踪 DNS 层级、查询相关权威服务器、缓存结果并返回完整答案。[10] 同一台机器可以同时承担两种角色，但角色在控制面和责任上仍然可以分离。2013 年这条攻击路径利用的是面向任意外部客户开放的递归能力，不能笼统写成“DNS 服务器参与攻击”。

这一区分具有直接的责任意义。公共权威服务为了让互联网查询其区域数据，本来就需要对外可达；递归服务通常只应面向明确授权的用户或网络。关闭开放递归不是关闭公共权威 DNS，而是划定递归客户范围，并通过访问控制列表、接口绑定、视图、独立服务实例或其他可验证策略执行这一边界。

RFC 5358 在 2008 年已经描述了使用公开递归服务器和伪造受害者地址实施反射放大的问题，并建议递归服务只向预期客户开放。[4] 因而，“限制非预期递归”不是为解释 2013 年事件而事后发明的标准。解析器运营者当时已经可以知道这一控制类别，但仅凭标准存在，仍不能推定某个具体运营者已阅读、理解或故意忽略了它。

解析器运营者控制软件选择、监听接口、客户范围、递归访问策略、缓存与响应行为，也控制修复后是否执行重启和故障切换测试。它不控制遥远网络是否允许源地址伪造。反过来，接入商能够拦截伪造源地址，却通常无权修改另一机构解析器的递归访问列表。即便同一组织同时运营接入网络和解析器，两项职责也应分别取证和验证。

后来的响应控制、DNS Cookies 或最小化特定查询响应等机制可以提供纵深防御，却不能把一个本应受限的递归服务重新定义为安全的公共服务。[7][8] 首要问题始终是：任意互联网来源是否能够调用递归功能，以及运营者能否证明该边界持续有效。

源地址验证是另一道独立控制

反射攻击的另一项前提是伪造源地址能够离开最初的网络边缘。BCP 38，即 RFC 2827，把一项实用控制放在最接近流量来源的位置：如果客户或内部网络发送的数据包声称来自不属于其合法范围的地址，客户侧边界或服务商接入边界应拒绝该数据包。[5] 从提供商视角看，这通常称为入口过滤；对更广泛的互联网而言，其结果是阻止伪造流量从该网络外溢。

这一控制之所以适合部署在客户边缘，是因为运营者在这里最清楚接口、客户和已分配前缀之间的关系。数据包进入任意中间转接网络后，后续运营者未必拥有足够上下文判断其源地址是否合法。因此，不能把每个碰巧承载伪造数据包的远端转接网络都视为同等责任主体。责任最强的位置，是运营者能够准确知道某接口允许使用哪些源前缀，并能执行过滤的位置。

BCP 84，即 RFC 3704，进一步处理多宿和非对称路由环境。[6] 严格反向路径检查在某些合法非对称路径中可能误丢数据包，但这不意味着多宿网络可以完全放弃源地址验证。运营者可以使用接口访问列表、不同严格程度的反向路径方法或与可行路径相适应的策略，在保留合法多宿流量的同时拒绝明显不可能的来源。

合格的证据不应只是“已启用 BCP 38”这一句政策声明。接入运营者应能列出受控接口、客户前缀、验证模式、例外原因、变更历史和覆盖率；受控测试应证明伪造来源无法穿过边界；路由调整后还应复测，以确认多宿和非对称变化没有造成旁路或误拦。MANRS 对源地址验证长期部署困难的讨论说明，标准存在并不等于所有边缘已经执行，因此现实检验必须落在测得的覆盖范围上。[15]

限制递归和验证源地址分别切断反射链的不同位置。前者让任意外部请求者无法调用解析器，后者让伪造受害者地址的请求难以离开源网络。[4][5][6] 关闭一个开放解析器不能修复另一网络的伪造问题；接入网络部署过滤也不能替远端解析器维护访问边界。只有把二者作为独立而互补的控制，责任图才与实际数据包路径相符。

小规模疏漏如何汇聚成网络外部性

反射放大改变了运营者看待“本地小问题”的尺度。一个解析器每秒只发送少量响应，可能不会影响自己的客户；一个接入网络每天只放过少量伪造请求，也可能看不到本地故障。然而，攻击者不需要任何单个解析器成为决定性资源，只要足够多的解析器同时响应，就能让分散流量在远端聚合。

Cloudflare 报告的超过 30,000 个解析器和接近百倍的特定放大形态，展示了这种从局部轻微到远端严重的转换。[1][2] 数千个分别管理的配置决定共同作用：源网络节省了实施验证的成本，开放解析器保留了过宽的服务范围，而受害者、缓解商、转接商或互联路径承担了汇聚后的带宽压力。

这构成一种网络外部性。产生风险的配置位于一处，主要成本却可能由没有参与配置决定的远端机构承担。开放解析器运营者可能与 Spamhaus 没有任何业务关系，也没有选择攻击目标，但其设备仍提供了可被匿名外部请求调用的反射能力。接入运营者可能只看到很小的出站查询，却允许了攻击不可缺少的伪造条件。

责任并不要求证明某个单独解析器“造成了整个攻击”。更合适的问题是，该运营者是否控制了一项可重复利用的条件，是否有合理方法发现它，以及是否在获知风险后完成可验证修复。同理，单个接入网络放过的流量可能只占总量一小部分，但持续执行源地址验证会在规模上减少整个攻击生态可用的伪造入口。

这也是为什么责任不能只按流量份额或主观意图分配。完整来源 AS 分布尚不清楚，各参与网络的精确因果份额也无法从公开记录中求得。可执行控制比抽象份额更适合作为行动依据：解析器运营者关闭非预期递归，接入网络拒绝不合法来源，缓解商记录路径和容量变化，服务所有者区分不同服务的连续性。

Anycast、BGP 与互联路径改变故障边界

Cloudflare 接管缓解后，保护对象不再只是位于单一路径后面的服务器。Anycast 允许多个站点宣告同一服务地址，BGP 根据可见路由为不同来源选择到达站点的路径。攻击流量因此可能分散到多个地点，由不同清洗和接入容量共同吸收。[1][2]

但 Anycast 不是无限容量，也不会平均分配所有流量。某个来源网络选择哪个站点，取决于当时的路由传播、策略、本地优先级、路径长度、对等关系和转接可达性。一个平台的总清洗容量即使很大，也可能存在站点间余量不均、特定转接链路较窄或某个对等入口集中过多流量的问题。攻击因此可能从客户接入故障转化为提供商入口、上游线路或互联边缘的压力。

Cloudflare 称，后续流量不再只针对最初客户地址，而是影响其提供商和互联相关路径，并在该叙述中报告约 120 Gbit/s 和约 300 Gbit/s 的规模。[2] 这些描述表明故障域可能发生移动，却不能证明每个互联网交换点、每个对等成员或所有经过相关地区的网络都发生中断。

“交换点方向”“交换点附近”或“经交换互联抵达”都不是“整个交换点故障”的同义词。一条私有对等链路、一个交换平台端口、一条转接线路或某个站点入口都可能成为限制因素。要认定具体故障，必须有与接口、端口、成员、路由和时间相匹配的记录。现有材料不支持虚构某个交换平台的整体中断，也不支持把其所有成员视为攻击因果链中的共同责任方。

BGP 在这里不是事后画出的拓扑图，而是缓解实际执行的一部分。路由宣告决定哪些站点接收数据包，路由变化可能转移压力，上游协调可能改变接受或丢弃流量的位置。对等互联可以缩短路径并分散入口，转接可以提供更广泛可达性和额外容量；二者也都可能形成新的瓶颈。责任判断需要保存路由宣告与撤回、流量工程变更、接口利用率、站点负载以及对等和转接方的协调时间线。

任何提供商对峰值的公开描述都应明确测量位置和方法。Anycast 入口看到的聚合值不能自动代表客户收到的流量，也不能代表互联网整体流量。真正有助于修复的不是一个脱离路径的最大数字，而是哪条链路在何时承压、哪个站点吸收了多少、哪项路由变化改变了结果，以及变更后是否从外部重新验证服务。

网站中断不等于分布式 DNSBL 数据停止

Spamhaus 最初可见的服务故障有明确边界：攻击占满其连接并使网站无法访问。[1] 后续阶段又涉及主机、DNS 合作方、支撑服务和 Cloudflare 的提供商侧路径。Spamhaus 后来称，其分布式反垃圾邮件数据在其他基础设施遭到攻击期间仍保持可用。[3]

网站与 DNSBL 数据分发不是一个不可分割的服务。网站承载页面、说明、联系方式和状态沟通；基于 DNS 的阻止列表则通过不同端点、复制结构、路由、缓存和用户依赖提供查询。网站入口失效会妨碍支持和公共沟通，但不能单独证明所有邮件系统都无法获得阻止列表数据。

相反，“分布式数据仍然可用”也不能证明每个地区、每名用户和每条网络路径都完全没有降级。它只支持更窄的判断：至少不能从网站中断推出 DNSBL 数据在全球停止提供。局部路径失败、延迟上升或特定端点不可达，既不能在缺少测量时被凭空认定，也不能被一句整体可用声明排除。

服务连续性记录应分别测量 HTTP 可达性、权威 DNS 健康、DNSBL 查询成功率、数据更新时间、延迟和错误率，并注明测试地点、网络、端点和时间窗口。后来的陈旧数据服务机制等设计可以帮助研究在上游或权威服务暂时不可用时如何维持部分解析连续性，但它属于后来的韧性比较，不能倒推为 2013 年所有相关系统已经具备或应以相同方式部署的控制。[13]

Spamhaus 控制自身服务依赖、恢复选择以及公共沟通的准确性，却不控制远端开放解析器或允许伪造数据包离开的网络。Cloudflare 控制其接收的路由和缓解过程，却不控制 Spamhaus 所有分布式数据端点。按服务层分开描述，既避免把网站中断夸大为全球邮件过滤失败，也不会淡化支撑网络受压对运营连续性造成的真实威胁。

不同运营者掌握不同控制

解析器运营者首先控制递归边界。它应知道哪些服务器、地址、接口和地址族提供递归，哪些客户范围获得授权，以及组合部署是否同时暴露权威和递归角色。责任证据包括资产清单、访问策略、外部暴露测试、查询与响应行为记录、变更单以及重启和故障切换后的复测。只修改配置而不验证运行结果，不能证明开放递归已经关闭。

接入网络和客户网络控制源地址验证。它们应记录客户接口允许的前缀、验证方式、多宿例外、路由变化以及受控伪造测试结果。若使用严格反向路径检查，必须说明合法非对称流量如何处理；若使用较宽松或可行路径方法，也要证明明显不可能的源地址不会通过。[5][6] 责任不在于宣称支持某项最佳实践，而在于展示实际覆盖的边缘和仍存在的例外。

Cloudflare 控制其 Anycast 宣告、清洗策略、容量调配、路由变化、上游协调和公共测量说明。[1][2] 它应能区分入口收到、被丢弃、站点间分布和最终交付的流量，并说明峰值来自何处。其观测对于重建事件十分重要，但作为事件参与方和观察者，其数字仍必须保留测量范围，不能被外部叙述提升为全网事实。

转接运营者控制客户边缘政策、自己的接口和拥塞响应。它可能拥有阻断伪造流量、调整路径或协调容量的能力，但不能因为位于一条可能路径上，就被自动分配具体攻击流量或法律过错。需要流量记录、接口计数器、客户关系、路由状态和时间线将控制能力与实际事件连接起来。

对等方和交换平台控制各自的互联配置、端口、交换结构与运营协调。它们能够记录接口压力和路径变化，却不应在缺少证据时被描述为发生整体中断，或被视为产生攻击流量的主体。共享基础设施承受外部成本，并不等于所有运营参与者拥有同等因果责任。

Spamhaus 控制其服务架构、依赖映射、恢复行动以及网站与分布式数据状态的区分。[3] 它不控制远端解析器的访问列表，也不能在他人接入边界部署源地址过滤。受害者有保持服务韧性和准确沟通的责任，但这不能替代反射器与源网络对自己控制面的修复。

权威 DNS 运营者则应只在证据显示其具体角色时纳入判断。事件中的主要缺陷是无限制递归和可伪造请求结合，而不是所有公共 DNS 服务都有相同问题。后来的大型权威服务架构指导可以用于今天的容量、分布和故障切换评估，却不应与开放递归责任混为一谈。[9]

证据必须沿控制点分配

一份可审计的解析器记录，应当把每个递归实例映射到运营所有者、地址、接口、软件配置和授权客户范围。测试既要从获准网络验证合法递归，也要从未经授权的外部网络确认服务被拒绝；还应覆盖 UDP、TCP、IPv4、IPv6 和可能被遗漏的备用接口。修复前后需要保留时间、测试位置、配置版本和结果，确保重启、升级或故障切换没有重新暴露服务。

源地址验证证据应对应到具体客户和接口。运营者需要说明该边界允许使用的前缀、采用的过滤或反向路径策略、异常路由如何处理、例外由谁批准以及何时到期。受控测试必须回答带有不合法来源的数据包是否真的能够离开网络，而不是只检查配置中是否存在一条看似正确的规则。

解析器与边界网络的遥测还应能够相互连接。解析器记录可以显示异常查询速率、请求类型、响应尺寸、截断和限速行为；边界记录可以显示伪造数据包丢弃、客户接口和时间窗口；流量与路由记录则可以说明响应从何处进入缓解或受害路径。证据链应回答五个连续问题：解析器是否可被任意外部来源调用；请求来源是否可能被伪造；生成了怎样的响应；响应经过哪条路径；哪项控制变更终止或降低了问题。

滥用通知也需要可操作信息。只发送一组 IP 地址，无法让运营者有效复现问题。更完整的通知应包含 UTC 时间窗口、协议、目标和表面来源、代表性数据包特征、测量方法、接收方网络或 AS 信息以及可追踪的案件编号。接收方则应记录调查、处置、例外和复测结果。RIPE 与 DNS-OARC 的相关材料说明，放大防御不仅需要一般性倡议，还需要把开放服务、流量特征和运营修复连接起来。[16][17]

缓解提供商需要保存攻击指纹、采样与去重方法、Anycast 站点负载、清洗决策、路由变更、上游请求和恢复时间。公开峰值应说明是入口流量、丢弃流量还是客户侧流量。若攻击从客户地址转向提供商或互联路径，记录还应显示故障域何时移动，以及哪项路由或容量操作改变了结果。

互联网交换平台和对等方应在自己的观测边界内报告端口、接口、路由和交换结构状态。它们不应根据邻近性推断整个互联网的攻击规模，外部分析也不应根据“经过交换相关路径”推定交换平台整体故障。路径专属证据是区分承载、受压、缓解和致因的必要条件。

服务所有者的记录则需要把网站、权威 DNS、支撑主机和分布式数据服务分开。一次绿色状态不能代表所有层都正常，一次网站故障也不能代表所有数据服务都停止。可用性声明应附带端点、测量位置和时间范围，并在恢复后从不同网络复测。

2013 年以前已经存在的控制

对历史事件作责任评估时，最重要的公平边界，是区分当时已经明确存在的控制，与后来才形成的工具和指导。RFC 5358 于 2008 年发布，已经说明使用伪造受害者地址和公开递归服务进行 DNS 反射放大的风险，并建议只向预期客户提供递归。[4]

RFC 2827，即 BCP 38，早在 2000 年就提出在客户边缘过滤不符合合法来源范围的数据包。[5] RFC 3704，即 BCP 84，则为多宿网络和非对称路径提供更细致的源地址验证思路。[6] 因而，到 2013 年 3 月时，两项核心控制类别已经公开：不要向任意外部客户开放递归，不要让明显伪造的源地址从受控网络边缘离开。

这只能证明控制概念存在，不能证明每个运营者都已部署，也不能证明特定运营者的主观知识。标准文本不能代替具体接口、配置和测试记录。对某个解析器或接入网络作判断，仍需知道它实际运行了什么、是否暴露、是否允许伪造流量，以及何时完成修复。

RFC 1034 对 DNS 概念和运行角色的说明，为区分递归解析与权威数据发布提供基础。[10] 这种角色区分并不是为了事后寻找责任对象，而是为了防止把所有 DNS 系统当成同一类设备。事件的核心组合是开放递归与源地址伪造，不是公共权威服务本身天然有错。

UDP 行为相关的早期指导有助于解释无连接数据报和中间设备可能呈现的运行特征，但不能直接完成源地址验证，也不能从反射响应还原攻击者身份。[12] 责任仍然需要回到边缘过滤、递归边界和实际路由证据。

后来的标准只能用于比较与当前验证

2013 年之后出现或成熟的机制，可以帮助今天的运营者构建更强的纵深防御和验证体系，却不能被投射回历史，仿佛当年所有网络都能以完全相同方式部署它们。DNS Cookies 能在双方支持的交互中增加对伪造的抵抗能力，但其适用条件和部署状态必须实际验证。[7]

最小化 ANY 响应可以减少一种曾经具有吸引力的响应形态，但它并不关闭开放递归，也不能阻止源网络发出伪造请求。[8] 大型权威 DNS 服务的后续架构指导可以改善分布、容量和韧性评估，却不能把权威服务与开放递归责任合并。[9]

EDNS 等扩展影响消息能力和响应形态，适合纳入现代响应尺寸、分片和容量测试；它们不是递归访问控制的替代品。[11] 后来的陈旧数据服务机制有助于分析解析服务在上游暂时不可用时的连续性，但不能证明 Spamhaus 事件中的所有端点已经以同样方式运行。[13]

RIPE、MANRS、DNS-OARC 和后续研究可以提供当前的清单方法、暴露测量、源地址验证、响应控制和运营比较。[14][15][16][17][18][19] 它们还可以帮助设计外部复测、覆盖率统计和跨运营者通知。然而，这些后来的资料只能回答今天如何验证得更好，不能自动证明某项后来机制在 2013 年已普遍可得、已被某家运营者采用，或者能以完全相同方式部署。

公平的历史问题不是要求 2013 年的运营者预见所有未来 RFC，而是检查当时已经存在的基础控制是否被采用、限制是否被记录、故障是否得到修复。面向今天的责任问题则更严格：既然已有更成熟的测试和韧性指导，运营者能否提供当前、路径专属、可以复现的证据。

从资产清单到独立复测

可验证修复应从完整分母开始。解析器运营者不能只报告“关闭了若干开放解析器”，还应说明其全部相关地址、实例和接口中有多少经过测试，多少仍然例外，多少因资产归属不清而未覆盖。没有分母的修复数量无法说明剩余暴露面。

资产变化也会使一次性检查迅速失效。收购、网络重构、云租户变化、软件升级、新增 IPv6、备用接口启用和灾备切换，都可能重新引入递归暴露。运营者应在这些变更后触发外部测试，而不是只依赖季度或年度扫描。RIPE 的现代运营材料可以帮助完善持续检查方法，但最终证据仍必须来自运营者自己的当前系统。[14]

源地址验证同样需要持续覆盖。新增客户、前缀变化、多宿策略和非对称路径都可能让旧规则失效。每项例外都应有技术理由、负责人、补偿控制、到期时间和复测条件。只有当受控测试证明不合法来源无法越过边缘时，过滤声明才转化为可审计事实。[5][6][15]

DDoS 演练不应只测试清洗平台容量，还应测试路由和沟通。运营者需要知道哪些 Anycast 站点宣告服务、攻击流量如何重新分布、哪条转接或对等线路最先承压，以及何时需要联系上游。演练记录应把检测、路由变更、容量告警、协调、恢复和复测串成时间线。

要使这套修复具备可审计性，证据保留应贯穿处置前后，而不是等到服务恢复后再补写结论。运营者应把原始观测、配置版本、变更时间、批准记录、路由与接口状态、告警和协调经过放在同一条可追溯时间线上，同时保留测试地点、输入条件、预期结果与实际结果，使后来复核者能够区分配置改变、流量转移和真正消除暴露。外部验证也不应只重复内部检查：应由受影响路径之外的测量位置，按修复前相同的边界重新检查未授权递归、伪造来源拦截、服务端点可达性和路径表现，并把不一致之处继续留在记录中。受控故障切换演练则要在明确范围、回退条件和观察窗口内进行，依次验证主备切换、路由调整、备用接口和恢复沟通，既观察目标控制是否仍然有效，也确认切换没有重新打开原先关闭的入口。演练结束后还要恢复基线，核对配置与运行状态，重复外部复测，并把例外、未覆盖资产和后续复验时间一并记录。只有修复前证据、变更证据、外部行为和修复后验证能够彼此对应，运营者才能说明问题为何消失、是否可能复发，以及下一次变更后应从哪里重新确认；若其中一环缺失，就应明确标示证据边界，而不是以一次绿色检查代替完整闭环。

修复完成的标准也不能只是受影响路径上的单点恢复。若原链路已经被重新路由，原位置显示“正常”可能只是流量转移后的结果。独立复测应从多个未经授权的网络检查递归是否关闭，从代表性客户边缘测试伪造源是否被拒绝，并从不同地点测量网站、DNS 和数据服务。只有外部行为与内部配置相符，才能确认修复不是表面变化。

研究和测量工作可以帮助选择抽样范围、识别长期暴露和比较防御效果。[18][19] 但研究报告不能替某个运营者完成责任证明。最终通过测试的条件，是该运营者能够提供自己控制范围内的最新证据，并让第三方在明确边界内复现结果。

责任不是把所有故障归给一个主体

分布式攻击容易诱发“唯一责任者”叙事，但技术链本身由多个控制面组成。攻击请求的实际发起者控制请求内容和目标选择；源网络控制伪造地址是否可以离开；解析器运营者控制递归是否向外开放；权威服务提供被查询的数据，但不因此自动承担开放递归责任；缓解商控制清洗和路由；互联网络控制自己的容量和协调；Spamhaus 控制自身服务连续性和对外说明。

这些责任可以同时存在，却不必具有相同性质或份额。公开记录不能给出精确的因果分摊，也不能证明每一方当时知道多少。技术上能够指出一个可修复控制，不等于已经证明法律过错；某个网络承载了流量，也不等于其运营者制造了攻击。

同样，运营者没有选择攻击目标，不会让开放配置失去外部影响；受害者成为攻击对象，也不意味着它控制远端反射器。责任框架需要避免两个极端：一端只关注攻击者而忽视大量可修复的基础设施条件，另一端则把所有路径参与者无差别视为共同攻击者。

更精确的做法是为每项结论指定证据门槛。要认定递归暴露，应有外部查询测试和配置记录；要认定源地址验证失效，应有受控测试或边界证据；要认定特定链路受压，应有接口和时间数据；要认定服务不可用，应有端点和地点测量；要认定运营者知情，应有通知、工单或内部记录；要认定法律责任，则需要相应法律事实，而非技术推测。

公开记录仍然无法回答的问题

这场事件的反射机制比其全部规模更容易确定。开放递归解析器接收带伪造源地址的查询，并向受害地址返回更大响应，这一机制有同期叙述和事件前标准支撑。[1][2][4] Cloudflare 的观测值也可以被准确归属。但很多更广泛的问题仍然没有答案。

第一，公开材料没有完整的来源 AS 分布。超过 30,000 个解析器不等于超过 30,000 个独立网络，也不能说明每个响应的来源、数量和持续时间。第二，约 300 Gbit/s 不是公共互联网统一测得的峰值。第三，旁观网络遭受了多大拥塞、哪些具体服务受影响，缺少完整测量。

第四，无法从数据包本身推定各解析器、接入商、转接商、交换平台、缓解商或受害方运营人员在事件前后知道什么。第五，不能在缺少路径记录时把某个交换点写成发生整体故障。第六，后来的逮捕信息不能替代对每一项技术行为和法律责任的独立证明。[3]

第七，网站不可用不能证明全球 DNSBL 数据停止，Spamhaus 关于分布式数据持续可用的说法也不能证明所有用户和路径毫无降级。[3] 第八，公开记录无法精确分配每个参与网络对最终拥塞的因果份额。

这些未知不是研究失败，而是责任分析的边界。把未知保留为未知，可以防止宣传用语、机构冲突和巨大数字替代证据。网络责任的目的不是在记录不足时制造确定性，而是指出还缺少哪类数据，以及哪些运营者有能力在下一次事件中保存这些数据。

一套可执行的运营责任测试

第一项测试是递归边界。运营者能否列出全部递归实例，说明获准客户范围，并从未经授权的外部网络证明递归请求被拒绝？修复是否经历重启、升级、主备切换和 IPv6 测试？如果不能，关闭递归仍然只是未经验证的声明。

第二项测试是源地址验证。客户边缘是否只允许合法前缀，受控伪造测试能否证明不合法来源无法离开？多宿和非对称路径例外是否有清晰理由、负责人和到期条件？如果只有政策文件，没有接口级覆盖和测试结果，责任控制仍不完整。

第三项测试是放大行为。运营者是否记录查询类型、响应尺寸、限速、截断和异常频率，并能区分递归与权威角色？后来的 DNS Cookies、最小响应和响应控制是否按实际支持条件验证，而不是仅在文档中启用？[7][8][19]

第四项测试是路径与容量。Anycast 平台能否展示站点级负载、路由宣告、对等与转接入口、清洗动作和容量压力？互联运营者能否只在自己的测量范围内陈述影响，而不把局部接口问题夸大成平台整体故障？

第五项测试是服务连续性。Spamhaus 或任何受保护服务能否把网站、权威 DNS、支撑主机、数据更新和分布式查询服务分别测量？恢复声明能否指出端点、地点和时间，而不是使用一个模糊的“在线”状态覆盖全部服务？

第六项测试是协调。滥用通知、上游请求、路由变化、容量告警和恢复行动是否具有一致时间线？每项通知是否得到处置，每项修复是否由受影响路径之外的测量重新验证？RIPE 和 DNS-OARC 的运营材料可用于改进这些步骤，但通过测试仍取决于当前系统证据。[14][16][17]

第七项测试是公开表述。流量数字是否说明观察者和测量位置？“几乎摧毁互联网”是否被明确标为宣传框架？未知的来源分布、旁观者影响、运营者知识和因果份额是否仍被保留？只有边界准确的沟通，才能让技术记录服务于修复，而不是制造新的误解。

结论：可审计修复比宏大叙事更重要

Spamhaus 事件的重要性，不在于它是否配得上一个夸张标题，而在于它暴露了分布式网络中的责任缺口。一个源网络允许伪造地址离开，一个递归解析器向任意外部客户开放，一组 BGP 路径把响应汇聚到远端，缓解平台再通过 Anycast、转接和对等关系分散压力。每个本地决定都可能很小，合在一起却足以压满共享链路。

这条路径也说明，责任必须跟随实际控制。解析器运营者关闭非预期递归，接入网络验证源地址，缓解商准确记录路由和流量，上游与互联方保存接口和协调证据，服务所有者区分网站与分布式数据的连续性。任何一方都不能用机构声誉替代配置和测量，也不能被要求为自己无法控制的远端系统负责。

RFC 5358 与 BCP 38/84 证明，关键控制类别在 2013 年以前已经存在。[4][5][6] 后来的 RFC、RIPE、MANRS、DNS-OARC 和研究让今天的验证工具更加完整，却不能被倒推为当年已经以完全相同方式普遍部署的能力。[7][8][9][14][15][16][17][18][19]

最终的责任测试并不复杂，但要求严格：谁能够改变这条可执行路径？他能提供什么证据？修复后，外部测量是否证明问题确实消失？记录能够回答时，就按控制能力追踪行动；记录无法回答时，就保持未知。网络连续性依赖的不是宣传、身份或事后确信，而是准确配置、明确归属和可重复验证。