DNS

关于客户计算机访问DNS请求的工作流程要知道作为MS的三大服务之一的DNS，仅在Resource Kit里就有近200页的介绍，这里还需要大家对这些基础性概念和服务进一步补充，能够使大家更全面的了解！废话少说，让我们来看一看，本文的“中心思想”－－客户计算机访问DNS请求对AA.Mi 文件服务器进行访问工作的工作流程如图详解1、客户计算机使用LAN Manager Workstation 和网络文件系统MRXSMB.SYS共同建立一个SMB消息，与建立会话。

2、重定向器将该消息交给TCPIP.SYS进行打包传输。

TCPIP.SYS与NETB T.SYS一起为此SMB 建立一个数据报，面向会话的SMB通信使用TCP139端口。

3、TCPIP.SYS需要解析该目标计算机的IP地址，于是使用内含的DNS解析器；同时NETB T.SYS 也将使用其自身的服务进行查找该计算机名字。

双方同时访问各自的缓存空间。

如果没有的话，就进入各自的下一步。

其中Netbt.sys见前面的WINS服务。

（在名称访问过程中，TCPIP.SYS和NETBT.SYS是同时在查找名称的解析，谁先找到，就使用谁的，没有被用到的将被存入缓存中。

）4、DNS解析器将向其指向的本地DNS服务器（LDNS）发出递归查询请求。

LDNS接受到相关信息后，在本机缓存中查找相关信息，找到后，……直接反馈客户机。

如果没有找到，就……在本地的区域中查找，查看自己是否是对于Microsift.con的一个权威服务器。

如果是，就在其中查找主机AA记录。

如果找不到，将返回“资源未找到”。

DNS解析器从LDNS得到这个消息将不再进行进一步查找。

5、如果LDNS不是一个对于此区域的一个权威管理器，就将信息发送到根域服务器上，全球有13台根域服务器。

6、根域服务器没有任何主机记录，当然不包含AA.Mi 的记录，但是INTERNIC是Com 的SOA，这就是标示其拥有名称服务器NS的记录，这些NS纪律指向被委派的区域的DNS服务器，它们存有直接位于Com下面的域的区域表。

但是根不接受递归查询，因此他将在NS记录中搜索并找到一个最接近的COM管理的服务器及其IP地址回返给LDNS。

7、LDNS服务器将向管理Com的DNS发出迭代请求，请求的A记录。

该DNS将把最接近的的DNS地址反馈给LDNS。

8、LDNS将再次访问 DNS服务器，并发出请求。

该DNS服务器将把AA的地址反馈给LDNS9、LDNS将此信息反馈给客户端计算机，并将该信息保存在自己的缓存列表中，以北后来再使用。

10、本地的DNS解析器收到该信息后，将使用ARP找到与该记录对应的MAC地址。

11、TCPIP.SYS将把IP包和MAC地址交给NDIS（Network Driver Interface System）网络微驱动模块。

12、NDIS将建立与目标计算机之间的连接，并传输数据。

13、同时TCPIP.SYS还将该记录保存给DNS解析器缓存，按照规定的TTL值进行保存。

DNS 查询的工作原理当DNS 客户端需要查询程序中使用的名称时，它会查询DNS 服务器来解析该名称。

客户端发送的每条查询消息都包括三条信息，指定服务器回答的问题：•指定的DNS 域名，规定为完全合格的域名(FQDN)•指定的查询类型，可根据类型指定资源记录，或者指定查询操作的专用类型。

•DNS 域名的指定类别。

对于Windows DNS 服务器，它始终应指定为Internet (IN) 类别。

例如，指定的名称可为计算机的FQDN，如，并且指定的查询类型用于通过该名称搜索地址(A) 资源记录。

将DNS 查询看作客户端向服务器询问由两部分组成的问题，如“您是否拥有名为…‟的计算机的A 资源记录？”当客户端收到来自服务器的应答时，它将读取并解释应答的 A 资源记录，获取根据名称询问的计算机的IP 地址。

DNS 查询以各种不同的方式进行解析。

有时，客户端也可使用从先前的查询获得的缓存信息在本地应答查询。

DNS 服务器可使用其自身的资源记录信息缓存来应答查询。

DNS 服务器也可代表请求客户端查询或联系其他DNS 服务器，以便完全解析该名称，并随后将应答返回至客户端。

这个过程称为递归。

另外，客户端自己也可尝试联系其他的DNS 服务器来解析名称。

当客户端执行此操作时，它会根据来自服务器的参考答案，使用其他的独立查询。

这个过程称为迭代。

总之，DNS 查询进程分两部分进行：•名称查询从客户端计算机开始，并传输至解析程序即DNS 客户端服务程序进行解析。

•不能在本地解析查询时，可根据需要查询DNS 服务器来解析名称。

下面将更加详细地解释这两个过程。

返回页首第 1 部分：本地解析程序下图显示了完整的DNS 查询进程的概况。

插图如查询过程的初始步骤所示，DNS 域名由本机的程序使用。

该请求随后传输至DNS 客户端服务，以便使用本地缓存信息进行解析。

如果可以解析查询的名称，则应答该查询，该进程完成。

本地解析程序的缓存可包括从两个可能的来源获取的名称信息：•如果在本地配置主机文件，则来自该文件的任何主机名称到地址的映射，在DNS 客户端服务启动时将预先加载到缓存中。

•从以前的DNS 查询应答的响应中获取的资源记录，将被添加至缓存并保留一段时间。

如果此查询与缓存中的项目不匹配，则解析过程继续进行，客户端查询DNS 服务器来解析名称。

返回页首第 2 部分：查询DNS 服务器如前面的图中所示，客户端将查询首选DNS 服务器。

在此进程的初始客户端/服务器查询部分中使用的实际服务器选自全局列表。

有关如何编译和更新该全局列表的详细信息，请参阅客户端功能。

当DNS 服务器接收到查询时，首先检查它能否根据在服务器的本地配置区域中获取的资源记录信息作出权威性的应答。

如果查询的名称与本地区域信息中的相应资源记录匹配，则使用该信息来解析查询的名称，服务器作出权威性的应答。

如果区域信息中没有查询的名称，则服务器检查它能否通过来自先前查询的本地缓存信息来解析该名称。

如果从中发现匹配的信息，则服务器使用该信息应答查询。

接着，如果首选服务器可使用来自其缓存的完全匹配响应来应答发出请求的客户端，则此次查询完成。

如果查询名称在首选服务器中未发现来自缓存或区域信息的匹配应答，则查询进程可继续进行，使用递归来完全解析名称。

这涉及来自其他DNS 服务器的支持，以帮助解析名称。

在默认情况下，DNS 客户端服务要求服务器在返回应答之前，使用递归过程来代表客户端完全解析名称。

在大多数情况下，DNS 服务器默认配置为支持递归过程，如下图所示。

插图为了使DNS 服务器正确执行递归过程，首先需要使用DNS 域命名空间内有关其他DNS 服务器的一些有用的联系信息。

该信息以根提示的形式提供，它是一个初始资源记录列表，DNS 服务可利用这些记录定位其他DNS 服务器，它们对DNS 域命名空间树的根具有绝对控制权。

根服务器对于DNS 域命名空间树中的根域和顶级域具有绝对控制权。

详细信息，请参阅更新根提示。

使用根提示查找根服务器，DNS 服务器可完成递归的使用。

理论上，该进程将启用DNS 服务器，以定位那些对域命名空间树的任何级别使用的任何其他DNS 域名具有绝对控制权的服务器。

例如，当客户端查询单个DNS 服务器时，考虑使用递归过程来定位名称。

在DNS 服务器和客户端首次启动，并且没有本地缓存信息可帮助解析名称查询时，就会进行上述过程。

根据其配置的区域，它假定由客户端查询的名称是域名，该服务器在本地不包含有关该域名的信息。

首先，首选服务器分析全名并确定对于顶级域“com”具有绝对控制权的服务器的位置。

随后，对“com”DNS 服务器使用迭代查询，以获取“”服务器的参考信息。

随后，参考应答从“”服务器传送到“”的DNS 服务器。

最后，与服务器 建立联系。

因为该服务器包括作为其配置区域一部分的查询名称，所以它向启动递归的源服务器作出权威性地应答。

当源服务器接收到表明已获得对请求查询的权威性应答的响应时，它将此应答转发给发出请求的客户端，这样递归查询过程就完成了。

尽管执行上述递归查询过程可能需要占用大量资源，但对于DNS 服务器来说它仍然具有一些性能上的优势。

例如，在递归过程中，执行递归查询的DNS 服务器可获得有关DNS 域命名空间的信息。

该信息由服务器缓存起来并可再次使用，以便提高使用此信息或与之匹配的后续查询的应答速度。

随着时间的推移，这些缓存信息会不断增加并占据大量的服务器内存资源，尽管每次DNS 服务重新启动时这一信息将被清除。

返回页首可选的查询响应以前对DNS 查询的讨论，都假定此过程在结束时会向客户端返回一个肯定的响应。

然而，查询也可返回其他应答。

最常见的应答有：•权威性应答•肯定应答•参考性应答•否定应答权威性应答是返回至客户端的肯定应答，并随DNS 消息中设置的“授权机构”位一同发送，消息指出此应答是从带直接授权机构的服务器获取的。

肯定应答可由查询的RR 或RR 列表（也称作RRset）组成，它与查询的DNS 域名和查询消息中指定的记录类型相符。

参考性应答包括查询中名称或类型未指定的其他资源记录。

如果不支持递归过程，则这类应答将返回至客户端。

这些记录的作用是为了提供一些有用的参考性应答，客户端可使用参考性应答继续进行递归查询。

参考性应答包含其他的数据，如不属于查询类型的资源记录(RR)。

例如，如果查询主机名称为“www”并且在这个区域未找到该名称的 A RR，而是找到了“www”的 CNAME RR，则DNS 服务器在响应客户端时可包含该信息。

如果客户端能够使用迭代过程，则它可使用这些参考性信息为自己进行其他查询，以便完全解析此名称。

来自服务器的否定应答可以表明：当服务器试图处理并且权威性地彻底解析查询的时候，遇到两种可能的结果之一：•权威性服务器报告：在DNS 命名空间中没有查询的名称。

•权威性服务器报告：查询的名称存在，但该名称不存在指定类型的记录。

以肯定或否定响应的形式，解析程序将查询结果传回请求程序并把响应消息缓存起来。

注意•如果查询的最终应答太长而不能在一个UDP 消息数据包中发送和解析，则DNS 服务器可以在TCP 端口53 上发送故障转移响应消息，以便在TCP 连接会话中完全应答客户端。

•当限定DNS 客户端的名称解析到特定的DNS 服务器（如Intranet 上的DNS 服务器）的时候，系统通常会禁止在DNS 服务器上使用递归。

当DNS 服务器不能解析外部DNS 名称的时候，可能也会禁用递归，而且期望客户端故障转移到其他DNS 服务器，以便解析这些名称。

在相应服务器的DNS 控制台中，可以在“高级”属性中进行配置，以禁用递归。

详细信息，请参阅禁用DNS 服务器上的递归。