新闻详情

DNS云学堂 | 权威DNS那些事儿（中）

1422

发表时间：2020-07-15 10:00作者：ZDNS

书接上回，在上一篇内容中重点剖析了互联网DNS体系及造成权威DNS变更复杂的主要原因，今天我们通过搭建实验环境，研究权威DNS的原理及细节。enjoy：

在介绍实验过程之前，先直接说结论，建议为权威NS记录变更预留2天时间是一个相对保险的建议值，可以确保全网绝大部分LocalDNS都会刷新。若超过这个时间后仍有问题，需要考虑其他可能的原因。实际上从工程经验看，域名变更后大部分ISP和Public DNS最多在1-2小时后就可以刷新。

P.S. 若需要变动的是edu.cn、gov.cn等结尾的域名，建议提前联系域名注册管理机构进行流程和手续的咨询，切记~

1. 基本原理及实验

之前的文章中，从互联网DNS体系并不能看出DNS的实际运行机制，因此我们首先搭建实验环境来进行模拟，在此基础上研究权威DNS的原理及细节。

1.1 搭建实验环境

实践是验证理论的唯一标准。很多人经过初步的学习后，对互联网DNS的体系有了一定的了解，但是不能解答之前的疑问，为什么DNS的收敛时间如此之长，问题出在哪个地方？每个环节的配置和参数对于整体的影响分别是什么？

带着这些疑问我们搭建了互联网DNS的模拟环境，由1台根DNS（兼职顶级域）、2台权威DNS和1台递归DNS组成。

所有DNS不做特殊设置，均为通用配置。测试的域名区域为test.com，配置NS记录及www域名记录。

测试根DNS配置根区及com顶级域：

com. 1800 IN NS ns.com.

ns.com. 1800 IN A 192.168.30.135

ns1.test.com. 660 IN A 192.168.30.136

test.com. 600 IN NS ns1.test.com.

ns2.test.com. 660 IN A 192.168.30.137

test.com. 600 IN NS ns2.test.com.

测试权威DNS配置test.com权威区域（记录相同TTL不同，便于识别）；

权威DNS 01：

test.com. 120 IN NS ns1.test.com.

ns1.test.com. 140 IN A 192.168.30.136

ns2.test.com. 140 IN A 192.168.30.137

test.com. 120 IN NS ns2.test.com.

www.test.com. 160 IN A 1.2.3.4

权威DNS 02：

test.com. 240 IN NS ns1.test.com.

ns1.test.com. 260 IN A 192.168.30.136

ns2.test.com. 260 IN A 192.168.30.137

test.com. 240 IN NS ns2.test.com.

www.test.com. 300 IN A 1.2.3.4

测试递归DNS将根服务器设置为测试根DNS，不使用默认的13个根；

测试客户端无特殊设置，使用DIG、NSLOOKUP等工具进行测试并抓包；

以上就是本次搭建的实验环境及其关键配置。

1.2 实验原理及路线

根权威、顶级域权威、二级及以上级域权威、递归是互联网DNS体系的组成部分，根权威包含1000多个顶级域NS记录，顶级域权威包含归属于其区域的二级域名权威DNS的NS记录，依次类推，而负责从各级权威获取信息直至完成域名解析的就是递归服务器。为了确保分级的、复杂的流程下信息的准确传递，DNS协议设计了很多保证措施，并最终由DNS软件来实现。

递归DNS会从不同级别的权威DNS上获取NS记录并发起迭代查询，直至最终获取到需要的域名记录的解析结果。在实际使用过程中，递归DNS会从上级权威获取下级权威的NS记录（包括记录名称和Gelu IP），同时也会从下级权威DNS获取其NS记录，这两个记录很可能是不一致的，这就是本次实验主要验证的内容。

实验步骤如下：

1) 在测试顶级域DNS上只配置test.com的NS记录ns1，指向测试权威DNS 01，并在权威DNS 01上也只配置ns1，在测试客户端上观察解析结果；

2) 在权威DNS 01上配置第二个NS记录ns2，等测试域名记录www.test.com过期后，在测试客户端上观察解析结果；

3) 在测试顶级域DNS上添加test.com的NS记录ns2，指向测试权威DNS 02，并关闭测试权威DNS01，等测试域名记录www.test.com过期后，在测试客户端上观察解析结果；

1.3 实验过程

首先清除递归DNS和操作系统上的缓存记录（不光递归DNS有缓存，还有浏览器缓存和操作系统(OS)缓存，不清除缓存可能会影响实验结果）。

在测试顶级域DNS上只配置test.com的NS记录ns1，指向测试权威DNS 01，并在权威DNS 01上也只配置ns1。测试客户端结果如下：

在权威DNS 01上配置第二个NS记录ns2，等测试域名记录www.test.com过期后，在测试客户端上观察解析结果如下：

在测试顶级域DNS上添加test.com的NS记录ns2，指向测试权威DNS 02，并关闭测试权威DNS01，等测试域名记录www.test.com过期后，在测试客户端上观察解析结果如下：

上述测试为连续测试，每次均等待 www.test.com的A记录过期后重新进行查询。

1.4 实验结论及分析

由该实验可得出以下推论：

本实验中递归DNS最终使用从本级权威DNS上获取的NS记录TTL，并以此为准。实际上有一个更贴切的说法是以上级权威和本级权威的TTL最小值为准。实验中是本机权威配置的NS记录TTL小于上级权威的NS记录TTL，反过来的话效果如下：

在上级权威和本级权威的NS记录配置不一致时，以本级权威的NS记录为准。（例如实验中上级权威未配置ns2但本级权威DNS上有配置ns2，且被递归DNS获取并使用）
递归DNS上的NS记录过期后，一旦有不命中缓存的查询出现，递归DNS会到上级权威开始重新查询该区域的NS记录。命中缓存的查询则直接回复，不会去上级权威查询更新NS记录。下图为命中记录缓存的查询效果。
上级权威服务器中，变更域名的NS记录生效后，最长不超过本机权威的NS记录TTL时间，递归DNS就会更新该域名的最新NS记录。

那么是不是我们可以选择不改注册NS记录直接改权威DNS就可以了呢？答案是否定的，测试的话在确保记录一致性的情况下可以这么做，但正式变更还是要按照先增后减的原则来进行，要的就是一个字，稳。

递归DNS有一个很复杂的运行机制，而且每个不同的递归DNS软件甚至不同版本都会有细微的差距，再加上权威DNS的配置差异（例如是否开最小应答）、LAME Server（简单来说就是对权威NS的主动标记拉黑机制）、DNS缓存强制修改（有些流氓DNS会这么干）、递归强制解析等因素，按照上述结论去使用是不太稳的。

特别是一旦注册的NS记录不能用时，等同于全部NS故障，权威DNS服务将会中断，所有在线业务会受到很大影响。

而一旦错误配置的权威NS记录或域名记录在互联网DNS体系中扩散，Hmm……那种等待收敛的无力你感绝对不会想体会第二次。虽然可以通过刷ISP的递归缓存的方式快速收敛，但这个方式的使用难度和费用是个问题。
1.5 从试验结果展开的一点小思考
实验中的模拟结构是一个理想模型，但是在实际的互联网上，在递归DNS下面往往还有其他的LocalDNS，如转发服务器、缓存服务器等，那么这个TTL时间传递到客户端后可能跟权威的设置没有什么太大关系，此时传递给最终客户端的TTL主要取决于这些DNS服务器的配置。比如最小TTL的限制为3600秒，即便该DNS服务器从递归DNS上查询到的域名记录TTL只剩30秒，也会被强制修改为3600并返回给查询者。
1.5 从试验结果展开的一点小思考

实验中的模拟结构是一个理想模型，但是在实际的互联网上，在递归DNS下面往往还有其他的LocalDNS，如转发服务器、缓存服务器等，那么这个TTL时间传递到客户端后可能跟权威的设置没有什么太大关系，此时传递给最终客户端的TTL主要取决于这些DNS服务器的配置。比如最小TTL的限制为3600秒，即便该DNS服务器从递归DNS上查询到的域名记录TTL只剩30秒，也会被强制修改为3600并返回给查询者。

这个场景并不少见，ISP和Public的DNS大部分都是递归缓存分离的，再加上二级运营商或企事业单位自建的DNS采用全区转发的查询策略（降低服务器负载），最终从客户端到权威DNS服务器之间可能有3个或以上的DNS服务器，此时这个TTL生效时间跟权威的设置会有很大的区别。60甚至更小的TTL也是这样！如果不能容忍这个问题，APP类的应用可以选择使用HTTP DNS的方式来避开，附赠一大堆好处，此处略。（未完待续）