表示正在查询的名字服务器和区,它保存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的父域名,父域名的父域名,以此类推,直到根。因此,如果SNAME=Mockapetris.ISI.EDU,查询NS RR的顺序为Mockapetris.ISI.EDU,ISI.EDU,EDU,最后是.(根)。NS RR列出了此区的或在SNAME之上的主机名,复制名字到SLIST,使用本地信息设置它们的地址,可能地址不可用,此时resolver有几种不同的选择,最好是进行并行搜索,一个搜索现在可用的,一个去寻找新的,当然实现起来就有麻烦了,我们把实现的一些规则列于下面:
加入一些限制,让请求不会进入无限循环,也不会造成对链式请求和对其它服务的链式请求,即使在有人错误配置的情况下也不能造成上述情况
尽一切可以获得响应
避免不必要的传输
尽快获得响应
如果查询NS RR失败,resolver从SBELT中初始化SLIST,基本的思想是当resolver不知道哪个服务器在工作时,它会从一个配置文件中取得相应的信息。虽然是特殊情况,但基本上要有两个根服务器地址存在于这种配置文件中。有两个是为了冗余,根服务器可以对所有的域空间进行探索,两个本地服务器将允许resolver继续尝试利用本地资源解析域名。除了名字的名字和地址,SLIST中可以保存服务器的优先查询顺序,保证高优先级在前,本地服务器在远程服务器前,也可能是由成功的统计结果得到,算法不尽相同。
第3步发出请求,直到收到响应。算法基本思想是对所有列出的服务器以循环方式进行发送。实际上,要重视多穴(multihomed)主机的多个地址,在使用多个resolver的时候要注意对相同主机进行重新传输对时间的影响。SLIST通常包括一个值,用于控制和监视传输的超时。
第4步涉及分析结果,resovler应该检查响应的ID域看是不是和请求的ID一致。理想的响应是从认证权威那里收到的数据,它要么给出需要的数据,要么给出名字错误。在TTL大于0的时候,结果保存于缓冲,同时结果返回给用户。如果结果指出其它服务器A,要对这个服务器A和SLIST中的主机进行比较,看是不是更合适,这可以通过比较SLIST中的匹配计数完成,这个匹配计数是通过SNAME和服务器A中的NS RR计算得到。如果不合适,这个响应会被忽略,如果合适,结果会被缓冲,相应的服务器会进入SLIST,新的查询开始。如果响应包括CNAME,新查询将从CNAME开始,除非响应有标准格式的数据,或CNAME就中结果。
5.例子