DNS解析原理:递归 VS 迭代

DNS解析流程分为 递归查询 和 迭代查询 ，递归查询是以本地名称服务器为中心查询， 递归查询是默认方式，迭代查询是以DNS客户端，也就是客户机器为中心查询。 其实DNS客户端和本地名称服务器是递归，而本地名称服务器和其他名称服务器之间是迭代。

“递归解析”（或叫“递归查询”，其实意思是一样的）是最常见， 也是默认的解析方式 。在这种解析方式中，如果客户端配置的本地名称服务器， （又称Local DNS， 可以是默认的运营商提供的Local DNS 或者自己设置的DNS） 不能解析的话，则后面的查询全由本地名称服务器代替DNS客户端进行查询，直到本地名称服务器从权威名称服务器得到了正确的解析结果，然后由本地名称服务器告诉DNS客户端查询的结果。

下图是windows下默认获取的运营商Local DNS或者 自己设置的Local DNS

在这个查询过程中，一直是以本地名称服务器（Local DNS）为中心的，DNS客户端只是发出原始的域名查询请求报文，然后就一直处于等待状态的，直到本地名称服务器发来了最终的查询结果。此时的本地名称服务器就相当于中介代理的作用。如果考虑了本地名称服务器的缓存技术（也就是在DNS服务器上对一定数量的以前查询记录保存一定时间，这样后面查询同样的域名信息时就可直接从缓存中调出来，以加速查询效率）的话，则递归解析的基本流程如下：

（1）客户端向本机配置的本地名称服务器（在此仅以首选DNS服务器为例进行介绍，所配置其它备用DNS服务器的解析流程完全一样）发出DNS域名查询请求。

（2）本地名称服务器收到请求后，先查询本地的缓存，如果有该域名的记录项，则本地名称服务器就直接把查询的结果返回给客户端；如果本地缓存中没有该域名的记录，则本地名称服务器再以DNS客户端的角色发送与前面一样的DNS域名查询请求发给 根名称服务器 。

（3）根名称服务器收到DNS请求后，把所查询得到的所请求的DNS域名中 顶级域名所对应的顶级名称服务器 地址返回给本地名称服务器。

（4）本地名称服务器根据根名称服务器所返回的顶级名称服务器地址，向对应的顶级名称服务器发送与前面一样的DNS域名查询请求。

（5）对应的顶级名称服务器在收到DNS查询请求后，也是先查询自己的缓存，如果有所请求的DNS域名的记录项，则相接把对应的记录项返回给本地名称服务器，然后再由本地名称服务器返回给DNS客户端，否则向本地名称服务器返回所请求的DNS域名中的二级域名所对应的二级名称服务器地址。

然后本地名称服务器继续按照前面介绍的方法一次次地向三级、四级名称服务器查询，直到最终的对应域名所在区域的 权威名称服务器 返回到最终的记录给本地名称服务器。然后再由本地名称服务器返回给DNS客户，同时本地名称服务器会缓存本次查询得到的记录项。

DNS客户端和本地名称服务器是递归，而本地名称服务器和其他名称服务器之间是迭代。

DNS递归名称解析 ： 在DNS递归名称解析中，当所配置的本地名称服务器解析不了时，后面的查询工作是由本地名称服务器替代DNS客户端进行的（以“本地名称服务器”为中心），只需要本地名称服务器向DNS客户端返回最终的查询结果即可。

DNS迭代名称解析 ：（或者叫“迭代查询”）的所有查询工作全部是DNS客户端自己进行（以“DNS客户端”自己为中心）。在条件之一满足时就会采用迭代名称解析方式：

通过图片看看他们的不同：

权威 DNS 是特定域名记录（例如“example.com”）在域名注册商处所设置的 DNS 服务器，用于特定域名本身的管理（增加、删除、修改等）。

权威 DNS 服务器只对自己所拥有的域名进行域名解析，对于不是自己的域名则拒绝访问。比如，向“example.com”的权威 DNS 服务器查询“test.com”的域名肯定会查询失败。

递归 DNS（也称本地 DNS 或者缓存 DNS）用于域名查询。递归 DNS 会迭代权威服务器返回的应答，直至最终查询到的 IP 地址，将其返回给客户端，并将请求结果缓存到本地。

对用户发出的域名解析请求，递归 DNS 必须给出一个最终的 IP 地址结果。完整的递归DNS 查询流程需要 DNS 服务器从根域名 “.” 服务器，顶级域名服务器（例如“.com”），一级域名服务器（例如“example.com”）等一级一级递归查询，直到最终找到权威服务器取得结果，并返回给客户。同时，递归服务器根据域名 TTL，缓存查询结果，便于相同域名重复查询。

递归 DNS 服务器大多数在运营商端，负责网络接入终端的 DNS 查询，即网络访问设备上配置的 DNS 服务器 IP。

递归 DNS 的访问过程如下图所示（递归 DNS 在图中表示为 Local DNS）：

https://www.alibabacloud.com/help/zh/doc-detail/60303.htm

https://www.zhihu.com/question/36891472

DNS（Domain Name System，域名系统）， 记录ip地址的分布式服务器。 DNS解析过程如图

全球13组根域名服务器以英文字母A到M依序命名。

域名系统默认的不用写

顶级域名服务器主要负责管理在该顶级域名服务器注册的二级域名。

列：

**举例: **

baidu.com 和 www.baidu.com

权威DNS服务器是经过上一级授权，对域名进行解析的服务器。(为了保障安全和保障一般权威DNS服务器都是俩)

查询过程

主机向本地域名服务器的查询一般都是采用递归查询

本地域名服务器向根域名服务器的查询的迭代查询

A记录：解析域名到指定ip

CNAME记录（Canonical Name 别名指向）：解析域名到域名

MX记录：指向一个邮件服务器，用于电子邮件系统发邮件时根据收信人的地址后缀来定位邮件服务器。

NS记录：解析服务器记录。用来表明由哪台服务器对该域名进行解析，这里的NS记录只对子域名生效。

优先级：NS记录优先于A记录。即，如果一个主机地址同时存在NS记录和A记录，则A记录不生效。这里的NS记录只对子域名生效。

TXT记录：为某个主机名或域名设置联系信息，如：

admin IN TXT “管理员, 电话： 1000000000”

AAAA记录(AAAA record)：是用来将域名解析到IPv6地址的DNS记录。用户可以将一个域名解析到IPv6地址上，也可以将子域名解析到IPv6地址上。

SRV记录：一般是为Microsoft的活动目录设置时的应用。

显性URL记录：访问域名时，会自动跳转到所指的另一个网络地址（URL），此时在浏览器地址栏中显示的是跳转的地址。

隐形URL记录：访问域名时，会自动跳转到所指的另一个网络地址（URL），此时在浏览器地址栏中显示的是原域名地址。

举例:

在线DNS解析网站

提升用户体验！ 两步走：

第一步

第二步

引子：

外网DNS是用户访问网站的第一道门，如果外网DNS调度不准确，会出现跨网，跨地域等问题，调度问题是外网DNS关注的首要问题。如何让用户就近接入？有没有好的设置方法可供参考？

调度问题直观的表现是VIEW设置多少个，ACL是否匹配正确。ACL设置一般企业会采购IPIP库的结果，国内基本可以得到正确的结果，海外的IPIP归属地也不会有很大的波动。如果请求能正常到达要访问的权威服务器，看似就万事大吉了。但是在观察业务数据的时候，发现问题并没有那么简单。

这是一个演变的过程，按照改进的过程叙述。

第一步：国内一般的方法是华北，华东，华南，三个地域建ns。海外选择离业务近的点建ns。中国和海外的ns设置不同的地址。自建权威服务器注册到DNS服务商。按照地域顺序往后排序。每个view配置相同的ns。认为DNS解析会按照最近的NS来请求。

问题：

前两台NS会收到很多访问的请求，用户的来源IP和之前给这个NS设定的覆盖范围也不一致，其他的NS请求量相对低。和用户分布的趋势不符合。

如果这样的话，即使分了ACL，也没有达到多个NS覆盖多个的问题。用户域名请求的时间仍旧很高。那么local DNS不是应该像很多NS同时发请求，然后选择一个就近的接入，以后就按照这个NS来请求吗？

当然不会，这样用户还需要在不同的NS上随机挑选，这样更加增加了local DNS的请求时间。

local DNS第一次解析域名的时候，ns的地址是由.com权威提供的，本地递归DNS最终是缓存权威DNS上的ns记录。.com权威提供的方式是通过glue记录。在注册域名的时候，需要额外填写。

glue记录是非常容易忽略的一个问题，应该搭建常规的DNSserver并不是必须的选项，因此常常会忽略，我也是在注意到问题之后，才发现对glue记录并不了解。

加入没有glue记录，local DNS拿到了请求之后，还要在询问NS地址是什么，

查看 www.baidu.com 的glue记录：

请求命令：

dig www.baidu.com

位于返回请求的ADDITIONAL SECTION中。

实验验证一下第一次请求的过程：

先来看一下请求的TTL值

第二次递减：

第三次递减：

变为0:

重新开始请求：

看下对应的抓包过程：

第一次请求的过程：

A.root-servers.net198.41.0.4美国

E.root-servers.net192.203.230.10美国

分别像这几个根存问结果：

首先像 J.root-servers.net192.58.128.30美国 询问，

给服务器回复了 *.gtld-servers.net的地址 .com顶级域

com回复之后，继续往下看：

com回复了baidu的ns

本地递归DNS最终是缓存权威DNS上的NS记录。

如果想实现按照NS调度，不同的View应该配置不同的NS地址，用户请求从com得到请求之后，再去查询NS ，就会按照NS配置的地址到想让他去的NS解析了。不足之处，第一次因为从glue拿地址，所以第一次没有办法实现智能解析

minimal-responses

如果是yes，当产生响应的时候，服务器将只会按照需要将记录添加到authority和additional的数据部分。（例如，delegations，negative responses）。这样会改善服务器的性能。默认值为no。

---