TLD glue 记录“逗留”过长？
2016 年 10 月 21 日，一起针对美国 DYN 公司的网络攻击让整个互联网大惊失色，其主要攻击目标是 DYN 负责运行的 DNS 系统，该系统承载着北美及欧洲大批量用户的域名解析服务，整个攻击过程历时近 12 个小时，使得使用 DYN 服务的用户蒙受了巨大损失，知名黑客组织 Anonymous 和 New World Hackers 声称对此次事件负责。
在此次事件中，有很多问题值得讨论，也不仅限于如何调整 DNS 系统的配置。又拍云作为一家 CDN 服务提供商，DNS 作为我们调度系统的一部分，我们必须要从网络层面以及协议层面增强 DNS 系统的防护能力，以便在未来某个时刻，能够抵御住类似 DYN 遭受的 DDoS 攻击。而在本篇博客中，我会阐述一个在 DNS 核心协议中容易被人忽略且不易理解的特性，可能这个隐蔽的特性现在无法立即利用起来抵御此类攻击，但事实上，只要相关机构做一下微小的调整，它就会变得极其有用。这个特性目前没有被利用起来，并非由于协议问题，而是因为那些 TLD（Top Level Domain，顶级域）服务商的冷漠以及无动于衷。如果这个特性能够利用起来，将会极大降低遭受 DDoS 攻击的 DNS 服务的恢复时间。
该特性就是我们本篇博文的主角：DNS TLD glue 记录（以下简称“glue 记录”，中文翻译大家可自行脑补
），更确切地说，是 glue 记录及其可自定义的 TLL。
glue 记录是 DNS 协议中最不容易理解以及最让人忽略的一个特性，请允许我阐述为何减少 glue 记录的 TTL 值能够带来如此巨大的益处。
但是首先，什么是 glue 记录？
Glue 记录
在 DNS 内部，glue 记录解决了类似“鸡生蛋蛋生鸡”的问题。让我举一个实际点的例子，来阐述这个特性。
假设我们访问又拍云的主页 https://www.upyun.com，浏览器会将针对域名 www.upyun.com 的 DNS 查询发往你本地配置的递归 DNS 服务器（一般为运营商提供，以下简称“递归服务器”），递归服务器发起多级迭代查询，最终将解析的结果返回给浏览器。那么递归服务器作为代替浏览器处理该 DNS 请求的解析器，它到底做了什么？
简单来说，递归服务器经过了如下流程：
- 本地无任何缓存；
- 向根服务器发起查询，获取到承载顶级域 com 相关数据的权威服务器的名称及地址，也即 com 的 NS 记录及其对应的 A 和 AAAA记录，其中之一是 a.gtld-servers.net 及其 IPv4 地址 192.5.6.30；
- 我们重点关注之后的步骤，也即递归服务器获取到 com 的 NS 记录及其地址之后，后续的迭代查询是如何进行的。
为了解析 www.upyun.com，递归服务器需要继续向顶级域 com 发起查询，获取 upyun.com 的权威服务器的名称及地址。我们模拟这个过程，以上文为例，向 192.5.6.30 发起请求：
dig @192.5.6.30 www.upyun.com
; [只显示关键信息]
;; AUTHORITY SECTION:
upyun.com. 172800 IN NS ns1.ialloc.com.
;; ADDITIONAL SECTION:
[后续内容先省略]
与根服务器的行为一致，我们在询问 com 的权威服务器 www.upyun.com 的解析结果时，它并没有给我们直接返回结果，而是将 upyun.com 的权威服务器的信息告诉我们，ns1.ialloc.com，也就是说 com 的权威服务器只知道 upyun.com 的权威服务器的信息，而并不清楚 upyun.com 的权威服务器所管理的该区域的数据，类似这样的行为，在 DNS 协议中，叫做“授权”。
继续查询，我们需要知道的是 ns1.ialloc.com 的 IP 地址是多少？按以上类似的查询流程，在查询 ns1.ialloc.com 的 IP 地址时，com 的权威服务器也只会告诉我们 ialloc.com 的权威服务器名称。
这样循环往复下去，就变成了一个“鸡生蛋蛋生鸡”的问题：为了解析 www.upyun.com，我们首先需要解析 ns1.ialloc.com，为了解析 ns1.ialloc.com，我们依然需要解析 ns1.ialloc.com，如此继续循环。
基于以上问题，DNS 协议就引入了 glue 记录这个概念。我在上文的演示请求中，隐藏掉了部分信息，实际上，ns1.ialloc.com 对应的 IP 地址，是直接由 com 的权威服务器给出的，附着于“ADDITIONAL SECTION”：
dig @192.5.6.30 www.upyun.com
;[只显示关键信息]
;; AUTHORITY SECTION:
upyun.com. 172800 IN NS ns1.ialloc.com.
;; ADDITIONAL SECTION:
ns1.ialloc.com. 172800 IN A 111.1.32.110
因此，如果需要打破这个循环，就需要在所谓的“ADDITIONAL SECTION”给出 ns1.ialloc.com 对应的 IP 地址。在此例中，com 的权威服务器响应我们：顺便告诉你们，你们需要的 ns1.ialloc.com 的地址，我放在了 ADDITIONAL SECTION，即 111.1.32.110。
这就是 glue 记录，从概念上来说，确实有点诡异。我们向 com 的权威服务器发起针对 www.upyun.com 的查询，在响应中，我们不仅获取到 upyun.com 的授权信息，也获取到了相应的 IP 地址。仔细想一下，是否好似 upyun.com 这个区域中管理的部分数据实际上是由 com 这个顶级域处理的！
更进一步考虑一下，是否能将其他非法内容随意插入到 ADDITIONAL SECTION？例如：
dig @192.5.6.30 www.upyun.com
;[只显示关键信息]
;; AUTHORITY SECTION:
upyun.com. 172800 IN NS ns1.ialloc.com.
;; ADDITIONAL SECTION:
ns1.ialloc.com. 172800 IN A 111.1.32.110
www.baidu.com 172800 IN A 1.1.1.1
这种方式的缓存注入或缓存投毒，曾经也使递归服务器中招过。递归服务器本身对于选取 glue 信息的过程也较为复杂，晦涩难懂，不同的递归服务器如 BIND、unbound 等方式也不同。概念上来说，合法的 glue 记录和这种缓存注入的相比，差异很小。针对这一问题，此处我们就不展开了，DNS 协议设计者们，有针对该问题的讨论，并形成了草案，draft-fujiwara-dnsop-resolver-update-00 以及 draft-weaver-dnsext-comprehensive-resolver-00，感兴趣的朋友可以研究下。
问题在哪里？
我们在上文已经解释什么是 glue 记录，它是怎么工作的，以及它为何会存在于 DNS 协议中。坦白地说，glue 记录真是个能够用来解决某个难题的灵巧设计。
我们再仔细看下 glue 记录：
;; ADDITIONAL SECTION:
ns1.ialloc.com. 172800 IN A 111.1.32.110
问题就在 TTL 值，在此处，是 172800 秒，为 48 小时。正常情况下，某个区的管理者是可以管理该区域的 glue 记录的。比如 upyun.com，48 小时绝非我们期望的以及实际配置的值，假如你直接请求 upyun.com 的权威服务器 ns1.ialloc.com，也即 111.1.32.110，你能够得到一个不同的 TTL 值，远小于 48 小时：
dig @111.1.32.110 ns1.ialloc.com
;; [只显示关键信息]
ns1.ialloc.com. 10800 IN A 111.1.32.110
可以看到，upyun.com 的权威服务器返回的 TTL 是 10800 秒，为 3 小时，那么这个差异到底从何而来？
glue 记录通常是由注册商（如万网、新网及 GoDaddy 等）提供管理，这很正常。我们向注册商提供 upyun.com 的 NS 名称及其地址。问题在于，注册商提供了设置 NS 及其 IP 的地方，但并未提供设置 TTL 的途径，glue 记录的 TTL 被 TLD 服务商强制置为 48 小时。
此种行为，可以说对处理我们文初提到的 DYN 遭受的 DDoS 攻击毫无益处。因为过长的 TTL 的存在，我们根本无法快速切换或提供更多的资源去处理攻击行为。
攻击处理
实际上，在 HTTP 层面，通过在 DNS 快速切换 CDN 边缘节点的覆盖，我们可以让绝大部分用户免受被攻击节点的影响，在极端情况下，我们甚至可以将攻击流量牵引至高防节点做清洗。
同样的，此种方式也应在三层的攻击中得到利用，在我们的 DNS 服务器遭受攻击时，我们也能快速将合法的请求迁移出遭受攻击的 DNS 节点。然而很不幸，我们目前根本无法去更改 TLD 服务商处我们本应能够控制的 glue 记录的 TTL 值。由于 glue 记录的 TTL 被固定为 48 小时，动态更改权威服务器 IP 的方式去抵御攻击，目前来看还无法利用起来。
但我相信，这理应得到改变！
总结
我们应当使用各种可能的手段，来使互联网基础设施 DNS 系统在遭遇诸如 DDoS 攻击时能够更加健壮，本文讨论的手段只是其中之一。
在本篇博文中，我解释了什么是 glue 记录，为何被 TLD 服务商限定死的 48 小时 TTL 对抵御 DDoS 攻击毫无益处。也希望我的意见能唤醒 TLD 服务商，利用这种简单而又高效的方式，使 DNS 系统更加可靠。