前面我们曾经提到了一些有关递归查询的内容，但说的很少，也很笼统，本节将会从原理和实例两方面入手分析DNS的递归以及迭代查询。
在此之前，我们需要了解一些背景知识，以便于更好的理解今天的主题内容。
在互联网中，一个域名的顺利解析离不开两类域名服务器，只有由这两类域名服务器可以提供“权威性”的域名解析。
第一类就是国际域名管理机构，也就InterNIC，主要负责国际域名的注册和解析，第二类就是国内域名注册管理机构，在中国就是CNNIC了，主要负责国内域名注册和解析，当然，尽管分为国际和国内，但两者一主一辅，相互同步信息，毕竟最终的目的是在全球任何一个有网络的地方都可以顺利访问任何一个有效合法的域名，其间的联系就可见一斑了。
有的朋友可能会有这个疑问，域名服务器不是有很多吗？为什么说只有2类呢？是的，ISP何其多？当我们输入某一网址（或域名），系统将这个域名发送至需要将其当前已配置的DNS服务器，以便转换为IP地址进行访问，通常会是当地的公共DNS服务器（内网环境可能直接提交到防火墙或路由器上做进一步转发处理）。公网DNS服务器收到此请求后，并非立刻处理，比如转发至上一级的DNS服务器（在第一节讲过DNS有着很严格的逻辑层次关系），而是首先会查看自己的DNS缓存，如果有这个域名对应的IP，则直接返回给用户，系统收到这个IP后交给浏览器做进一步处理。在这个轮回的过程中，客户端所得到的DNS的回复就是“非权威的性”的，也就是说这个结果并不是来自这个域名所直接授权的DNS服务器，而是该记录的副本。简单的说，“非权威性”的应答是从别的DNS服务器上复制过来的，与之对应的，就是“权威性”应答则是由域名所在的服务器作出的应答，听起来似乎不易理解，我们来看一个例子。
我所在地是深圳，这里的公共DNS服务器是202.96.134.133，我们来检测一下。
如下图：
这里用到了nslookup命令，用来查询当前本机解析域名所依赖的DNS服务器，从上图中文名可以得知当前默认的DNS解析服务器是ns.szptt.net.cn，对应的IP地址为202.96.134.133，也就是说在这台机子上运行的网络程序，如果需要用到DNS域名解析的，都会将请求到这个服务器上，寻求解析。
当然，如果你是在内网，或是其他类型的局域网，在解析时候可能无法顺利得到上图的结果，多半是代理或防火墙的缘故。建议ADSL用户可以自测一下，加深印象。现在，我们来解析一个网站的别名记录，以此来了解一下何为“非授权记录”
以网易为例吧。如下图：
依照上图步骤就完成了一次CNAME记录的查询，通过这次小测试，希望大家注意一下几点：
1、查询的命令不仅这一种，我们还可以用命令nslookup -qt=cname www.163.com ，返回的结果是一样的。
2、查询的对象需要是一个完整的URL地址，而并非域名，如果想查询对象写出163.com，则默认值返回163.com这个域的ns记录。
2、查询的对象需要是一个完整的URL地址，而并非域名，如果想查询对象写出163.com，则默认值返回163.com这个域的ns记录。
如下图：
163.com的子域名还有很多，不同的子域名可能对应不用的NS服务器，这样做的目的是可以更快的相应客户请求，这就用到的服务器的均衡负载技术了。所以网易的NS服务器也肯定不只这一个。可以用命令来证实，如下图：
从上图可知，网易的NS服务器至少有2台。
以上所有的信息都是“非权威性”的回应，换句话说，这些记录都保存在深圳的这台DNS服务器上，刚才查询的所有结果均来源于此，自然都是副本信息。
那如何才能找到最原始的解析记录呢？要想揭开这个疑难，我们需要对DNS的查询原理有一定的认识。下面是是DNS查询的大致步骤：
1> 首先，客户端提出域名解析请求（无论以何种形式或方法），并将该请求发或转发给本地的DNS服务器。
2> 接着，本地DNS服务器收到请求后就去查询自己的缓存，如果有该条记录，则会将查询的结果返回给客户端。（也就是我们看到的““非权威性”的应答”）。
请注意，下面就开始递归查询了：
反之，如果DNS服务器本地没有搜索到相应的记录，则会把请求转发到根DNS（13台根DNS服务器的IP信息默认均存储在DNS服务器中，当需要时就会去有选择性的连接）。
3> 然后，根DNS服务器收到请求后会判断这个域名是谁来授权管理，并会返回一个负责该域名子域的DNS服务器地址。比如，查询ent.163.com的IP，根DNS服务器就会在负责.com顶级域名的DNS服务器中选一个（并非随机，而是根据空间、地址、管辖区域等条件进行筛选），返回给本地DNS服务器。可以说根域对顶级域名有绝对管理权，自然也知道他们的全部信息，因为在DNS系统中，上一级对下一级有管理权限，毫无疑问，根DNS是最高一级了。
2> 接着，本地DNS服务器收到请求后就去查询自己的缓存，如果有该条记录，则会将查询的结果返回给客户端。（也就是我们看到的““非权威性”的应答”）。
请注意，下面就开始递归查询了：
反之，如果DNS服务器本地没有搜索到相应的记录，则会把请求转发到根DNS（13台根DNS服务器的IP信息默认均存储在DNS服务器中，当需要时就会去有选择性的连接）。
3> 然后，根DNS服务器收到请求后会判断这个域名是谁来授权管理，并会返回一个负责该域名子域的DNS服务器地址。比如，查询ent.163.com的IP，根DNS服务器就会在负责.com顶级域名的DNS服务器中选一个（并非随机，而是根据空间、地址、管辖区域等条件进行筛选），返回给本地DNS服务器。可以说根域对顶级域名有绝对管理权，自然也知道他们的全部信息，因为在DNS系统中，上一级对下一级有管理权限，毫无疑问，根DNS是最高一级了。
4> 本地DNS服务器收到这个地址后，就开始联系对方并将此请求发给他。负责.com域名的某台服务器收到此请求后，如果自己无法解析，就会返回一个管理.com的下一级的DNS服务器地址给本地DNS服务器，也就是负责管理163.com的DNS。
5> 当本地DNS服务器收到这个地址后，就会重复上面的动作，继续往下联系。
6> 不断重复这样的轮回过程，直到有一台DNS服务器可以顺利解析出这个地址为止。在这个过程中，客户端一直处理等待状态，他不需要做任何事，也做不了什么。
7> 直到本地DNS服务器获得IP时，才会把这个IP返回给客户端，到此在本地的DNS服务器取得IP地址后，递归查询就算完成了。本地DNS服务器同时会将这条记录写入自己的缓存，以备后用。
到此，整个解析过程完成。
客户端拿到这个地址后，就可以顺利往下进行了。但假设客户端请求的域名根本不存在，解析自然不成功，DNS服务器会返回此域名不可达，在客户端的体现就是网页无法浏览或网络程序无法连接等等。
为了更好的帮助大家理解整个解析过程，我做了一张DNS域名解析的分步图，如下：
在这个图里，通过8个步骤的解析过程就使得客户端可以顺利访问www.163.com 这个域名，但实际应用中，通常这个过程是非常迅速的，主要由几个方面的原因所决定。1、客户端网络状况是否良好，2、与本地DNS连接的速度是否优秀，3、本地DNS上是否有访问地址的缓存等等，如果以上的因素答案都是肯定的，那么访问就会很迅速，上图的步骤也会骤减至2个，因为有缓存，所以本地DNS服务器会很快告之域名对应的IP而实现迅速访问。
上图中出现了2个陌生的列表，下面就说说这两张表的来历。这里我们结合第九章的内容继续讲解DNS的高级属性，如下图：
可以看到，在【根提示】选项卡中列出了13台根服务器，分别是
(a~m).root-servers.net和对应的IP地址，有的是2个IP，后面那个是备选地址，我们可以手动修改这些地址，但一般情况下，建议不要去动它。如果不小心更改或者删除，我们还是有几个办法修复的。因为这些服务器的地址列表是整个互联网共享的，所以我们可以在网络上找到最新的根服务器列表。通常在这个链接里：
ftp://rs.internic.net/domain/named.root ，也可以通过直接从网络上复制。如下图：
在服务器IP地址里，我们可以输入13个地址中的任意一个，确定后系统会自动连接到该服务器上更新列表。也并非13个地址中的一个，如果同网段内有冗余DNS，这里就可以输入那台DNS的地址，也是可以更新的。前提是，两台DNS服务器都必须连接到互联网。当然在DNS的安装目录下的CACHE.DNS文件中也是可以找到的，具体路径如下：C:\WINDOWS\system32\dns\CACHE.DNS。以上的方法都可以恢复这个列表。
在回到第一个图中，当本地DNS服务器向根DNS查询时，它会搜索自己的根DNS服务器列表，找到一个连接的地址，比如d.root-servers.net，这样就联系到了根服务器，当然，连接其他的也可以，没有太大区别。根服务器检测到是.com域名后，就返回给本地DNS服务器一个IP地址，这个IP就是负责.com顶级域名的其中一个服务器，我这里选的是c.gtld-servers.net，同样的，一共有13台这样的服务器负责.com域名的解析，即(a~m).gtld-servers.net。可能有的朋友疑问，这个是这么知道？OK，要解这部分内容，我们需要用到另一个工具dig，这个原本是Linux下的DNS服务器的调试工具，类似windows下的nslookup，但功能上比后者强很多，我们先做个演示，至于如何使用，后面会有章节来描述。
我们用dig命令来跟踪一下到www.163.com网站的整个过程，如下图：
图中提到的gTLD，其实这是顶级域名的一个分类，除此之外还有ccTLD，也就是国家及地区代码顶级域名，即CountryCodeTLD，比如.cn表示中国.hk，表示香港等。上图的4个过程其实就是我们从提交请求，到正常访问的过程。上图中还有很多参数没有说明，这部分会再后面章节有详述。
现在我们再来说一下递归查询和迭代查询。
在本节的第一张图中，当本地的DNS服务器帮助客户端解析www.163.com这个地址的IP地址的过程中，其实有已经包含了这2类查询。从客户端到本地DNS服务器是属于递归查询。而DNS服务器之间就是的交互查询就是迭代查询。
我们模拟一个场景。比如你的老板要去喜来登大酒店，但不知道怎么走，于是问你（你是他的秘书），此时你也不知道，于是问张三，张三也不清楚，让说让你去问李四，于是你问李四，李四正好知道，然后把线路告诉你，然后你把结果告诉你老板，这样整个问询就完成了。那么这就是个递归的过程。在这个过程中，老板始终在等待你的答案，而自己却丝毫不关心这档子事，而你就充当了一个代理和中间人的角色，来全权负责此时，你的目的是要把答案找到并反馈给老板。
你、张三、李四这三个人之间的信息传递，就是迭代的过程，因为你在问张三的时候，张三并没有像你代替你老板一样去问别人，而只是返回给你一个参考答案。这样的问询方式，我们就称之为迭代查询。
在默认情况下DNS服务器可以接受来自其他客户机（或其他DNS服务器）的迭代或递归查询，如果流量较大的服务器通常都只接受迭代查询，比如13台根服务器。因为如果它们对每一个解析请求都代为查询的话，那将会消耗极大的服务器资源，可能会导致服务器过载甚至崩溃。
关于DNS的迭代和递归查询我们先聊到这里。下节继续讨论DNS服务器高级属性的其他选项卡，敬请期待！
本文内容比较集中，如果有未讲到的地方，请大家指出，我会及时补充，谢谢！
评论