关于FB outage的一些分析

LZ是network相关从业者 有一些想法分享一下

FB为什么炸网上已经有很多解析，大家可以搜一搜。
大概就是facebook的BGP configuration出错导致fb的DNS record消失，
这样你去找facebook的IP地址就找不到了。


但是有趣的是，这次facebook炸了却波及到了好多其他网站。
所以这里我大概分析一下，为什么除了facebook其他的网站也被波及到。

一点点背景：
a. DNS解析器(DNS resolver)简单来说可以把域名(www.google.com)解析成IP地址(e.g. 142.250.64.68)，任何网站背后都是很多ip地址(根据request所在的位置找到对应服务器)。所以你的每一个网络请求都要先通过DNS resolver给你解析出来。
b. DNS服务器(DNS authoritative nameserver): 各大公司serve自己ip的地方，DNS解析器自己也不知道facebook.com的ip是什么，他要去问facebook的nameserver。

Process:
1. 从源头开始facebook BGP的configuration出错了，这样就会导致各DNS解析器(e.g. 8.8.8.8, 1.1.1.1, etc. 其实大部分人用的都是运营商自己的DNS解析器)无法找到facebook的DNS record。比如之前8.8.8.8问fb的nameserver "facebook.com的IP是多少啊？" fb的nameserver说 "x.x.x.x"。 现在8.8.8.8再问，fb的nameserver直接回复 "facebook.com不存在" 或者 "我现在炸了" (NXDOMAIN / SERVFAIL)。
2. DNS是用的UDP传输的，经常会有丢包packet loss或者其他问题比如上述“我炸了请重试”，所以各个解析器都会设置一些重试retry。因为找不到facebook的DNS record解析器们就会一直疯狂retry。
3. 因为FB的scale太大，而且是全球性的，大家越连不上facebook就会总点刷新，解析器们每次失败也会又重试很多次，这种巨大量的retry很多DNS解析器也承受不住。
4. Retry太多了DNS解析器们受不了会集体爆炸，这样所有网站的DNS解析都会收到影响。比如某个解析器在这个地区有100个task，各个task逐渐开始炸，比如50个炸了，所有剩余请求都积压到剩的50个了，这样load增加，速度就会变慢，到最后受不了了剩下的一起全炸了。(当然google的8.8.8.8只是小炸变慢了一点，但是小的DNS resolver就会炸的很严重，这也是为什么twitter上很多人说上不了网把DNS改成8.8.8.8就好了)。
5. 这样上任何网站都会变慢甚至无法连接，直到FB和DNS resolver们恢复。

非常有趣的是，这就是典型的蝴蝶效应，虽然看起来是只是facebook的bgp configuration出错了，但是差点炸掉了整个互联网。
假如几个facebook这么大体量的公司同时发生这种"小"错误，这样就能把全世界所有dns解析器炸掉，比如连google的8.8.8.8也无法幸免。整个互联网全都沦陷也是可能只是一瞬间发生的事。


补充内容 (2021-10-05 08:06 +8:00):
对DNS感兴趣的可以看一下https://www.cloudflare.com/learning/dns/what-is-dns/

补充内容 (2021-10-05 10:09 +8:00):
Cloudflare也发了关于这次事件的blog: https://blog.cloudflare.com/october-2021-facebook-outage/
感兴趣的可以看一下细节 大概和我这里说的差不多

补充内容 (2021-10-05 12:18 +08:00):
有很多人问关于retry的问题

其实这个retry来自于多方面 可以来自DNS resolver自己，也可以来自浏览器，也可以来自用户手动刷新，又或者是运营商中间的哪个layer。

举个简单的栗子：每一次facebook.com的request，DNS resolver自己retry3次，你用的chrome浏览器retry3次，加载不出来你非常着急自己再点浏览器refresh三次 这乘在一起就是3*3*3=27次。这还不考虑中间某些其他layer。

这仅仅是一次对facebook的request被放大了几十倍。这对于很多dns resolver简直是噩梦。于是纷纷承受不了就炸了。于是别网站的request也变慢，大家刷新的更多了，恶性循环。

有时候很多小东西经过乘积或指数放大有比预想要大得多且可怕的多的影响。

有点像缓存穿透的味道，很难想象DNS设计时没有考虑到这种情况。
随便开脑洞，可以想象的解决方案：
1. 缓存空结果，比如再有人问fb是啥就直接回答不知道
2. 指数延长retry间隔: 1s 4s 32s …

hesd10 发表于 2021-10-5 09:47
根据鄙人自学system design的经验，系统可靠性的提高靠冗余，Facebook不会没给自家的DNS服务器设计冗余吧？

应该不是FB自己家的DNS服务器引起内部炸掉，再连带外部一起炸的，可能是别的原因，造成全球用户ping个不停，接着公域几个根节点host里的那些服务器 overloaded，阻塞了。

wengjn 发表于 2021-10-4 14:51
归根到底还是fb的programmer leetcode题刷得不够啊，不然这种hard问题分分钟解决掉，嗯，对，一小时内两个h ...

你搞错了，就是因为全特么刷LeetCode去了，都不好好搞业务相关的知识，然后就悲剧了

System design: design a configuration to blow up the whole internet

一看就是不重视infra和security，三天两头爆雷，不是网崩就是数据泄露

感谢科普！读起来很有意思

浅显易懂的技术贴，感谢楼主分析！赞一个！

感谢分享！
请问DNS解析器没有自己的保护机制吗？比如同一个DNS服务器的请求不能超过自己capacity的百分之多少，来减轻这种情况

fb的system integrity有问题啊
怎么可以所有服务一起炸

补充内容 (2021-10-05 06:32 +08:00):
突然想到fb面试是不是要求bug free的？

所以楼主能估计一下啥时候修好吗

匿名者 发表于 2021-10-4 23:31
感谢分享！
请问DNS解析器没有自己的保护机制吗？比如同一个DNS服务器的请求不能超过自己capacity的百分之 ...

不都是UDP么，本质上保护不保护自己对询问者来说没有区别，有保护机制的话，在询问者看来你也是挂了。因为你不处理任何request

匿名用户 发表于 2021-10-04 14:38:47
不都是UDP么，本质上保护不保护自己对询问者来说没有区别，有保护机制的话，在询问者看来你也是挂了。因为你不处理任何request

不好意思没说清楚，我想问的是DNS解析器保护访问其他网站不受影响或者受影响小

归根到底还是fb的programmer leetcode题刷得不够啊，不然这种hard问题分分钟解决掉，嗯，对，一小时内两个hard问题没跑得