5.2.1缓存有答案
在客户机和域名交互信息的过程中，如果客户机所查询的结果就在域名的本地缓存中，则交互的过程如图5-6所示。
图中用数字表示的交互顺序是：
1)客户机发送查询到域名服务器。
2)域名服务器检查它的本地缓存。
3)如果域名服务器的本地缓存有相应的回答，则域名服务器直接将答案返回给客户机。
5.2.2缓存无答案
在客户机和域名服务器交互信息的过程中，如果客户机所查询的结果没有在域名服务器的本地缓存中，则交互的过程如图5-7所示。
图中用数字表示的交互顺序是：
1)客户机发送查询到域名服务器。
2)域名服务器检查它的本地缓存。如果答案不在域名服务器的本地缓存，域名服务器必须到其他地方寻找回答。
3)域名服务器可以将查询发送到根服务器，并被根服务器指引到所查询域的授权服务器。
4)一旦本地服务器从授权服务器得到答案，它就将答案保存在它的缓存中，并将答案提供给客户机。
5.3有效时间（TTL）
有效时间（TTL）相当于一个计时器，用来告诉域名服务器当它从授权服务器得到回答后，此答案在多长时间内是有效的。如第7章“DNS知道什么”中将会讲到，TTL值可以对每个记录设置，或者可以用一个域的SOA记录中的最小有效时间（M-TTL）作为每个记录的缺省值。如果某个记录的TTL设置得与缺省的M-TTL值不同，以后各个记录的TTL将取这个值，直到又明确设为最小TTL值。如果TTL的值等于0，则客户机就知道它不能缓存这个结果。
TTL的使用很简单。当本地域名服务器没有收到的查询所需的信息时，这个本地域名服务器必须查询相关域的授权服务器来得到回答。一旦本地域名服务器获得了回答，就将结果存入缓存以便其他本地主机查询同样信息时使用。TTL将决定本地域名服务器将这个结果在缓存中保存多长时间。一旦TTL的值已超过，本地域名服务器就将相应信息从缓存中删除，如果相应的查询又收到时，必须再次向授权服务器要求回答。如果TTL设置不为0，收到的结果就存人缓存并用于非授权的回答。
5.4查询过程
以下再回顾一下查询解析的整个过程。但这次是把它放在全局中看，而不是仅仅聚焦于局部工作以及DNS服务器的行动和责任。
5.4.1递归DNS查询
递归查询要求DNS服务器代表客户机承担全部的责任以检索一个授权回答。图5-8表示了这种查询，此时客户机pc.aclne.com发布递归查询给DNS服务器acme.com。
在图5-8中，DNS服务器acme.com从客户机pc.acme.com接受了递归查询后，它本身对4个其他DNS服务器来说就变成了一个迭代DNS客户机／解析器。
当bigcompany.com的DNS服务器给出一个授权回答时，acme.com将它传递给pc.acme.com，完成对查询的解析。直到客户机满意后，解析才算结束。如果因为某种原因一个没被授权的回答被传递，解析过程就不会结束只到客户机满意为止。如果客户一直没有收到授权回答，它也许再次向在它的配置中所包含的其他DNS服务器发出查询。
如果acme.com拒绝pc.acme.com的递归查询请求，pc.acme.com不得不自己完成所有的迭代查询，轮流地访问每台DNS服务器，就像图5-8中的acme.com那样。客户机解析器发布递归请求几乎总是独占式的，但也有被拒绝的时候。
客户机从一台DNS服务器得到的对递归查询的回答只能是成功或者失败。在得到这个回答以前，客户机将一直等待。如果结果不是主机搜索到的授权IP地址，而只是一种提示或指向另外的DNS服务器，客户机下一次就查询提示的地址，以得到授权的回答。
递归查询意味着DNS服务器要代表客户机处理查询直到请求被解析。DNS服务器使用自己的解析器，不时变换服务器和客户机的角色，直到它自己或其他的服务器能提供授权的回答。有意思的是，处理客户机的递归查询的DNS服务器经常向其他服务器提出迭代查询的请求，根据它们所给出的结果，在DNS域名树中上下搜索直到有一个服务器能与查询的名字相匹配，否则在遇到如超时或出错等结束条件时终止查询。
只有满足以下条件才能递归查询：
•客户机要求递归查询。
•DNS服务器接受递归查询(多数如此，除了根服务器)。
•客户机的服务器不能从它自己的缓存或数据库中给出回答。
如果客户机的服务器可以从它自己的缓存或数据库中给出回答，它就能立即给出有效的回答，而不需要进一步查询。
多数解析器都首先进行递归查询。如果服务器拒绝递归查询，而它又不能从自己的缓存或数据库中给出回答，客户机将再试用迭代查询。
5.4.2迭代DNS查询
迭代查询能使服务器返回一个最佳的搜索点，或称搜索提示。迭代查询可能不会返回最后的结果，而递归查询则可以给出结果。迭代查询可以返回部分结果，或者提示下一步到哪里搜索。客户机(解析器)通过迭代查询逐步接近所需的回答，迭代地查询其他服务器直到得到最后的回答，或者出错，或者是超时。迭代查询要求服务器的工作较少，而要求客户机的工作较多。
再回到图5-8，其中第二次查询指向ns.myisp.com，返回的提示指向acme.com，即根域名DNS服务器。然后，重复类似的过程，直到第五次指向bigcompany.com的DNS服务器查询返回所需的回答时结束。
如果第一台DNS服务器的迭代查询不能返回一个地址，它将告诉客户机下一次应该访问哪台DNS服务器。一般地，下一次访问的最佳服务器将在域名树中上移，并更靠近DNS根域名服务器，甚至就是根域名服务器。当查到根域名服务器后，一般只需再在域名树向下查询若干次，就能得出最终的结果：或者是到达所需的服务器，以返回查询的地址；或者是出错并终止查询。
5.4.3反向DNS查询
反向查询完全是另一回事。递归查询和迭代查询都是正向查询，也就是从一个域名去查询IP地址。而反向查询则刚好相反：它从客户机中收到IP地址，然后返回一个全域名(FQDN)。为此，在域名空间中专门按照IP地址而不是域名创建了一个域，所有已注册的IP地址都组织在arpa域的in-addr子域。
根据域名可以将主机划分到不同的域或子域，因此主机名是可重复的。而Internet中没有两个主机可以注册相同的IP地址，所以按照IP地址它们都可以成为同一个域的成员。在这种方案中，一个唯一的IP地址代替了域名层次结构中的域名。在in-addr.arpa域中，主执host2.acmecompany.com将有一条如下形式的指针(PTR)记录：
对这个指针记录，在acmecompany.com子域中相应的地址记录将是：
在这个例子中，主机host2的IP地址在in-addr.arpa域中，并和其他的已注册的Internet主机地址一起排序。通过IP反向查询主机host2，查询的次数不需很多。只需在in-addr.arpa域中查询它的反向排列的IP地址就可以返回主机host2的全域名，前提是所有已注册的主机在in-addr.arpa域中都按IP地址而不是按域名排列。
5.4.4正在进行的查询
当查询正在进行时，一个客户机乃至一台DNS服务器使用的查询类型对管理员比对用户更重要。如果在查询和解析过程中遇到困难，可以试图改变缺省设置。客户机几乎总是试图进行递归查询。2000DNS服务器的缺省值是当到达一个前向服务器时，就试图进行递归查询，而到达其他DNS服务器时便发出迭代查询。第11章讨论了对2000DNS服务器的设置，包括怎样设置迭代查询及如何只接受迭代查询。
如前所述，当查询正常工作时，整个过程对客户机来说是透明的，以下是一个跟踪反向域名查询的样本，它以ping命令开始：
可以注意到“QuesrionName”是反向的IP地址；20.40.25.198.in-arpa，它是PTR类型的。
它将IP地址发送给DNS服务器，询问与IP地址相对应的主机名。可以看到，所有的工作对客户端来总都是透明的。记住如果DNS服务器的记录和缓存中并没有该主机的信息，DNS服务器实际自己主动向另外的服务器查询，找到的回答正是客户机需要的和最终看到的。在这种情况下，表面之下进行的工作其实是非常复杂的。在这里被递归查询的与IP地址相对应的主机名是一个在WINS上注册的NetBIOS名。所以，执行解析的DNS服务器必须支持WINS-R记录(见第4章)。于是，DNS服务器不是转向WINS或在它的in-addr.arpa授权中查找而是对该IP地址执行了“适配器状态（adapterstatus）”。关键是无论递归查询引发了多少工作以及何种工作，对于客户端来说都是一样的。
5.5小结
本章描述了标准的DNS查询是如何进行的。查询的过程在本书的其他地方也有描述，如第2章和第3章，但不如本章完整。
(完)
【责编:admin】
--------------------next---------------------
