2.6. 资源记录

　　域名标记结点，每个结点都有资源信息集，些集可以为空。资源信息集和由分离资源集（RR）的特殊名字相关联。在集中的RR顺序没有关系，标记有这东西就是了，它不用由名字服务器，resovler或DNS的其它部分保存，只在这儿有。特定的RR我们认为有以下几个：

　　拥有资源的名字通常是隐式的，不构成RR的一部分。TTL时间只影响缓冲内的数据，不影响区内的已经保存的认证数据。TTL通常由管理员设置，TTL=0表示禁止缓冲。RDATA内的数据是二进制串和域名的混合。域名通常使用指针指向DNS内的其它数据。

　　2.6.1. RR的文本表示

　　RR在DNS中是以二进制形式表示的，而在名字服务器或resolver中保存的时是经过压缩编码处理的。本文中我们采用相同于主文件中表示的表示方法，也就是不压缩的方法，以便显示RR的内容。行开始时给出谁拥有RR，如果这一位置空出，就表示本行RR的拥有者和上面RR的拥有者是一个。其后是TTL，type和RR的class。RR的RDATA部分是在当前数据的表示类型的基础上得到的。下面是一些RR的例子：

　　ISI.EDU. MX 10 VENERA.ISI.EDU.

　　MX 10 VAXA.ISI.EDU.

　　VENERA.ISI.EDU. A 128.9.0.32

　　A 10.1.0.52

　　VAXA.ISI.EDU. A 10.2.0.27

　　A 128.9.0.33

　　其中我们注意到MX那一部分，它的RDATA部分有是一个16位数后面跟一个域名组成。其它的也就不说了。本例子显示了6个RR，第三个域名有两个RR。下面是一个例子，它显示在不同的class下如何表示：

　　XX.LCS.MIT.EDU. IN A 10.0.0.44

　　CH A MIT.EDU. 2420

　　2.6.2. 别名和统一命名

　　现存的系统中有时会对相同的资源有不同的命名，不但主机是这样，邮箱也是这样，不同的名字指向的是同一个位置。大部分系统都能够对多个名字指定一个是统一命名的结果，另外的是别名。域名系统提供使用统一命名的机制（CNAME RR），CNAME RR标记它的owner名为别名，并指出在RDATA部分的相应统一命名。如果一个结点存在CNAME RR，不应该有其它的数据，这保证了统一命名和它的别名不能不同。这也使得缓冲的CNAME可以不用检索认证权威服务器就可以提供服务。在有CNAME RR时，DNS软件如果查询不到与域名相关的资源，它会检查资源集中是不是有一个有匹配class的CNAME，如果有，名字服务器返回的应答中包括这个CNAME记录，并根据在CNAME中指定的数据开始新的查询。下面我们看一个例子，假设名字服务器处理对USC-ISIC.ARPA的查询，它要求查询A信息，下面是RR的内容：

　　USC-ISIC.ARPA IN CNAME C.ISI.EDU

　　C.ISI.EDU IN A 10.0.0.52

　　这两个RR都作为响应返回，而只查询CNAME的*查询则只返回CNAME。

　　RR中指向其它名字的域名应该指向主名而不是别名，这就避免了查询中过多的转向查询。例如，对于上面的RR，它的IN-ADDR.ARPA记录应该是：

　　52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU

　　最后指向的是C.ISI.EDU，而不是USC-ISIC.ARPA，当然一个健壮的域名软件不会因为提供了循环的CNAME而失败。

　　2.7. 查询

　　查询就是发向名字服务器要求响应的一个请求。在Internet上，这种请求以UDP或TCP传输，名字服务器的响应可以是查询结果，或是另一个名字名字器地址，要么就是一个错误信息。通常用户并不直接发送请求，而是向resolver发送请求，由resolver依次将一个或多个请求发向名字服务器，并负责处理错误情况。请求和响应有标准格式，它们包括一个头和数个固定的域，然后是包括查询参数和RR的四个部分。头中最重要的域是称为操作符的东西，它指出要进行什么操作。在所有可能的16个值中，标准查询是必须的，反向查询和状态查询是可选的，有一个完全查询已经过时，其它的还未指定。而上面的提到的四个部分如下：

　　请注意：因头中操作符（码）的不同，这些部分的内容可能不同，但格式可是一样的。

　　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的服务器名。例如：希望向MockapetrisISI.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（以下我们称为切分），在所有的切分完成后，相连空间的每个组就是一个独立的区。此区是在相连区域内所有数据的认证权威。

　　这种方法意味着所有的区至少有一个结点，域名和所有特定区内的结点是相连的。给定的树型结构一定有一个点更加靠近根，我们用这个点标记这个区。虽然可能没什么用，也可以将每个域名分在不同的区中，也可以让所有的结点在一个区中。另外，数据库也可根据不同企业对名字的控制进行划分，有些企业可能希望自己管理某一部分域名子树，这时这个企业就可以对域名进行相应的增加或删除操作，可以自己加入自己的下一级域名。当然，这个企业也可以对自己管理的名字空间进行进一步划分。

　　3.2.1. 技术问题

　　描述一个区的数据有四部分：

1. 　　区中所有结点的认证数据

2. 　　定义区内顶结点的数据（此数据可被认为是认证数据的一部分）

3. 　　描述代表子区的数据

4. 　　访问服务器子区的数据（我们也称为“相关”（glue）数据）

　　所有这些数据以RR的形式表示，所有区可以被RR集的形式描述。通过传输RR，可以传输整个区，具体的方法可以是通过FTP传输相应的文本文件，或是通过网络消息的形式传输。一个区的认证数据是所有的RR，这些RR和树中所有的结点是关联的，要么就是切分后的结点关联。描述顶结点的RR对于区的管理特别重要，这些RR有两种类型，名字服务器RR，它描述了区中的服务器列表；另一种是SOA RR，它描述的区的管理参数。

　　描述切分的RR是NS RR，因为切分是在结点间进行的，所有RR不是区认证数据的一部分，它应该和相应的在子区内的顶结点一致。因为名字服务器通常和区边界相关，NS RR只在一些区的顶结点上有。在组成一个区的数据中，NS RR在顶层结点和在边界底的切分处出现，不在其它地方。

　　区结构所要实现的一个目标是任何区都有足够的数据可以和任何子区建立通信。也就是说，父区有足够的信息可以访问子区中的任何一台名字服务器。NS RR命名了子区服务器，它不足以完成上面的要求，因此有了名字但仍然不知道地址。特别地，如果名字服务器的名字在子区内是它自己，我们就无法知道通过它的任何信息了。为了解决这一问题，区中包括了一个关联RR，它不是认证权威数据的一部分，但它表示了服务器的地址。如果名字服务器名在切分下，就需要这些RR了。

　　3.2.2. 管理问题

　　当有些组织希望掌握自己的域时，第一步是标记合适的父区，然后取得父区中管理结点的许可来管理。管理的时候没有什么具体的技术问题，可是还是有一些规则的，对中型的区可以没有这些规定，但是小型的就不行了。本文不具体讨论这一问题了，有兴趣可参阅相关的资料。

　　一旦选择了子区的名字，此区的新管理结点要冗余的名字服务器来支持。注意：没有要求一个区的服务器必须在此域中有名字的主机上。在许多种情况下，一个区要想被更容易地访问到最好把内容放得分散一点，不要集中在一起。现在许多国家的名字服务器是放置在别国的，这样在取得名字解析的时候不用把请求千里迢迢送到远程主机上去了。作为配置的最后一步，就是要选择NS RR和关联RR。

　　3.3. 深入名字服务器

　　3.3.1. 查询和响应

　　名字服务器的主要内容就是响应标准查询。查询和响应有专用的格式，查询包括QTYPE，QCLASS和QNAME，它描述了需要数据的类型，类（class）和名字。服务器的响应取决于它支持不支持循环查询：

• 　　最简单的是不支持循环查询，它返回的要么是本地信息，要么是一个错误码，告诉用户你要的信息这里没有，然后再返回一个邻近服务器的地址，让用户到那里去查一查。

• 　　如果支持循环查询，那名字服务器如果未能在本地找到相应的信息，就代替用户向其它服务器进行查询，这时它是代替用户扮演了resolver的角色，直到最后把结果找到（也可能根本没有结果，那就返回错误），并返回给用户为止。

　　使用循环查询要客户和服务器双方都支持才行。这个信息通过查询和响应中的两位来交换：

• 　　如果允许循环查询则设置RA位，服务器方可以不管客户是否进行请求而直接设置此位

• 　　查询中如果请求循环查询则设置RD位，客户只有在知道服务器方支持循环查询后才能够进行循环查询请求

　　客户可以在响应中同时设置RA和RD位来确认是否支持循环查询请求。请注意：服务器在客户未指明RD位时不会自己进行循环查询。

　　如果请求了循环查询，同时也支持循环查询，对查询的响应会是以下之一：

• 　　查询指定的CNAME RR有多个别名

• 　　指定的名字服务器不存在

• 　　临时错误

　　如果未请求循环查询或不支持循环查询，则响应可以可能是：

　　- 认证权威服务器指出名字不存在

　　- 临时错误

　　另外还会提供一些信息，指出所查询的RR是否从一个区来，或者是不是被缓存；另一种信息指明名字服务器指出还有一个服务器拥有相同的记录，这个服务器更靠近要查询的名字的祖先。