新闻详情

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

1075

发表时间：2020-07-15 09:48作者：ZDNS

说到DNS，对于网络工程师来说并不是一个陌生的领域，但仍然常会有人问诸如权威DNS变更怎么做比较好、怎么设计更合理之类的问题。

这是因为对于大多数人来说，DNS只是一个不知不觉每天都在使用的网络服务，对它的认知仅仅停留在冰山水面之上可见的部分。而之所以出问题或有疑惑，其实主要是涉及到了水面下的领域——这部分知识相对冷门，且涉及到标准规范与落地运行的偏差，因此情况复杂多变。

对于整个DNS体系来说，水面下的部分非常庞大，要全部搞清楚非一日之功，所以互联网域名系统国家工程研究中心（ZDNS）的工程师们开启了“DNS云学堂”栏目，分享DNS相关基础知识、使用技巧、问题对策、典型案例、技术趋势等。今天带来第一期内容，分享权威DNS那些事儿。enjoy：

tips：

在讲解具体知识之前，有一些术语和原理需要先简单介绍一下：

注册局：

域名注册局是管理顶级域名的组织。他们创建域名后缀，设置域名规则，并与注册商合作向公众出售域名。例如，VeriSign 管理 .com 域名及其域名系统 (DNS) 的注册，CNNIC管理 .cn 域名及其域名系统 (DNS) 的注册。

注册商：

注册商是经认证可向公众销售域名的组织，如万网、DNSPOD、新网、ZDNS等。每个注册商可注册的域名后缀有可能不同，是因为注册商需要与注册局对接以便开展对应后缀的域名注册等业务，未对接不可注册对应的域名。

顶级域名：

.com、.cn、.net、.org、.fans、.ren等称之为顶级域名，及URL域名部分中最后的那个部分，由对应的注册局进行数据维护。

二级域名：

这个就是我们常用的域名，比如baidu.com、taobao.com等均视为二级域名。

权威NS记录：

域名服务器记录，用来表明由哪台服务器对该域名进行解析。注册域名时，需要指定由哪些DNS服务器来为该域名提供域名解析服务，若不指定，默认一般由注册商的DNS服务器提供免费的域名解析服务。

注册生效时间：

REGISTER_TIME，变更NS记录时，需要向注册商提出申请，由注册商平台通过私有协议向注册局递交变更数据，注册局方面收到数据后不是立即生效，有可能需要通过审核、校验、窗口期等环节才会在顶级域数据库中进行变更，因此该时间有可能是几分钟，也有可能是1-2天，工程经验值最长不超过两天。

NS缓存时间：

NS_TTL，分为上级权威指定和本级权威配置两种，一般是指本地权威DNS上配置的NS记录对应的TTL值（单位是秒，以下同）。

这两个值在实际环境中往往不相同，以zdns.cn为例，在上级权威指定的TTL为86400秒（2天），本地权威的TTL则为3600秒。这个值是递归DNS是否再次从根开始迭代查询的重要依据，其缓存的某域名区域的NS缓存过期后，再次向递归DNS查询该区域的非已缓存记录时，递归DNS开始新一轮的迭代查询。

下图为非托管域名的解析查询，NS缓存时间为3600秒，上级权威（顶级域权威.cn）指定时间为86400秒。

托管域名也类似，下图为吉利汽车的域名查询，托管在DNSPOD，其NS缓存时间为86400秒，上级（顶级域权威.com）指定为172800秒。

1. 互联网DNS体系剖析

支撑互联网DNS运行的体系很复杂，大致可以分为两类：

一类就是我们熟知的互联网域名解析体系，包括13个根权威、顶级域名权威、二级及以上域名权威、递归服务器等。

另一类就是一套不那么为人熟悉、也不是完全在线自动化的域名注册管理体系，包括ICANN、注册局、注册商等等，这个领域相对是比较冷门的，也是导致出现本文开头提到的那些现象的原因。

除了这种相对冷门的知识以外，还有一个主要的因素需要我们高度重视，那就是——现行互联网DNS体系的很多实际落地方式和我们理解的DNS体系原理并不是完全匹配。

DNS有很多称之为草案或建议的技术在现网运行（比如EDNS），而且各种DNS软件的DNS实现机制也不尽相同，再加之部分运营商出于各自的考虑，其递归DNS往往会强制缓存域名记录并忽略TTL值，导致经常出现与技术原理不太相符的现象。

所以当变更权威NS这类的行为出现各种奇葩现象时，不要怀疑自己——“错的不是你，是世界”。

1.1 域名解析体系

1.1.1 标准互联网域名解析流程

这就是我们熟知的互联网域名解析体系。以zdns.cn为例来说明互联网解析的正常流程。（递归与迭代：从客户端到客户端配置的DNS服务器的查询过程称之为递归，从递归服务器开始的各级查询称为迭代查询）。

从图中可以看到，递归DNS的每一次迭代查询都会缓存从各级权威DNS获得解析结果，以便在下一次查询相同域名区域的不同记录时，不再从根服务器开始迭代查询，而是从缓存中查找对应域名区域的NS记录，直接向该域名区域的权威DNS进行查询，以提高解析速度（比如缓存ZDNS权威的NS记录后，再查询cloud.zdns.cn时，不再重新从根查询，而是直接向zdns的权威DNS进行查询，提高效率）。

试想一下，如果递归DNS修改了从各级权威DNS获得的结果，是不是会出现与标准解析流程不同的现象？是的，这就是权威DNS变更时经常出现各种花样现象的原因之一。

1.1.2 多权威DNS的可靠性机制

天有不测风云，为了确保权威域名解析服务的正常，避免在线业务的第一个关键环节的故障，在实际的生产环境中，往往会建立多个权威DNS服务器对应多个NS记录，来提高服务的可用性。

权威DNS的NS记录数量，ISC的推荐是2个以上，6个以下（低于该区间意味着单点故障的可能性，高于该区间意义不大，性价比不高）。

递归DNS（比如BIND）在获知某个域名存在多个NS记录时，自身有一个机制(RTT)对这些NS记录对应的服务器进行探测和排序，以决定使用哪个。每次查询失败，都会导致延迟增加作为惩罚，降低其优先级，进而选择另外一个NS记录对应的服务器进行查询。上图是一个简化的RTT机制，帮助理解这个机制的运行原理，实际的RTT机制比较复杂，这里不再赘述。

P.S.：每个NS记录建议对应一个IP地址，原因是若同时对应多个IP时，其中一个IP的故障可能会导致递归DNS认为该NS记录异常，即便其他IP仍可正常提供服务，从而达不到设计的预期冗余效果（起码BIND是这么个机制）。

1.2 域名注册体系

域名注册系统同样是一个分布式系统，这也就意味着作为域名的最终拥有者，是这个注册链条的末端环节，需要一级一级的向上办理业务，而不能跨级办理。

打比方来说，注册或变更zdns.cn的域名需要以下流程：

1. 想注册zdns.cn的域名，需要找一个有.cn注册资质的注册商，在该注册商的平台上进行信息填写及注册。