DNS协议概述( 五 )


包括查询名和其它参数
Answer
包括查询结果的RR
Authority
包括一个RR,但这个RR包括的是另一个名字服务器
Additional
包括了一个些在其它部分中使用RR时会有用的信息
请注重:因头中操作符(码)的不同,这些部分的内容可能不同,但格式可是一样的 。
2.7.1. 标准查询
标准查询指定一个目标域名(QNAME),查询类型(QTYPE)和查询类(QCLASS),然后寻找相应的RR,这类的查询占了DNS查询的绝大部分,假如未有非凡说明,一般都指这种查询 。
QTYPE和QCLASS域为16位,是定义的type和class的超集 。QTYPE域可以包括:
:和相应类型相匹配的RR matches just that type. (e.g., A, PTR).
AXFR:由QTYPE指定的特定区
MAILB:和RR相关的所有邮箱
*:所有RR类型
QCLASS域可以包括:
:和相应类相匹配的RR
*:所有的RR类
使用查询域名,QTYPE和QCLASS,名字服务器就会检查相应的RR,服务器可以返回一个可能包括相应RR的服务器名 。例如:希望向Mockapetris@ISI.EDU发邮件,应用程序会向resolver要求了解关于ISI.EDU的信息,会产生下面的查询:QNAME=ISI.EDU,QTYPE=MX,QCLASS=IN,可能产生响应的区可能是:
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
随此以外还有:
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
VENERA.ISI.EDU. A 10.1.0.52
A 128.9.0.32
服务器假设假如请求者希望得到邮件交换(exchange)信息,它会马上请求交换服务器的地址,所以找到两个 。这里需要注重QCLASS=*类型的查询,因为服务器不可能知道了解域名系统中所有类的可用信息,它也不是所有类的认证权威,因此这类查询不能得到认证 。
2.7.2. 反向查询(可选)
名字服务器可以反映资源和域名之间的映射关系 。标准查询可以对将域名映射到SOA RR,相应的反向查询则映射SOA RR到域名 。
对于名字服务器来说这种实现是可选的,但是所有的名字服务器必须至少能够理解反向查询消息,不能说发来的消息当不知道 。域名系统不保证反向查询的完全和唯一性,因为系统是按照域名而非主机地址或其它资源类型安排的 。反向查询主要用于调试,以及和数据库支持相关的活动中 。反向查询可以不返回正确的TTL,也不标明RR是某个集合中的一员,我们不知道它是不是唯一的,因此反向查询的结果不缓冲 。反向查询对于映射主机地址到主机名是不合适的,此时要用IN-ADDR.ARPA域 。
2.8. 状态查询(实验中)
没有定义
2.9. 完整查询(过时的)
这里就不说了,以后可能会支持重设计(redegsign)服务 。
3. 名字服务器
3.1. 介绍
名字服务器保存了许多信息,这些信息组成了域数据库 。数据库被分为区,这些区在不同的服务器上保存 。服务器可以有不同的可选函数和数据源,它最基本的工作是响应查询,它的响应是是一种简单的形式进行的,响应可以仅根据本地数据作出,也可以根据其它相关服务器而做出 。一个给定的区可以根据不同的服务器来保证其有效性,通过治理命令,用户可以查询由至少两台服务器保存的一个区上的数据,多台服务器保存信息保证了适当的冗余 。
给定的名字服务器通常支持一个或多个区,但只充当域树一小部分的认证权威 。它有一些缓冲的非认证信息,这些信息是域树其它部分的,在响应查询时名字服务器会给出什么时它认证的,什么是它缓冲的 。
3.2. 数据库如何被划分为区
划分数据库有两种方法,一种是根据class,另一种是在名字空间的结点间进行分隔,而产生,我们称这种分隔为cut 。class(以下我们称为类)分隔比较简单,在传统上,名字空间和所有类是一回事,分隔的类可被认为是一系列平行的名字空间树 。创建新类的通常理由是要为已有的类型创建新的数据格式,或是为了对已有的名字空间进行分隔治理 。在一个类中可在两个相邻的结点进行cut(以下我们称为切分),在所有的切分完成后,相连空间的每个组就是一个独立的区 。此区是在相连区域内所有数据的认证权威 。

推荐阅读