DNS应从何谈起篇一---从Facebook的故障谈起
本文写于2021年11月01日，于公司内部平台分享，脱敏后发布在云加社区。
导语 涉及DNS相关的概念词汇非常多，很多技术从业人员朗朗上口的比如于域名劫持，又或者运营商劫持，国内哪里哪里部署了根镜像，域名注册，域名备案，域名解析异常，DNS 放大攻击，随机子域名攻击，DNS故障了，DNS又故障了等等等等。 在确定我们应当如何去谈DNS的标题的时候，我还没想好该系列文章应当以何种逻辑出现，是从递归到根域名服务器到TLD服务器到权威服务服务器还是从域名是什么，DNS是什么，一个网站的访问等等逻辑去开始去谈。思来想去，随着Facebook 六小时断网故障的发生，我想先从故障开始，通过多起故障了解DNS分层访问体系，待对DNS分层体系有了了解后，我们在一点点去填充里面的知识点；
本篇文章的主角是图一的Auth DNS;
故障一：20211004 Facebook六小时中断
2021年10月4日，FB例行维护做全球骨干网容量评估的操作时无意中断了网络连接，且内置审计工具触发bug未能阻止命令执行，FB的Auth DNS会在无法连接数据中心时关闭BGP广播，Auth DNS服务异常后，很多内部工具无法正常工作，工程师无法远程修复，最终造成了6小时的停机；
Auth DNS，全称为authoritative nameserver，我们叫他权威DNS、权威域名解析服务器、或者权威服务器都可以，如果我们将com称为一级域名，那么权威服务器里面存储的就是二级域名以及其子域名对应的信息，比如qq.com,facebook.com等域名对应的子域名的解析记录就是存储在该服务器,我们可以通过linux自带的dig工具获取到域名对应的权威服务器是哪些，也可以用互联网上的一些工具来获取域名对应的权威服务器；这里我们通过 dnslookup facebook.com可以看到如下：
name TTL record type value
a.ns.facebook.com. 172800 A 129.134.30.12
a.ns.facebook.com. 172800 AAAA 2a03:2880:f0fc:c:face:b00c:0:35
b.ns.facebook.com. 172800 A 129.134.31.12
b.ns.facebook.com. 172800 AAAA 2a03:2880:f0fd:c:face:b00c:0:35
c.ns.facebook.com. 172800 A 185.89.218.12
c.ns.facebook.com. 172800 AAAA 2a03:2880:f1fc:c:face:b00c:0:35
d.ns.facebook.com. 172800 A 185.89.219.12
d.ns.facebook.com. 172800 AAAA 2a03:2880:f1fd:c:face:b00c:0:35示例二：Facebook权威服务器
facebook.com的权威服务器是由4个ipv4和4个IPv6的地址组成的一组权威，这里看到的IP是通过BGP Anycast的方式在全球多个点进行的同一IP播布，BGP Anycast的一个好处就是，当探测到单点故障时，可以通过路由取消的方式完成故障点的下线，实现故障的隔离。这组权威服务器除了托管facebook.com这个二级域名外，还托管了很多facebook其他的二级域名，比如intagram.com、fb.com、m.me、fb.me、保护性注册的域名facbook.com【没有e】、intagram.com【没有s】等等几千个二级子域名;以facebook.com二级域名后缀为例，公网暴露的域名其约四万个，eg
Domain
facebook.com
web.facebook.com
developers.facebook.com
de-de.facebook.com
l.facebook.com
apps.facebook.com
business.facebook.com
en-gb.facebook.com
ja-jp.facebook.com
es-la.facebook.com
fr-fr.facebook.com
it-it.facebook.com
es-es.facebook.com
pt-br.facebook.com
new.facebook.com
zh-tw.facebook.com
id-id.facebook.com
...示例三：facebook.com子域名
本次故障对facebook Auth DNS造成的影响是整个Auth DNS IP无法被正常路由，就是说，示例二中的所有DNS服务器均无法返回示例三facebook.com的子域名对应的解析结果，造成了影响的进一步扩大；上文讲到，这些权威IP是由全球多个点共同播布的IP发布出来的，单点故障后通过取消路由播布的方式即可完成故障点的隔离，那么为什么故障会发生呢？
基于光纤修复，容量扩容，软件更新等场景，Facebook的网络管理员需要主动做下线部分主干网络的模拟，在10.4号的模拟中，内置的审计工具触发bug,未能阻止到一些预期需要阻止的命令的运行，导致数据中心同互联网的网络断开；AuthDNS 触发了故障隔离机制，取消了自身播布的路由。
这时候，facebook.com相关域名TTL在Localdns里的缓存时间到期之前，解析是正常的，但一旦TTL到期，LocalDNS需要通过迭代的方式获取IP时，就会出现解析失败的情况了，排查和解决此类网络问题的工具，最终依赖了该权威服务器，导致也无法通过工具实现问题的快速解决。于是需要到现场，现场的物理安全鉴权、相关权限的确认，都使得故障时间延长。由于网络故障导致的AuthDNS 的下线使得这次问题影响加剧，Instagram和whatsapp主站的的接入层IP也在Facebook网内，因此也收到了牵连。
通过该故障，我们反思Tencent Auth,以及如何设计一套健壮的权威解析服务器；
从网络层面，Tencent Auth DNS server三网多地多活部署，通过腾讯自有as国内45090、海外132203+国内三网静态部署，多地域+跨运营商的部署方式相对健壮，类似fb自有as路由消失问题，我们通过跨运营商，多as做权威播步，即使单一as下路由从互联网消失，对腾讯权威服务的影响可控，可通过跨网权威临时恢复本网权威故障，当前三网静态按城市做路由汇总，理论网络层面不会出现全量路由汇总到单个网络实体导致的故障。解析软件层面，暂时未想到现网组件出现全部自杀掉的情景；
name TTL record type value
ns1.qq.com. 172800 A 101.89.19.165
ns1.qq.com. 172800 A 157.255.246.101
ns1.qq.com. 172800 A 183.36.112.46
ns1.qq.com. 172800 A 203.205.220.251
ns1.qq.com. 172800 AAAA 2402:4e00:8030::115
ns2.qq.com. 172800 A 121.51.160.100
ns2.qq.com. 172800 A 123.151.66.78
ns2.qq.com. 172800 A 203.205.249.143
ns2.qq.com. 172800 AAAA 2402:4e00:8010:1::11c
ns3.qq.com. 172800 A 112.60.1.69
ns3.qq.com. 172800 A 183.192.164.81
ns3.qq.com. 172800 A 203.205.195.94
ns4.qq.com. 172800 A 125.39.46.125
ns4.qq.com. 172800 A 203.205.195.104
ns4.qq.com. 172800 A 203.205.221.79
ns4.qq.com. 172800 A 58.144.154.100
ns4.qq.com. 172800 A 59.36.132.142示例六：qq.com权威
那是不是说，Tencent Auth就不受网络层面和控制层面的影响了，当然不是，上述的结论只是针对Facebook遇到的问题而言，接下来我分别从网络和软件层面，讲下Tencent Auth近期的两起故障。
故障二：20210405联通大网Tencent Auth 域名解析超时---见内部分享
故障三：域名解析异常导致腾讯新闻列表1小时打开失败---见内部分享
这里还有很多权威DNS的故障，比如2016年10月21日，美国域名供应商DYN的DNS网络遭受DDOS攻击，导致美国网络大范围瘫痪；2020年7月16日，CloudflareDNS服务器故障导致国内外大量网站无法正常解析访问；2021年7月22日，Akamai DNS故障，导致Fnac、Amazon云服务等2w多个大型网站瘫痪；我们通过故障一Facebook的故障，看出AuthDNS对网络的依赖和DNS解析服务对业务的影响，我们通过故障二联通解析异常得出，我们虽然做了多地跨网部署，但人为的因素对服务的影响也是重大的，我们也发生过单一网络下的解析故障；通过故障三，可以看到权威服务软件本身，对权威服务的影响也是巨大的。AuthDNS在DNS体系中的重要性也不言而喻；
通过上述故障，我们对Auth DNS做一个简单的定义，包含特定的二级域名及其子域名的信息（大部分是如此，亦存在子域名单独授权的权威服务器），在Localdns查找IP地址过程的最后一个环节（图例一）。facebook.com的authdns存储facebook.com域名以及相关子域名，还包括了Facebook(现在应该是Meta)下的其他二级域名；qq.com的authdns存储qq.com域名以及其他Tencent 二级域名信息。百度、阿里、腾讯都是通过自研的方式实现权威域名的托管，除了腾讯自营外部域名托管使用了自研的GSLB外，腾讯内部自研authdns的团队还有DNSpod,为外部互联网企业提供域名托管服务，比如mi.com、bilibili.com;令人欣喜的是，meituan.com除了使用了DNSPod托管外，还加入了自研权威服务器，AUTH DNS从业者的公司选择加一。还有架平的TDNS团队，结合CDN业务调度的需求，通过聚合运营商Ldns以及CDN节点的资源情况返回理论最佳调度。
mi.com. 172800 IN NS ns3.dnsv5.com.
mi.com. 172800 IN NS ns4.dnsv5.com.
-----
bilibili.com. 172800 IN NS ns3.dnsv5.com.
bilibili.com. 172800 IN NS ns4.dnsv5.com.
------
meituan.com. 172800 IN NS ns3.dnsv5.com.
meituan.com. 172800 IN NS ns4.dnsv5.com.
meituan.com. 172800 IN NS edns1.sankuai.com.
meituan.com. 172800 IN NS edns2.sankuai.com.最后，简单的升华。
一方面DNS是健壮的，DNS作为互联网的核心基础设施，从最初局域网内主机名到IP的映射发展到如今资源调度，服务入口，为全球近四亿个二级域名提供解析服务；一方面DNS也是脆弱的，树状的分层体系开放了边界，引入了不同的网络实体，随着单一实体的发展和壮大，单一实体服务的灾难产生的影响是巨大且不可控的；无论是从宏观上十四五规划对建设数字中国，布局关键信息基础设施的要求，还是微观上业务对DNS的依赖，都能体现DNS的重要性；通过一系列的文章，希望各位老板了解DNS，重视DNS，真正的防患于未然。
