2021 年 10 月 4 日 Facebook 及旗下服务全线瘫痪，Cloudflare（全球公共 DNS 服务 1.1.1.1 的供应商）工程师发表博客 october-2021-facebook-outage[1] 以外部视角解读本次事故。
“Facebook 不可能瘫痪，是吗？”
在今天 15:51 UTC（格林威治）时间，我们开了一个标题为“Facebook DNS 查询返回 SERVFAIL”的内部紧急事件，因为担心我们的 DNS 解析服务 1.1.1.1[2] 出了问题。但正当我们准备在公共状态页面[3]上发布时，我们意识到发生了其他更严重的事。
社交媒体很快就炸开了锅，报道我们的工程师也迅速确认了。Facebook 和它的附属服务 WhatsApp 和 Instagram 都已经瘫痪。他们的 DNS 域名停止了解析，而且他们的基础设施 IP 也无法访问。就像有人一下子从他们的数据中心拔掉了网线，将他们与互联网断开。
这本身不是 DNS 问题，但 DNS 故障是我们目前看到的 Facebook 大瘫痪的第一个“症状”。
这怎么可能？
来自 Facebook 的更新
Facebook 现在发布了一篇博文[4]给出了内部发生的一些细节。外界的我们看到了这篇博客中概述的 BGP 和 DNS 问题，但实际上始于一个影响了整个骨干网的配置变更。这导致了 Facebook 和其他附属服务的消失，而且 Facebook 内部的员工都很难再次获得服务。
Facebook 又发表了一篇博文[5]，详细说明到底发生了什么。你可以作为吃瓜群众阅读该文了解内部情况。
现在来看看我们从外部看到的情况。
认识 BGP
BGP[6] 表示边界路由协议（Border Gateway Protocol）。这是一种在互联网上的自治系统（AS）之间交换路由信息的机制。驱动互联网运行的大型路由器有着庞大的、不断更新的路由表，用来将每个网络包传送到最终目的地。没了 BGP，互联网路由器就懵逼了，网络也无法运行。
互联网实际上是网络的网络，通过 BGP 捆绑在一起。BGP 允许一个网络（例如 Facebook）向其他网络宣讲其存在来构成互联网。当我们写到 Facebook 没有官宣它的存在时，ISP 和其他网络就找不到 Facebook 的网络，所以就无法提供服务了。
每个独立的网络都有一个 ASN（Autonomous System Number）：自治系统编号。一个自治系统（AS）是一个具有统一的内部路由策略的独立网络。一个 AS 可以产生前缀（比方说它们控制一组 IP 地址）以及传输前缀（比方说它们知道如何到达特定的 IP 组）。
Cloudflare 的 ASN 是 AS13335[7]。每个 ASN 都要使用 BGP 向互联网公布它的前缀路由；否则没人知道如何连接以及在哪里找到它们。
我们的学习中心[8]对什么是 BGP[9] 和 ASN[10] 以及它们是如何运作的有很好的解释。
在下面简化的示意图中，可以看到互联网上的六个自治系统，以及一包数据从起点到终点可能使用的两条路线。AS1 → AS2 → AS3 是最快的，而 AS1 → AS6 → AS5 → AS4 → AS3 是最慢的，但如果第一条路断了，也可以作为备用路线。
bgp-simplified
在 UTC 时间 15:58 我们注意到 Facebook 已经停止公布他们 DNS 前缀的路由。这意味着，至少 Facebook 的 DNS 服务是不可用的。正因为如此 Cloudflare 的 1.1.1.1 DNS 解析器无法再响应 facebook.com 的 IP 地址的查询。
代码语言：javascript复制route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>
route-views>show ip bgp 129.134.30.0/23
% Network not in table
route-views>
同时，其他 Facebook 的 IP 地址仍可路由，但没啥用因为没了 DNS，Facebook 和其相关服务实际上就是不可用的。
代码语言：javascript复制route-views>show ip bgp 129.134.30.0
BGP routing table entry for 129.134.0.0/17, version 1025798334
Paths: (24 available, best #14, table default)
Not advertised to any peer
Refresh Epoch 2
3303 6453 32934
217.192.89.50 from 217.192.89.50 (138.187.128.158)
Origin IGP, localpref 100, valid, external
Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402
path 7FE1408ED9C8 RPKI State not found
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
route-views>
我们持续追踪在全球网络中看到的所有 BGP 更新和公告。在 Cloudflare 的规模下，我们收集的数据向我们展示了互联网是如何连接的，以及流量从哪里流向地球上的任何地方。
你更改前缀广播或是完全撤销前缀，就会发送 BGP UPDATE 消息通知路由器。在检查我们的时间序列 BGP 数据库时，可以清楚地看到从 Facebook 接收到的更新数量。通常这张表是很安静的：Facebook 不会一天到晚对其网络做大量变更。
但是 UTC 时间 15:40 左右，我们看到了 Facebook 的路有变化的峰值，这就是问题开始的时候。
如果我们以路由的公布和撤销的视角来看，就能更好地了解发生了什么。路由被撤销，Facebook 的 DNS 服务器下线，出现问题一分钟后，Cloudflare 的工程师在一个房间里想，为啥 1.1.1.1 不能解析 facebook.com 并担心这是我们系统的某种故障。
随着那些撤销，Facebook 及其网站实际上已经与互联网断开了连接。
DNS 受到影响
作为这一事故的直接后果，时间各地的 DNS 解析器都停止了对其域名的解析。
代码语言：javascript复制➜ ~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @1.1.1.1 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
➜ ~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @8.8.8.8 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
发生这种情况是因为 DNS 像互联网上的其他系统那样，也有路由机制。当有人在浏览器地址栏中输入 https://facebook.com 这个 URL 时，负责将域名翻译成真实 IP 地址的 DNS 解析器，首先检查它的缓存中是否有记录并使用；如果没有的话，它就试图从域名服务器那得到答案，通常由域名所有者托管。
如果域名服务器不可达或由于其他原因而无法响应，则会返回 SERVFAIL 错误，浏览器也会向用户抛出错误。
同样我写过 DNS 是如何工作的[11]。
因为 Facebook 停止通过 BGP 公布他们的 DNS 前缀路由，我们和友商的 DNS 解析器无法连接到他们的域名服务器。因此，1.1.1.1、8.8.8.8 和其他主要的公共 DNS 开始发送（和缓存）SERVFAIL 应答。
但这还没完，现在人类的行为（不停地刷新）和应用程序的逻辑（重试机制）导致了另一个雪崩效应，一场 DNS 流量海啸接踵而至。
发生这种情况的部分原因是应用程序不接受错误的应答并开始积极重试；另外一部分原因是用户也不接受错误的应答并开始重刷页面，或重启他们的应用程序，也非常激烈。
这是我们在 1.1.1.1 上看到的流量增长（以请求数计）：
因为 Facebook 和他们的网站是如此之大，我们的 DNS 解析器在全球面临平时 30 多倍的查询，并可能对其他平台造成延迟和超时问题。
幸运的是，1.1.1.1 建立在免费、私有、快速和可扩展的基础之上，我们能够继续为用户提供服务，影响很小。
绝大部分的 DNS 请求都在 10 毫秒内得到解析。同时 p95 和 p99 百分比的一小部分响应时间增加，可能是由于过期的 TTL 不得不求助于 Facebook 的域名服务器和超时。众所周知 DNS 10 秒超时限制。
对其他服务的影响
人们开始转战其他社交媒体希望了解到更多信息或讨论正在发生的事。当 Facebook 下线时，我们开始看到对 Twitter、Signal 和其他社交网络平台的 DNS 查询增加。
我们还可以从受 Facebook 影响的 ASN 32934 的 WARP 流量中看到另一个副作用。这张图展示了每个国家从 UTC 时间 15:45 到 16:45 的流量与三小时前对比的变化。全世界出入 Facebook 网络的 WARP 流量完全消失了。
互联网
今天这件事温和地提醒我们，互联网是一个非常复杂的系统，数百万个系统和协议相互依赖共同工作。信任、标准化和实体间的合作是其成为全球近 50 亿用户服务的核心。
更新
UCT 时间 21:00 左右，我们看到了 Facebook 的网络重现 BGP 活动，并在 UTC 时间 21:17 达到顶峰。
下图显示了 DNS 域名 “facebook.com” 在 Cloudflare 的 DNS 解析器上可用性。它在 UTC 时间 15:50 不可用并在 UTC 时间 21:20 重新上线。
毫无疑问 Facebook、WhatsApp 和 Instagram 的服务上线还需一段时间，但截至 UTC 时间 21:28 Facebook 看上去已经重新连接至全球网络，DNS 重新运作了。
