原文: [https://blog.cloudflare.com/o...]
译: 时序

“FB不会宕机，不是吗？”，我们想了几分钟这个问题

今天2021.10.4 16:51 UTC，我们建了一条标题为“FB DNS 查询返回SERVFAIL”的单子，因为我们担心我们的DBS 1.1.1.1出现了问题。但当我们要在我们的的[公共状态]页面发布状态时我们发现可能有更严重的问题正在发生。

社交媒体迅速发酵报道了这件事同时我们的工程师也确认了。FB以及它的关联服务WhatsApp与Instagram也全宕了。它们的DNS域名停止了解析，它们的基础设施IP也不可用了。那就像是有人将他们的数据中心同时“拔了网线”，让他们从互联网上消失了。

这怎么会发生呢？

会会BGP

BGP的全名是边界网关协议(Border Gateway Protocol)。它是一种用来在互联网上的自主Autonomous系统(AS)与路由信息交换信息的协议。巨大的的路由让互联网可以让路由快速更新连通的列表来传递网络包到目标地址。没有BGP，互联网路由不知道怎么做，互联网就不工作了。

互联网基本上就是一堆网络中的网络，它是被BGP协议划分。BGP让一个网络(这里是指FB)来向互联网中的其他网络告知其的存在。由于我们前面提到FB没有广播它的存在，ISP服务商和其他网络不知道如何能找到FB的网络，所以它就不可用了。

每个独立的子网都有一个ASN：(Autonomous System Number)。一个Autonomous系统(AS)都是一个使用了单独内部路由策略的独立网络。一个AS可以生成前缀（表明它们控制一组IP地址），其也可以传送前缀（表明它们知道如果抵达一组特定的IP地址）。

Cloudflare的ASN是AS13335.每个ASN都要使用BGP声明它的前缀路由到互联网；不然的话，没有人知道如何连上并查找我们。

我们的[学习中心]有对于[BGP]和[ASN]如何工作的很好的资料。

这是一张简化的图，你能看到互联网有6个autonomous系统，2条一个数据包可以用来从开始点到结束点的路由。 AS1->AS2->AS3是最快的，AS1->AS6->AS5->AS4->AS3是最慢的，但如果第一条路出问题了也可以走。

在1658UTC我们注意到FB停止向路由广播它们的DNS前缀。这表示，至少FB的DNS服务器不可用了。由于这个原因Cloudflare的1.1.1.1的DNS无法回答对于facebook.com或instagram.com的IP地址查询。
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>
同时，其他的FB IP地址仍然是可路由的，但由于没有FB的DNS相关信息基本没什么用：
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更新和声明。在我们的这里，收集的数据给了我们一个互联网如何连接和流量在全球从哪来到哪去的视图。

BGP更新的消息告诉路由任何你对前缀或整体的广播都要撤销前缀。当检查我们的时序BGP数据库时可以清晰的看到我们从Facebook收到的一系列更新。通常这张图很平静：FB不会产生很多变更。

但在15:40 UTC我们看到从Facebook看到路由变更的尖峰。这就是问题开始的时候。

如果我们将路由声明与撤销分开看，我们能更清楚的看到问题。路由在插销，Facebook的DNS服务器在掉线，问题发生一分钟后，Cloudflare工程师在一间屋子里想确定为什么1.1.1.1不能解析facebook.com的地址，并在担心那是我们系统的一个问题。

由于这些撤销事件，Facebook和它的站点很快的从互联网断开。

DNS受到影响

由于这个问题直接的影响，全世界的DNS解析停止解析它们的域名。
➜ ~ 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后，DNS解析，响应域名查询的请求并返回需要连接的IP地址，最初会检查它的缓存中是否存在并使用缓存。如果没有，则从域名服务器上抓取答案，一般是由掌管它的实体来负责。

如果域名服务器不可达或由于一些原因不能响应，则SERVFAIL会返回，浏览器则返回错误给用户。

一样的，我们的学习中心提供了DNS如何工作的[解释]。

当Facebook停止通过BGP来广播它们的DNS前缀路由，我们和其他人的DNS服务就无法连接它们的域名服务器。然后，1.1.1.1，8.8.8.8和其他主要的公共DNS服务器开始发出（或缓存的）SERVFAIL响应。

但这不是全部。现在人类行为和程序逻辑一起导致了其他指数效应。DNS请求产生了海啸。

这个问题部分是由于app不接受返回的错误并开始重试，另一部分原因是终端用户不管错误的请求并开始重刷页面，或杀掉他们并重启app，也造成了大量请求。

这是我们看到在1.1.1.1上的流量增加：

到这，由于Facebook和它的网站太大，我们的DNS处理比平时大30倍的查询量并导致了其他平台的延迟和超时问题。

幸运的是，1.1.1.1是打造成免费，快速（正如独立DNS检测工具DNSPerf证明的那样），可扩展，我们可以保证服务的情况下最小的影响用户。

我们DNS请求能保持到低于10ms。同时，p95和p99的百分位能看到响应时间的增加，很可能是由于失效的TTL需要重新请求Facebook域名服务器并产生超时。DNS的超时时间限制在10秒是工程师默认的规则。

影响其他服务

人们开始转向其他服务并想要知道到底发生了什么。当Facebook不可用了，我们看到对Twitter，Signal和其他消息，社交媒体平台的DNS访问量在增加。

我们能到从Facebook影响的ASN 32934在本次不可用对于WARP流量的负面影响。这张图能看到从15:45 UTC到 16:45 UTC之间在每个国家与3小时前比流量是如何变化的。全世界WARP流量从Facebook网络进出的流量都消失了。