标准产品系列数据中心产品系列专业级产品系列安全产品系列标准产品系列标准产品系列标准产品系列标准产品系列AD产品系列规格图DDI-DHCP页(新版)NACS页面新版GSLB新版页面DIAS新版页面产品型号及规格图高可靠专用硬件应用交付 智能应用负载ZDNS-AD智能负载均衡(GSLB)网络核心设备分布式权威解析递归缓存解析DNS安全防护注册配置工作流智能解析 ( DNS )可视化地址管理旧DHCP页留存网络动态感知地址实名审计IPAM页面新版海量弹性数据报表业务导向报表运营大数据分析 ( AM )综合管理平台私有云虚拟化云管理和虚拟化ZDNS SafeguardDNS 云解析动态流量调度CDN BalanceDNS 云容灾全网管控ZDNS Cloud域名管家新通用顶级域名申请注册局安全锁TMCHSSLDPMLAdultBlockTLD注册局业务监测云注册商业务支撑云注册局业务支撑云注册局业务统计云DNE下载文件顶级域名云平台域名审核云企业域名资产管理云应用交付 智能应用负载ZDNS-ADIPAM旧版留存攻防演练解决方案性能优化-了解详情互联网安全混合云路由互联网行业解决方案本地化运营解决方案顶级域名解决方案大型企业解决方案教育行业解决方案广电行业解决方案新华社北京航空航天大学恒丰银行中国劳动关系学院华数传媒陕西师范大学泰康人寿中国石油信创产品中国民生银行大型企业金融行业解决方案广电解决方案教育行业解决方案政府行业解决方案大型企业解决方案服务保障培训认证在线学院公告信息已是合作伙伴售后工程师认证政策申请认证培训申请认证考试证书查询合作伙伴培训与认证解决方案技术资料ZDNS云学堂资源中心合作伙伴渠道政策前沿技术顶级域名手册行业研究行业标准100+专利软著招贤纳士联系我们news图片链接ZDNS客户psirt法律声明ZDNS大事记
新闻详情

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


_______________
_______________
_______________
_______________
友情互联:
________________________________________________________________________________________________________________________________
邮箱:support@zdns.cn
7*24小时客户服务
咨询电话:400-6688-876
标签:
请输入要描述的内容进行内容补充 请输入要描述的内容
01
03
请输入要描述的内容进行内容补充 请输入要描述的内容
_______________________________________________________________________________________________________________________________
互联网域名系统北京市工程研究中心有限公司 版权所有 © 2022 
官方微信
DNS 云解析
新顶级域直通车
________________________________________________________________________________________________________________________________