原文: [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: 0Refresh 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网络进出的流量都隐没了。
互联网
明天的事件揭示咱们互联网是一个非常复杂并由成千盈百的独立零碎与协定组成并一起工作的。信赖，标准化，实体间的合作让寰球50亿沉闷用户能互联。
更新
在大概21:00 UTC咱们看到从Facebook网络收回的BGP更新流动，并在21:17 UTC达到峰值。
这张图显示出了DNS名称 facebook.com在Cloudflare的DNS服务器1.1.1.1上的可用性。它在大概15:50 UTC不可用并在21:20 UTC时复原。
毫无疑问，Facebook，WhatsApp和Instagram须要更多工夫上线，但在21:28 UTC时看起来Facebook开始从新连贯到了寰球互联网，DNS也开始工作了。
本文来自祝坤荣(时序)的微信公众号「麦芽面包」，公众号id「darkjune_think」
开发者/科幻爱好者/硬核主机玩家/业余翻译
转载请注明。
微博:祝坤荣
B站: https://space.bilibili.com/23...
交换Email: zhukunrong@yeah.net