新闻详情

DNS云学堂 | 权威DNS那些事儿(中)

94
发表时间: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的方式来避开,附赠一大堆好处,此处略。(未完待续)


_______________
_______________
_______________
_______________
友情互联:
___________________________________________________________________________________________________________________
邮箱:web@zdns.cn
7*24小时客户服务
咨询电话:400-6688-876
标签:
请输入要描述的内容进行内容补充 请输入要描述的内容
01
03
请输入要描述的内容进行内容补充 请输入要描述的内容
___________________________________________________________________________________________________________________
京ICP备15027496号-3 | 京公网安备11010802021115号 | All rights reserved
扫码了解更多详情
DNS 云解析