4.1. 介绍Resolver是用户程序和域名服务器之间的接口，最简单的情况下，resolver接收从用户来的
请求，返回符合本地数据格式的查询结果。resolver和请求DNS服务的程序在同一台机器上，但DNS服务器则在
其它机器上，因为resolver可能要查询多个名字服务器，所有它需要有一个本地缓冲，而查询的时间则可能因具体查
询不同而差别很大。resolver的一个重要作用是就是它有一个多个程序可以共享的缓冲区，这里保存着一些查询结果
，使用这些结果可以减少对服务器反复的查询。4.2. 客户-resolver接口4.2.1. 典型函数这个接口因
主机不同而不同，但有三个函数是大家必须都有的：主机名到主机地址转换，此函数通常定义用来模拟原来基于HOSTS.
TXT的函数。给定一个字符串，返回一个32位IP地址，在DNS下，它转换为请求类型A的RR请求。因为DNS不保
存RR的顺序，函数会进行排序将返回的许多地址中的一个返回给用户。请注意：最好是返回多个地址，但单个地址是模拟原
来基于HOSTS.TXT服务的。主机地址到主机名转换，给定32位IP地址，返回字符串。查询时采用PRT查询，主
机名加上"IN-ADDR.ARPA"后缀进行查询，如IP地址为1.2.3.4，则PTR RR查询域名"4.3.
2.1.IN-ADDR.ARPA"。通用查询函数，调用者提供QNAME，QTYPE和QCLASS，希望所有匹配
的RR，函数会使用DNS格式而非本机格式返回查询结果，结果中包括所有RR的内容。在resolver执行上面的函
数时，会返回以下的结果给客户：给定请求数据的一个或多个RR，此时resovler以合适的格式返回结果名字错误(
NE)，在查询的名字不存在是会返回NE未找到数据错误，查询的名字存在，但合适类型的数据不存在时产生这种错误，如
把主机地址用于邮箱地址时会返回错误需要注意的是，有时某些函数会在查询时名字错误和数据未找到错误会被合并为另一种
类型的错误，但通常函数不会。一个原因是程序通常先查询一个名字（包括类型信息），然后是同一个名字的另外类型，如果
两个错误合起来，反面会减慢查询速度。4.2.2. 别名当试图解析一个特殊的名字查询时，resolver可能发现
这是一个别名，如果可能这种情况会返回给客户。但是经常，当resolver碰到一个CNAME时，它会重新开始一个
查询。然而，在执行通常函数而且CNAME RR配置查询类型时，resolver不应该要别名。在有别名的时候有几
种特殊情况。多级别名应该避免，因为太缺乏效率，但这也不应该被做为错误返回给客户。对于别名循环和别名指向不存在的
名字时应该将错误返回给客户。4.2.3. 临时错误有时候因为网络等原因，resolver可能不能完成某个请求，
这时不应该返回没有名字或未查询到这类错误。这类错误对人类用户来说可是件烦心的事。在某些时候可以阻塞请求，但这并
不是个好的解决之道，特别是服务器就等它完成以转向其它任务的时候。推荐的方法是返回错误指示现在出现临时错误。4.
3. Resolver内部每个resolver的实现都不相同，会有复杂的逻辑处理各种错误，而本文只讨论一个纲领
。4.3.1. 根（Stub）resolvers一种实现resolver的方法就是在支持循环查询的服务器上实现
，这样可以节省PC机上的资源，也可以对查询结果缓冲进行集中管理。其它的事情就是要一个支持循环查询服务器地址的文
件在PC机上，PC机上资源有限，支持一个域名数据库可能不太现实。用户必须确定所列的名字服务器支持循环查询，服务
器可以拒绝进行任何客户的循环查询请求，因此用户必须向管理员核对。这种类型的服务有一些不足，因为循环查询较费时，
根对UDP重发时间的选择比较难以确定，服务器会因为根的反复重发而崩溃。使用TCP或许会好，但这样会严重占用主机
时间，使用TCP相当于实现一个实时的查询系统。4.3.2. 资源除了自己的资源外，resolver可以访问本地
服务器保存的区数据。这会使resolver的速度加快，但是也可以让缓冲数据冲掉区数据。本文中指的本地信息是说缓
冲和共享区数据，在有认证数据和缓冲数据时应该优先使用认证数据。下面的算法假设所有函数被转换为一个通常的查询函数
，使用下面的数据结构代表进行中的请求的状态：SNAME 要查询的域名STYPE 查询请求的QTYPESCLAS
S 查询请求的QCLASSSLIST 表示正在查询的名字服务器和区，它保存resolver的预测，预测希望查询
的数据在什么地方，通过接收的数据，此结构内的数据会发生变化。它包括服务器地址，区内已知的服务器，历史记录，以及
表示查询距离目标还有多远的标记（查询从树顶开始向下，直到目标）。SBELT 在resolver无法从本地信息知
道应该查询哪个服务器时，它就派上用场了。CACHE 保存前一次响应的结果，因为resolver会抛弃达到TTL
时间的RR，所有大部分resolver实现将接收到RR的时间转换为绝对时间，然后保存在缓冲中，resolver
可以在查询时顺便将过期RR抛弃，也可定期进行维护。4.3.3. 算法大体上，算法有四步：检查结果是否在本地，如
果是则直接返回；向最合适的服务器查询；向多个服务器发出请求，直到得到响应；分析结果：如果响应给出了结果或包含名
字错误，缓冲并返回结果给用户；如果响应指出更合适的服务器，缓冲这个结果，转第2步；如果响应显示CNAME，但并
不是答案，缓冲CNAME，将SNAME改为CNAME RR中的统一名称，然后转第1步；如果响应显示服务器失败或
其它不可识别的内容，从SLIST中删除此服务器，然后转第3步。第1步在缓冲内查找，如果找到了，那就返回给用户。
有些resolver可以设置不使用缓冲内的数据，但并不推荐把它做为默认情况。如果resolver能够直接访问服
务器的区，而且能够找到数据的认证形式，则不要使用缓冲内的数据。第2步向服务器查询需要的数据，通常的办法是寻找本
地提供的服务器RR，提供SNAME，然后给出SNAME的父域名，父域名的父域名，以此类推，直到根。因此，如果S
NAME=Mockapetris.ISI.EDU，查询NS RR的顺序为Mockapetris.ISI.EDU
，ISI.EDU，EDU，最后是.（根）。NS RR列出了此区的或在SNAME之上的主机名，复制名字到SLIS
T，使用本地信息设置它们的地址，可能地址不可用，此时resolver有几种不同的选择，最好是进行并行搜索，一个
搜索现在可用的，一个去寻找新的，当然实现起来就有麻烦了，我们把实现的一些规则列于下面：加入一些限制，让请求不会
进入无限循环，也不会造成对链式请求和对其它服务的链式请求，即使在有人错误配置的情况下也不能造成上述情况尽一切可
以获得响应避免不必要的传输尽快获得响应如果查询NS RR失败，resolver从SBELT中初始化SLIST，
基本的思想是当resolver不知道哪个服务器在工作时，它会从一个配置文件中取得相应的信息。虽然是特殊情况，但
基本上要有两个根服务器地址存在于这种配置文件中。有两个是为了冗余，根服务器可以对所有的域空间进行探索，两个本地
服务器将允许resolver继续尝试利用本地资源解析域名。除了名字的名字和地址，SLIST中可以保存服务器的优
先查询顺序，保证高优先级在前，本地服务器在远程服务器前，也可能是由成功的统计结果得到，算法不尽相同。第3步发出
请求，直到收到响应。算法基本思想是对所有列出的服务器以循环方式进行发送。实际上，要重视多穴（multihome
d）主机的多个地址，在使用多个resolver的时候要注意对相同主机进行重新传输对时间的影响。SLIST通常包
括一个值，用于控制和监视传输的超时。第4步涉及分析结果，resovler应该检查响应的ID域看是不是和请求的I
D一致。理想的响应是从认证权威那里收到的数据，它要么给出需要的数据，要么给出名字错误。在TTL大于0的时候，结
果保存于缓冲，同时结果返回给用户。如果结果指出其它服务器A，要对这个服务器A和SLIST中的主机进行比较，看是
不是更合适，这可以通过比较SLIST中的匹配计数完成，这个匹配计数是通过SNAME和服务器A中的NS RR计算
得到。如果不合适，这个响应会被忽略，如果合适，结果会被缓冲，相应的服务器会进入SLIST，新的查询开始。如果响
应包括CNAME，新查询将从CNAME开始，除非响应有标准格式的数据，或CNAME就中结果