DNS解析概念和解析器操作

DNS解析概念和解析器操作

1、DNS解析器功能和一般操作

​ 从整体上看，名字服务器无疑是DNS系统中最重要的一部分。毕竟，它们存储着系统上的所有数据，而且当提交给它们名字时它们实际上是提供我们所需要的地址。离开了这些服务器就不会有DNS，当然，如果没有人请求服务则服务器有什么用呢？系统中的客户机，被称为解析器，同样也很重要，因为它们发起了名字解析的过程。

1.1、名字解析服务

​ DNS解析器的主要任务就是解析。尽管大多数人认为名字解析就只是将名字转换为IP的过程，但是这仅是几种解析服务的一种而已。下面给出几种最典型的DNS解析类型。

​ 标准名字解析。接受一个DNS名字作为输入并确定其对应的IP地址。

​ 反向名字解析。接受一个IP并确定其关联的名字。

​ 电子邮件解析。接受报文中使用的电子邮件来确定应该把电子邮件报文发送到何处。

1.2、名字解析器执行的功能

​ 尽管也存在其他类型的解析活动，但大多数名字解析仍然采用标准类型，因此是我们讨论的首要重点。为了完成这一任务，名字解析需要执行许多相关的功能：

​ 提供用户接口。正常情况下的名字解析一般不需要显示的运行一个解析软件。在web浏览器中，当你输入一个网站，名字解析自然就运行了。这没有什么神奇的地方。只不过是隐式的调用了解析器而已。web浏览器看见你输入一个名字而不是IP地址，因此把这个名字输送给解析器，告诉它：”我想解析这个名字。“（恩，毕竟礼多人不怪。）解析器负责执行解析并将连接到那个网站的IP地址提供给web浏览器（这儿感觉也不是将ip传给浏览器）。因此，解析器是用户（包括人类用户和软件用户即浏览器）和DNS系统之间的接口。

​ 生成并发送查询。给定一个要解析的名字，DNS解析器必须使用DNS报文传递系统来创建一个适当的查询，确定要执行什么类型的解析，然后将查询发送给适当的名字服务器。

​ 处理响应。解析器必须接受它向其发送查询的那台DNS服务器返回的响应，并决定如何处理响应中所包含的信息，你将会看到，为执行某个特定的名字解析可能有可能有必要联系多台名字服务器。

​ DNS中主要的客户机是称为DSN名字解析器的软件模块，它们负责接受来自客户机软件的名字。向DNS服务器产生解析请求，然后处理和返回响应。

2、DNS名字解析技术：迭代解析和递归解析

​ 常规的名字解析把一个DNS名字转换为IP地址，在最高层，这个过程可以看作是有两个阶段组成。在第一个阶段，我们定位到一台含有我们这个需要信息即特定名字对应的IP地址的服务器。在第二个阶段，我们向这台服务器发送一个包含希望解析名字的请求，然后这台服务器返回所请求的地址。

​ 第二的阶段相当简单，但是第一个阶段找到合适的服务器，可能比较困难，因为DNS服务器的名字信息不是集中存放的。

​ 由于DNS名字信息以分布式数据库的形式分散 存储在很多服务器上，使用单个请求/响应通信通常并不能完成名字解析。首相必须找到含有解析器需要信息的那台服务器，这常常需要一连串的报文交换，从一台根服务器开始，一直向下延伸到包含客户端所需的资源记录（RR）的特定服务器。

2.1、迭代解析

​ 当一个客户机向一台名字服务器发送一个迭代请求时，这台服务器要么以对这个请求的回答（即对应的IP地址）作为应答，要么以含有所需信息或是更靠近该信息的另一台服务器的名字作为响应。原来的那颗客户机必须随后向这台被推荐的服务器发送一个新的请求，（重复）迭代上述过程，该过程将一直持续，知道一直找到正确的服务器为止。如下图所示。

2.2、递归解析

​ 当客户机向一台名字服务器发送递归请求时，如果该服务器含有它所查找的信息，它就将真正的答案作为响应。如果服务器没有所需的信息，他就接管查找答案的责任，变成一个客户机，代表原来的客户机向其他服务器发送新的请求，最终就能够获得自己想要的信息（如果信息不可得就会发送一个差错报文），过程如下图所示。

​ DNS中名字解析得两种方法分别时迭代解析和递归解析。在迭代解析中，如果客户机向没有包含其所需要得信息得某台服务器发送一个请求。则这台服务器就返回一个指向另外一台名字服务器得指针，随后客户机向这台服务器发送一个新的请求。在递归解析中，如果客户机向没有包含其所需信息的某台服务器发送了一个请求，这这台服务器将会接管向其他服务器发送请求以查找所需记录的责任，并把这些记录返回给客户机。执行这些操作的服务器在向其他服务器发送自己的请求时充当客户机的角色。

3、提高DNS名字解析的效率：高速缓存和本地解析

​ 迭代和递归查询都能帮我们找到正确的服务器，但它们会花费大量的时间。由于经常需要执行解析，所以对基本的解析过程做一些改进以尽可能地提高效率是有益地。

3.1、高速查询地动机：查询本地化

有一个称为访问局部化地计算机科学原理刻画了与计算机（以及网络）使用方式地两种常见现象。第一种现象，又是称为访问地空间局部性，观察到如果一个资源临近另一个最近刚刚访问过的资源，则这个资源很可能被访问。第二个现象，被称为访问地时间地局限性，指的是如果一个资源最近刚刚被访问过，则它很可能会再次访问。

​ 一般来说，这两种现象是计算机领域里采用高速缓存地理论基础，并且它们也是DNS服务器采用高速缓存地理论基础，高速缓存带来地好处同样适用于解析器，而且很多解析器也都采用类似服务器执行高速缓存地方式来执行高速缓存。

3.2、名字解析器高速缓存

​ 在某台特定地客户计算机上，一旦解析了一个特定地名字，就将其缓存下来并留作下一次需要的时候使用，这样做同时也消除了DNS服务器上的流量和负载（但需要注意的是并不是所有的解析器都执行高速缓存）。一条资源记录（RR）在缓存中保存的时间长短由其寿命（TTL）值规定。此外，解析器不会缓存某些结果，如反向查询，而且如果解析器怀疑（无论什么原因）返回的数据已经损坏或者不可靠，它们也可能不缓存解析结果。

3.3、本地解析

​ 把解析器的查询请求提交到根据根服务器之前让这台服务器首先检查一下自己是否能回答这个查询是非常有意义的，因为这样做不仅可以向客户机提供更迅速的回答，而且也减少了互联网络上的流量，这个做法称为本机解析。例如我们自己电脑上的hosts方法。

4、DNS名字解析过程

4.1、DNS名字解析的一个简单例子

​ 假设XYZ industries为xyzindustries.com地区自己运行的DNS服务器，其中主名字服务器叫做ns1.xyzindustries.com，从名字服务器是ns2.xyzindustirs.com，Googelplex大学为google.edu域运行自己的DNS服务器，该域有三个域：finerats.googleples.com compscis.googleplex.com admin.googleplex.com。其中，compscis.googleplex.com位于一个配有专用服务器的单独地区中，其他两个子域位于.googleplex.edu地区。

​ 现在假设你是XYZ industries的一名员工，并且你的客户负责管理Googleplex大学的网络部门。现在你咋你自己的浏览器中输入该部门的web服务地址www.net.compsic.googleplex.edu。那么这个过程将涉及一下步骤。

4.2、修改解析以处理别名（CNAME记录）

​ CNAME记录可以用来把某台设备的一个固定不变的名字呈现给外界，同时又使得对应该名字的实际设备可以在组织内部变化。当使用一个CAME时，需要修改名字解析的过程，添加一个额外的步骤：首先把别名解析为规范名，然后再解析规范名。

5、利用IN-ADDR.APRA域的NDS反向名字解析

5.1、初始方法：反向查询

​ 对于反向查询，解析器发出查询，查询中不是填入一个名字并留下空间以待服务器填入IP地址，而是填入一个IP地址并留下空间以待服务器填入名字，服务器将会检查自己的RR并将名字返回给解析器，当互联网的规模比较小的时候，这种方法也不错，但是现在网络规模非常巨大，所以这个方法是行不通的。

​ 那么，应该怎么执行反向查询呢？嗯，问题在于服务器是按照名字而不是按照IP地址来组织的。所以，解决方法就如同想的那样简单，按照IP地址来组织服务器。这并不表名我们要删除名字层次结构，或是复制多有的服务器，以及任何与此类型的愚蠢想法。相反，我们创建一个与名字层次结构共存的附加的数字层次结构，然后，我们利用这个层次结构，采用一种通常称为反向名字解析的过程，从数字查找名字。

5.2、用于反向解析的IN-ADDR.ARPA名字结构

​ 因特网的数字结构层次结构是利用一个位于保留的.ARPA TLD内，叫作IN-ADDR.APRA（IN-ADDR代表INternet ADDRess）的特殊域实现。之前的文章讲过.APRA最初用来因特网的主机过渡到DNS，而现在由运营英特网的人用于各种目的。

​ 在IN-ADDR.APRA内创建了一种特殊的覆盖整个IP地址空间的数字层次结构

5.3、用于反向解析的RR设置

​ 在这种结构中我们现在就可以把实际DNS名字空间中的每一条记录域这个名字空间中的一条记录关联起来，我们利用指针（PTR）RR类型完成这以工作。例如，如果www.xyzindustries.com的IP地址是192.168.2.34，则它所在地区的DNS服务器就会有一条地址（A）RR记录用来说明这种情况，在中文件文本格式中，它可能会显示类似于下面这样的信息：

www.xyzindustries.com  A  192.168.2.34

但是在IN-ADDR.ARPA域内它还将有下面这样的记录：

34.2.168.192 IN-ADDR.ARPA PTR www.xyzindustries.com

注：DNS是不区分大小写的。

6、DNS电子邮件支持和邮件交换（MX）资源记录

​ 有一种应用程序一直都在使用DNS，但是当我们考虑DNS是却常常想不起它，这就是电子邮件。实际上，电子邮件比任何其他TCP/IP应用程序都要依赖于DNS。不妨考虑一下，有时你也可能会在类似于tracerroute这样的命令中输入一个IP地址，甚至有可能在浏览器中输入地址，但是你可能从来没有在电子邮件客户端中输入joe@192.168.23.25而发给任何人邮件。你输入的是类似于joe@qq.com内容，而DNS负责稿明白应该把电子邮件发到何处。

6.1、电子邮件名字解析的特殊要求

​ 电子邮件地址解析的名字解析不同于DNS中的其他应用，有一下三个原因：

​ 我们可能不希望将邮件发送到由地址确切指定的机器上。

​ 我们需要能够在不修改个人电子邮件地址的条件下更改服务器名字。

​ 我们需要能够支持多台服务器处理邮件。

为了提供所有这些场所所需的灵活性，一种专门的DNS RR类型，称为邮件交换（MX）记录，被定义出来。

6.2、邮件交换记录及其使用

​ 每条MX记录指定了一台特定的邮件服务器用来为某个特定域处理收到的邮件。一旦建立了这条记录，则电子邮件的解析就变得非常类似于常规的解析。假定你希望给joe@qq.com发送一个消息，则基本过程如下所述。

​ （1）你的电子邮件客户机程序调用本地机器上的解析器对joe@qq.com执行电子邮件解析。

​ （2）你的本地解析器和本地DNS解析器遵循本章前面介绍过的过程来查找joe@qq.com的权威服务器。

​ （3）权威服务器找到qq.com的MX记录，回复指出应该把mail.qq.com用于电子邮件。

​ 电子邮件尚不能向mail.qq.com实际发送任何内容，它还需要获得它的IP地址。因此它还需要对名字进行解析。这个请求很可能恰好到达刚才处理MX请求的那台DNS名字服务器。为了消除这种分别执行两次的低效性，DNS名字服务器可以把信息组合起来，还可以为一个特定的域规定多条MX记录，每条记录指向一台不同的邮件服务器的名字，这样做提供了冗余，如果哪台服务器出现了问题，另一台就可以接管它的工作。DNS还支持每一台邮件服务器时使用一个优先值，这样一来就可以明确指定哪一台服务器是主邮件服务器，哪台是第一备用服务器，那台是第二备用服务器，等等。DNS会先择优先级高的邮件服务器。
向一台不同的邮件服务器的名字，这样做提供了冗余，如果哪台服务器出现了问题，另一台就可以接管它的工作。DNS还支持每一台邮件服务器时使用一个优先值，这样一来就可以明确指定哪一台服务器是主邮件服务器，哪台是第一备用服务器，那台是第二备用服务器，等等。DNS会先择优先级高的邮件服务器。