2.3 域名解析环节实践

2021 年期间互联网发生了几起影响颇大的服务宕机故障：7月22日 Aakamai Edge DNS 故障，造成 PlayStation Network、HBO、UPS、Airbnb、Salesforce 等众多知名网站宕机^1。不久之后的10月4日，社交网络平台 Facebook 及旗下服务 Messenger、Instagram、WhatsApp、Mapillary 与 Oculus 发生全球性宕机^2。

这些故障是怎么引起的？影响范围为何如此广泛？带着这些问题，我们开始域名解析篇节。

2.3.1 域名解析的工作原理

域名解析靠的是 DNS，我们在浏览器输入一个域名时，DNS 负责将该域名解析为相应的 IP 地址，以便后续与目标服务器建立 TCP/IP 连接。探寻 DNS 工作原理之前，我们先了解域名的结构。如图2-2所示，域名是一种树状结构，最顶层的域名是根域名（注意是一个点“.”，它是 .root的含义），然后是顶级域名（top-level domain，简写 TLD），再是一级域名、二级域名、三级域名。

图2-3 DNS域名结构

了解域名结构之后，我们再看看域名时如何进行解析，DNS 解析流程如图2-4所示。

图2-4 DNS解析流程

  • 用户向 DNS 解析器（也称为递归解析器，例如电信运营商的 114.114.114.114）发出解析 example.com 域名请求。
  • DNS解析器 判断是否存在解析缓存，如存在返回缓存结果。如无则就近向 Root nameserver (根域名服务器)请求所属 TLD 域名服务器。
  • 获取 com.域的 TLD 域名服务器后， 向该地址请求 example.com. 的 权威解析服务器（Authoritative nameserver）。
  • 得到权威解析服务器地址后，向该服务获取域名对应的 IP 地址，域名解析过程结束。

DNS 解析流程中有两个环节容易发生问题：一个是 DNS 解析器存在较多中间环节容易出现解析污染或者 DNS 解析器宕机，这种情况会导致域名解析出现局部不可用；另外一个是权威解析服务器出现故障，这种情况会导致全局域名解析不可用，但出现故障的概率极低。

下面我们继续看看如果 DNS 解析出现故障了该如何排查。

2.3.2 DNS 故障排查

如果碰到服务不可用、Unknown host 等错误时，我们可以先用几个运维命令确认是否为 DNS 解析阶段出现问题。

  1. 使用 nslookup 命令

第一个介绍的是 nslookup 命令，该命令用于查询 DNS 的记录、域名解析是否正常等。

nslookup 命令示例：

$ nslookup thebyte.com.cn        
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	thebyte.com.cn
Address: 110.40.229.45

返回信息说明：

  • 第一行的 Server 为当前使用的 DNS解析器。
  • Non-authoritative answer 因为 DNS 解析器只是转发权威解析服务器的记录，所以为非权威应答。
  • Address 为解析结果，上面的解析可以看到是一个A记录 110.40.229.45。
  1. 使用 dig 命令

nslookup 返回的结果比较简单，如果想获取更多的信息，可以尝试使用 dig 命令。

dig命令示例：

$ dig thebyte.com.cn

; <<>> DiG 9.10.6 <<>> thebyte.com.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63697
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;thebyte.com.cn.			IN	A

;; ANSWER SECTION:
thebyte.com.cn.		599	IN	A	110.40.229.45

;; Query time: 14 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri May 12 15:22:33 CST 2023
;; MSG SIZE  rcvd: 59

返回信息说明：

  • 第一段 opcode 为 QUERY，表示执行查询操作，status 为 NOERROR，表示解析成功。
  • 第二段 QUESTION SECTION 部分显示了发起的 DNS 请求参数，A 表示我们默认查询 A 类型记录。
  • 第三段 ANSWER SECTION 部分为 DNS 查询结果，可以看到 thebyte.com.cn. 的解析结果为 110.40.229.45。
  • 最后一段为查询所用的DNS解析器、耗时等信息。

Facebook 2021年10月宕机故障中，使用 dig 排查各个公共DNS解析器，全部出现 SERVFAIL 错误，这说明是权威解析服务器出现了问题。

➜  ~ 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
..

^1: 参见 https://www.akamai.com/blog/news/akamai-summarizes-service-disruption-resolved
^2: 参见 https://en.wikipedia.org/wiki/2021_Facebook_outage

2.3.3 Facebook 故障分析总结

这一节我们了解 Facebook 的故障的原因以及给我们的警示。

Facebook 此次故障发生在 2021 年 10 月 4 日，故障绕过了所有的高可用设计，故障期间 facebook、instagram、whatsapp 等众多服务出现了长达接近 7 个小时宕机，影响范围之深以至于差点产生严重二次故障，搞崩整个互联网。如此大规模服务的瘫痪不是 DNS 就是 BGP 出了问题，非常巧，这次是两个一起出了问题。

图2-5 Facebook宕机

Facebook 官方在故障后续发布原因总结是：运维人员修改 BGP 路由规则时，误将 Facebook 的 AS32934（Autonomous System，自治域）内的权威解析服务器的路由给删除了。这个操作的直接后果就是所有请求 Facebook 域名的解析请求都会丢弃在网络路由中，世界各地 DNS 解析器都无法再正常解析 Facebook 相关的域名。

1.故障现象

故障期间使用 dig 查询 Facebook 域名解析全部出现 SERVFAIL 错误，根据我们前面的结论，这是权威解析服务器出现了故障，这个故障影响范围就大了，世界上所有的 DNS 解析器都不会再正常返回 Facebook 域名的解析结果。

 ➜  ~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com.            IN    A
➜  ~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com.            IN    A

因为 Facebook 用户太多了，用户无法正常登陆 APP 时会疯狂地发起重试。如图 2-6 所示，CloudFlare 的 DNS 解析器（1.1.1.1）请求瞬间增大了 30 倍，如果 1.1.1.1 宕机，恐怕整个互联网会出现相当一段时间不可用。

图2-6 cloudflare 监控到 Facebook 故障时期的请求数

故障从美国东部标准时间上午 11 点 51 分开始，最终六个小时以后才恢复。

2.运维操作的警示

一些关键的运维操作具有很大风险，例如更改 BGP 通告、修改路由、修改防火墙策略等。此类的操作如果产生失误，有可能造成远程连接无法再使用，这个时候想远程修复就难了，只能接近物理机才能处理。

对于这种在生产环境中很大风险性的操作，可以引用一种个二次提交的策略。例如，修改一个 iptables 规则，修改之后引入 10 分钟观察期，观察期结束后，系统自动恢复原来的配置，运维人员确认观察期内数据没有任何问题之后，再执行正式的操作。

3.故障总结

这次故障实际上 BGP 和 DNS 一系列设计缺陷叠加，从而放大了故障影响：

  • 运维人员发布了错误的 BGP 路由公告。
  • 恰巧 Facebook 的权威解析服务器的 IP 包含在这部分路由中。

这就导致域名解析请求无法路由到 Facebook 内部网络中。由于 DNS 出现问题，运维人员很难再通过远程的方式修复，只能是修复团队紧急跑到数据中心修复，这就是此次故障范围、时长影响巨大的原因。

Facebook 这次故障带给我们以下几点关于 DNS 服务的思考：

  • 部署形式考虑：可选择将 DNS 服务器节点全部放在 SLB（Server Load Balancer，负载均衡）后方，或采用 OSPF Anycast 架构等部署形式，从而提高 DNS 系统的可靠性。
  • 部署位置考虑：可选择数据中心自建集群 + 公有云服务混合异构部署，利用云的分布式优势进一步增强 DNS 系统健壮性，同时提升 DNS 系统在遭受 DDoS 攻击时的抵御能力。

如图 2-7 所示，亚马逊 amazon.com 和 facebook.com 的权威域体系对比，amazon.com 的权威解析服务器分散在不同的 AS 内，所以它的抗风险能力肯要强于 Facebook。

图2-7 amazon.com 与 facebook.com 域名结构对比

2.3.4 使用 HTTPDNS

解决权威解析服务器的问题之后，我们再回过头看看 DNS 解析器（也就是 LocalDNS）的问题。

当我们发出域名解析请求时，会先连接到运营商就近的 DNS 解析器，由这个服务器帮我们去整棵 DNS 树上进行解析，然后将解析的结果返回给客户端，但是本地的 DNS 解析器，往往有自己的“小心思”。一个最令人头痛的问题就是域名劫持，其他还存在延迟、调度不精准等问题。传统域名解析面临的诸多问题与挑战本质根源在于 Local DNS 服务经历了过多的中间环节，服务质量不可控，如果能绕过中间环节，设计一个更安全、直接、高效的 DNS 解析服务，上述问题看起来就可以彻底地得到解决。

HTTPDNS 模式在这样的背景下应运而生。

简而言之，HTTPDNS 就是使用 HTTP 协议直接向 DNS 的权威解析服务器进行请求，从而获取域名对应的 IP 地址。HTTPDNS 跳过默认系统 DNS 解析的过程，使用 HTTP(S) 协议绕过运营商的 Local DNS，从而避免域名劫持，也更准确地判断客户端地区和运营商，得到更精准的解析结果。

图2-8 HTTPDNS 模式下 DNS 解析流程

使用 HTTPDNS 配合客户端策略（预解析、懒加载等），可以实现低解析延迟的域名解析效果。在笔者的实践中，移动端产品使用 HTTPDNS 服务，初次请求延迟约下降 25% 左右，之前各类的劫持、页面无法打开报障也大幅下降。


  • 无标签
写评论...