RFC2181翻译，对DNS 规范的澄清（亚哥一路走好）

本座第一个 编外语： RFC是个晦涩难懂的东西 。

今天 （2011.1.14） 知道了跳楼的人原来是亚哥 ，亚哥走好吧 。

原文 ： http://www.faqs.org/rfcs/rfc2181.html

网络组                                                            R. Elz

要求评论: 2181                                                墨尔本大学

更新: 1034, 1035, 1123                                           R. Bush

分类: 标准跟踪                                                 RGnet公司

                                                              1997年7月

对DNS 规范的澄清

这个备忘录的状态

   这个文档为因特网社区提供一个因特网标准跟踪协议，并且要求读者进行讨论和提出建议以 便改进。请参考 “因特网官方协议标准（Internet Official Protocol Standards）”（STD 1）的当前版本，以了解本协议的标准化状态 。对这个备忘录的传播是不受限制的 。

1. 摘要

   这个文档关注的是域名系统（Domain Name System ）规范中某些被确认为是问题的领域，并且为那些问题提出改进建议。涉及 8个独立的问题：

     + 来自多宿主服务器的IP 包中的包头地址使用，

     + 拥有相同的名字、类和类型的记录集中的TTL，

     + 对区分片（zone cuts）的正确处理，

     + 3个关于SOA 记录和它们的使用的小问题，

     + 生存时间（Time to Live）（TTL）的准确定义

     + 对TC（截断的（truncated））这个包头标志位的使用

     + 什么是权威（authoritative 或者canonical）域名，

     + 一个有效的DNS 标签由什么组成。

   前6条是当前不能明确得知其正确行为的问题 ，我们试图改正它们 。另外 2点是已经明确说明的东西 ，然而人们似乎在某些时候忽略了它们 。我们试图对已有的规范进行加强 。

内容

    1  摘要  ........................................   1

    2  介绍  ........................................   2

    3  术语  ........................................   3

    4  服务器的回复源地址选择  ......................   3

    5  资源记录集（这是本座看这篇文章的目的）  ......   4

    6  区分片  ......................................   8

    7  权威服务器资源记录（SOA RR）  ................  10

    8  生存时间(TTL)  ...............................  10

    9  TC(截断的) 包头位  ...........................  11

   10  命名问题  ....................................  11

   11  命名语法  ....................................  13

   12  安全性考虑  ..................................  14

   13  参考  ........................................  14

   14  致谢  ........................................  15

   15  作者地址  ....................................  15

2. 介绍

   这些年以来，人们记录下了域名系统规范[RFC1034, RFC1035]中的一些问题[RFC1123]。这个文档提出另外一些问题 。这里提出的问题都是独立的 。 那些问题包括：在回复一个查询时，一个多宿主 DNS 服务器应当使用哪个源地址 ； 对于具有相同的标签 、类和类型的 DNS 记录，使用不同的生存时间；什么是权威域名；CNAME 记录与什么相关；在 DNS 的什么部分 ，允许使用什么域名；DNS 域名的有效语法是什么样的。

   在这个备忘录里，对DNS 规范进行澄清，以避免这些问题。还有 RFC1034 中关于权威服务器记录的一个小的歧义性问题 、对TTL （生存时间）的定义和TC 位的用法中某些可能引起误解的问题。

3. 术语

   这个备忘录不使用那些常用的词语必须 、 应当 、 可以 或者是它们的否定形式。在某些小节中 ，可能会看到某个规范是以很温柔的方式叙述的 ，因此这也可能暗示着那个规范是可 选的。那个看法不对 。无论在任何地方 ，当这个备忘录建议应当或者必须进行某个动作 、或者某种行为可被接受或者不可接受的时候， 都应当被看成是本规范的一个基本要求 ，而不管用的是什么词语。如果某个行为或者动作真的是可 选的，那么就会用明文指出。

4. 服务器回复源地址选择

   如果不是全部的DNS 客户端都这么做 ，那么至少是大多数客户端 都会预期自己所收到的回复的来源地址是与自己所发送请求的地址相同的 。对于那种以客户端的角色进行递归查询的服务器以及简单的域名解析客户端来说 ，确实是这样的。回复包中的地址和标识 （ID） 被用来区分不同的回复，以及用来过滤可疑的回复。这一点 ，在DNS 设计时 ，可能是倾向于这么做，也可能是不倾向于这么做，但是现在它已成为了事实 。

   某些运行DNS 服务器的多宿主主机在生成一个回复包时，使用与客户端的请求包中的目标地址不同的地址来做为源地址 。这样的回复会 被客户端忽略，因为源地址与客户端当初向其发送请求的主机地址不符 。那样 ，它就被当成一个多管闲事的回复。

4.1. UDP源地址选择

   为了避免这个问题，当服务器使用UDP来对查询进行应答时，必须使用 与包含请求信息的数据包中的IP 包头的目标地址字段相同的 地址作为IP 包头的源地址字段 。如果这将导致从一个不允许进行这项活动的IP 地址发送回复，那么 ，可以使用服务器拥有的任意有效 IP 地址来发送回复 。应当对那个地址进行挑选 ，也使得客户端在未来的查询中使用那个地址的可能性最大化 。当那些并非所有地址 都可达的服务器在对发往任意播、多播或者类似地址的查询进行响应时 ，需要仔细维护。

4.2. 端口号选择

   对所有查询的回复都应当发往它们被发出的源端口｡当查询是从TCP 接收到的时,那么这一点直接从传输层协议继承咯｡对于通过UDP 接收的查询,服务器必须对源端口进行记录,并且在回复中使用它来作为目标端口｡回复应当一直从它们被发往的端口发出｡在极端情况下例外,这就是广为人知用于DNS查询的端口[RFC1700]｡

5. 资源记录集

   每个DNS资源记录(RR)都有一个标签、类 （class） 、类型 （type） 和数据。两个记录同时拥有相同的标签 、 类、类型和数据 的情况是无意义的 －服务器发现这样的重复记录时应当清除掉 。然而 ，有可能多数记录拥有相同的标签 、类和类型，只是拥有不同的数据 。这样的一组记录就 被定义为资源记录集(RRSet) 。

5.1. 发送RRSet中的RR

   对一个指定(或者未指定)的标签､类和种类的查询永远会返回关联的资源记录集中的全部记录 -无论它是一个还是多个资源记录｡如果整个资源记录集无法完全包含在回复包中 ,那么应当将回复包标记为 “截断的 (truncated) ”｡

5.2. 一个资源记录集中的资源记录的生存时间

   资源记录也拥有一个生存时间(TTL)。一个资源记录集中的资源记录可能拥有不同的生存时间 。并没有发现不能以其它更好的方法来解决的情况 。反过来，这可能会导致从一个缓存服务器发出不完全的回复 （没有标记为“截断的”），其中的某些资源记录但不是全部的资源记录的生存时间已经过期咯 。

   因此，不赞成对同一个资源记录集中的资源记录使用不同的生存时间 ，同一个资源记录集中的全部资源记录的生存时间必须保持一 致。

   如果某个客户端收到的回复中的某个资源记录集里的资源记录拥有不同的生存时间,那么它应当把这个当成一个错误 ｡如果这个资源记录集是来自一个非权威的数据源的 ,那么客户端应当简单地忽略这个资源记录集 ,并且 ,如果这些值是必需的,那么就尝试从一个权威的数据源获取这些信息｡那些 被配置为向一个或者多个特定的服务器发送全部的查询请求的客户端应当将那些服务器当成权威服务器来对待｡如果某个权威数据源发送了这样一个不堪入 目的资源记录集,那么客户端应该认为这个资源记录集中的全部资源记录的生存时间与 该资源记录集中最小的生存时间相同｡无论如何 ,服务器 都不得发送有多个不同生存时间的资源记录的同一个资源记录集 ｡

5.3. DNSSEC特殊情况

   由DNS 安全规范(DNSSEC)[ RFC2065 ]添加的 2个记录类型要求你们在构造资源记录集时要格外小心 。它们是SIG 和NXT 记录。要注意 ， DNS安全规范还非常新 ，人们仍然没有足够的经验 。当DNS 安全规范逐渐完善时 ，读者应当做好心理准备 ，那就是这个文档中包含的与DNSSEC 相关的信息可能会过时 。

5.3.1. SIG记录和资源记录集

   一个SIG记录为DNS 中的另一个资源记录集提供签名（验证）数据。当一个区 被签名之后，那个区中的每个资源记录集 都会有一个对应的SIG 记录。这个资源记录集的数据类型 被包含在SIG 资源记录的数据里，这样就能指示这个SIG 记录是与哪个资源记录集关联的 。在应用上面的规则时 ，无论何时在回复包中包含一个SIG 记录以验证那个回复的正确性 ，与适当的节点关联的其它全部资源记录集的SIG 记录 都要包含在回复中。 在某些情况下，这将会产生很多很多的记录，而且不会因为把它们设置成肥大的资源记录就会改善。

   因此，特别地 ，允许权威节区仅包含那些与要返回的应答中的类型字段有相同的 “类型覆盖 （type covered） ”字段的SIG 资源记录。然而 ，如果SIG 记录是为了应答对SIG 记录的查询或者对某个域名关联的全部记录的查询 （type=ANY） 而在回复节区中包含 ，那么整个SIG 资源记录集 都要包含在其中，就像任意的其它资源记录类型一样 。

   那些收到在权威节区或者（可能是错误地）附加数据部分包含SIG 记录的应答包的服务器必须意识到：几乎可以肯定并没有将整个资源记录集包含在其中。因此，它们必须以某种方式将那个SIG 记录缓存起来，以便将来收到一个对SIG 记录的查询时能够返回它。实际上， RFC2065 要求只向权威服务器发送SIG 查询 ，以避免引起这里的问题，并且 ，只要还有那些不理解SIG 记录的特殊属性的服务器存在，那么这一点就是必要的。然而 ，将来 ， 在新的实现中对SIG 记录的处理进行仔细的设计 ，应 该 就能够把这个限制放松一些咯 ，所以解析器不需要特别地对待SIG 记录的查询 。

   有些时候，某些指示会说，应当将收到的SIG记录查询转发到一个权威服务器上 ，而不是从缓存中的数据 里面取出并且回复 。这并不必要 －一个知道将SIG 作为特例来处理的服务器更有用 ，它能够按照它们的特性来正确地对SIG 记录进行缓存 。这样 ，服务器就能确定，什么时候可以安全地从缓存中取出数据进行回复 ，什么时候自己没有数据而必须将查询转发出去。

5.3.2. NXT资源记录

   下一个资源记录（Next Resource Records）(NXT)更古怪。对于一个区中的一个特定标签，最多只会有一个NXT 记录，所以表面上来看，资源记录集的问题是微不足道的。然而，在区分片操作中，亲代区和子代区（在 RFC2065 的术语中叫做超区（superzone）和子区（subzone））都会拥有一个相同名字的NXT 记录。那两个NXT 记录不会形成一个资源记录集 ，即使是两个区都保存在同一个服务器上也不会 。 NXT资源记录集永远 都只包含一个资源记录。由于两个NXT 记录 都是可见的，所以存在两个资源记录集。然而 ， 不要求 服务器在收到包含NXT 记录的应答时将这个作为特殊情况对待。它们可以选择注意到两个不同NXT 资源记录集的存在 ，并且将它们当作两个其它类型的不同资源记录集处理 。那样的话 ，就是缓存一个，忽略另一个。当然 ，注重安全的服务器就需要正确地处理收到的回复中的NXT 记录咯 。

5.4. 接收资源记录集

   服务器绝不能将它们收到的回复中的资源记录合并到自己的缓存中以形成一个资源记录集。如果某个回复包中包含了 能够与服务器的缓存中的数据形成资源记录集的 数据 ，那么服务器必须自己判断适当的处理方式 ，或者忽略回复中的资源记录，或者甩掉当前在缓存中的整个资源记录集 。因此 ，也不用担心缓存和回复中的生存时间不同的问题 ，总有一个会 被甩掉。也就是说 ，如果某个回复中的数据与缓存中的数据不相同 ，那么必然有一个数据不正确。对于服务器来说 ，需要费脑筋来确定哪个数据是正确的，如果某个是正确的 ，那么保留它，甩掉另一个。注意 ，如果服务器收到的回复中包含的某个资源记录集与它自己的缓存中的是一 致的，而仅仅是生存时间不同，那么它可以自己选择是否将自己缓存中的生存时间更新为应答包中的生存时间 。如果它觉得收到的应答数据比前一次缓存的应答数据更权威 （下一小节讲到），那么它应当这么做。

5.4.1. 对数据进行排名

   在考虑是要接受某个回复中的资源记录集还是要保留自己的缓存中的资源记录集时，服务器应当判断不同的数据的相对可信程度 。从回复中 拿出来的权威应答应当踢掉早些时候从某个回复中的附加信息部分取出来缓存的数据 。然而 ，如果缓存中包含咯来自一个权威应答或者一个区文件的数据 ，那么后面来的回复中的附加信息就应当直接忽视掉 。

   数据的可用性应当依据来源来判断。

   可信度应当从最可信到最不可信排序：

     + 从主要的区文件中来的数据，优先于寄生数据 （glue） ，

     + 从区传送中来的数据，优先于 寄生数据 ，

     + 一个权威应答中的应答节区的权威数据。

     + 来自一个权威应答中的权威节区的数据，

     + 一个主要区中的 寄生数据 ，或者一个区传送中的 寄生数据 ，

     + 来自一个非权威应答的应答节区的数据，以及来自一个权威应答的应答节区的非权威数据 ，

     + 来自一个权威应答的附加信息，来自一个非权威应答的权威节区的数据 ，来自非权威应答的附加信息 。

   注意，一个权威应答的应答节区一般只包含权威数据 。然而 ，如果所查找的域名是一个别名 （参考10.1.1 小节），那么只需要描述那个别名的记录保持为权威的 。客户端应当假设其它记录是来自服务器的缓存的 。如果要求获得权威应答 ，那么客户端应当使用与那个别名关联的规范名来再次查询 。

   从最不可信的那一类来源获得并且缓存的非权威资源记录，也就是从一个附加数据节区 、和从一个非权威应答的权威节区获得的数据，不应当作为那种可以发送给别人的应答来缓存 。在适当的时候 ，可以将它们以附加信息的形式返回。如果忽略咯这一点 ，将会在没有理由的情况下使得相对不可信的数据的可信度上升 。

   如果使用咯DNS 安全规范[ RFC2065 ] ,并且收到咯一个权威应答 ,还验证咯它,那么这个数据就应当看作比同类型的非权威数据更可信咯 ｡注意 ,在这个文档中 , "权威"的意思就是指那个应答中的AA 位设置为真 ｡ DNSSEC使用可信的SIG 和 键(KEY) 记录链来决定数据的权威性 ,AA 位几乎是无关的 ｡然而 ,会搞 DNSSEC的服务器还是必须在回复中正确地设置AA 位 ,以让那些当前还不会搞安全的服务器 (现在几乎就是全部的)正确地操作｡

   注意，除了 寄生数据以 外，不可能让以下数据冲突 ：来自两个正确配置的主要区文件的数据 ；来自两个正确配置的次要区 （来自区传送的数据）的数据；来自正确配置的主要和次要区的数据 。如果在多个区中 都包含有同一个域名的寄生数据 ，并且值还不一样，那么域名服务器应当优先选择使用主要区文件中的数据 ，不过也可以选择这种数据的任意一个集合。

   在决定该选择哪个数据时，可以选择那个看起来是来自一个 与权威数据源比较近的 数据源的数据 ，这样可能会有效。如果存在不正确的 寄生数据 ，那么优先选择主要数据源将使得更迅速地发现这种问题 。如果一个服务器从两个区文件中探测到其中的一个或者多个配置得有问题 ，以 致于产生咯冲突，那么它应当拒绝载入那些 明知是错误的区 ，并且提供适当的诊断信息。

（搞个鸟，作者不在前面写这一段解释，搞得本座把glue理解错咯）前面所说的"寄生数据 （glue）"指一个区文件中任意的不严格属于那个区的记录，这包括 ：委托的子区 的域名服务器记录（NS记录）、补充那些NS 记录的地址记录 （A 、 AAAA等等）和其它任意的可能出现的散落数据 。

5.5. 发送资源记录集（重奏 （reprise） ）

   在任何DNS 回复中，一个资源记录集只应当被包含一次。如果需要的话 ，它可以出现在应答、权威或者附加信息中的任何节区。然而 ，除非是某个规范显式要求的 ，它不 能在相同或者任何其它的节区中重复出现。例如 ，AXFR 回复要求SOA记录 （永远是只包含一个资源记录的资源记录集）同时作为回复包的第一个和最后一个记录。如果像这样要求有重复数据，那么每次传输的生存时间都必须保持一致 。

6. 区分片

   DNS 树被划分成一个个的"区"，它们是一些域的集合 ，为了特定的管理目的而当成一个单位 。区是通过 “区分片”来划分的。每次的区分片都从一个 “亲代”区（分割线以上）中分离出一个“子代”区（分割线以下）。在一个区的顶部 （正位于将那个区从亲代区分开的线的下面） 出现的域名被称做那个区的 “起源”。该区的名字与该区的起源的域的名字一致。每个区由DNS树的以下子集组成 ：在该区的起源处或者下面 ，并且在那条将该区与它的子代区 （如果有的话）分离开的线的上面 。区分片的存在是由亲代区通过NS 记录的存在而指示出来的 ，那些记录指明了子代区的起源。子代区并不包含对亲代区的任何显式的引用。

6.1. 区的权威性

   一个区的权威服务器是在该区的起源的NS 记录里面枚举的，这些记录与一个权威开始 （Start of Authority）(SOA)记录，是每个区中必有的记录 。这样的一个服务器对于一个不在别的区中的区的全部资源记录都是权威的 。那些用来指示一个区分片的NS 记录是属于新创建的子代区的 ，那个子代区的起源的任何记录也都是的 ，以及它的任何子域都是的 。为某个区服务的服务器不应当为与另一个区中的名字相关的查询返回权威应答 ，这包含NS 记录 、可能包含区分片中的A 记录，除非它也碰巧是另一个区的服务器 。

   除了下面即将讲到的DNSSEC 情况之外，服务器应当忽略掉除了NS 记录以及必要的用来找到NS 记录中列出的服务器的A 记录以外的记录，它们可能会在一次区分片中被配置到区里。

6.2. DNSSEC问题

   DNS安全机制[ RFC2065 ]使得这一点更复杂 ，与其它的DNS 资源记录相比 ，新加进去的某些资源记录类型是极不平常的。尤其是NXT("下一个 （next） ") 资源记录包含着关于哪些名字存在于一个区中的信息 ，因此也包含了哪些名字不存在于一个区中的信息 ，这样它就有必要与它存在于其中的区关联 。同一个域名可能在亲代区和子代区中拥有不同的NXT 记录 ，并且都是有效的 ，并且不是一个资源记录集。参考5.3.2 小节。

   由于NXT 记录倾向于是自动生成的，而不是由DNS 管理员配置的 ，所以，服务器可以 但不是必须这样做 ：将它们接收到的所有的不同的NXT 记录都保留下来 ，而不用理会5.4 小节中的规则。

   为了让一个安全的亲代区来安全地指示出某个子区是不安全的，DNSSEC要求有一个键资源记录（KEY RR）来指示出那个子区是不安全的，并且亲代区的权威SIG 资源记录存在于亲代区中 ，因为根据定义来看它们不可能存在于子区中 。如果某个子区是安全的 ，那个键和SIG 记录会存在于那个区中 ，并且是权威的，但是它们必须一直存在于亲代区中 （如果是安全的）。

   注意,无论什么情况下 ,为亲代区而不为子区服务的服务器都不能在为一个区分片上的标签作应答时设置AA位 ｡

7. 权威开始资源记录

   有3个关于权威区开始 （Start of Zone of Authority）(SOA)资源记录的问题需要澄清。

7.1. 在权威应答中放置权威开始资源记录

RFC1034 的3.7 小节指示 ：一个权威应答的权威节区可以包含从中取出该应答的区的SOA 记录 。在讨论消极缓存时 ， RFC1034 的4.3.4 小节提到了这个技术 ，但是也提到了应答包中的附加节区 。前者是正确的 ，因为在 RFC1034 的6.2.5 小节中的示例已经暗示了这一点 。如果添加了SOA记录 ，那么就要把它们放到权威节区。

7.2. 权威开始资源记录的生存时间

   可能你们注意到了 ，在 RFC1035 中用来定义资源记录的格式的3.2.1 小节里 ，在定义生存时间字段的地方 ，去掉了一行 ，它说的是一个SOA 记录的生存时间应当一直设置成 0以避免缓存。在别的任何地方都没有这么说过 ，而且普遍地没有这么实现。在你们的实现中不应当假设SOA 记录的生存时间会是 0，并且不要求在实现中发送生存时间为 0的SOA 记录。

7.3. SOA.MNAME字段

   在规范中写得很明白，但是似乎被大家忽略了，SOA 记录的MNAME 字段应当包含由这个SOA 认证的区的主要 （主 （master） ）服务器的名字。它不应当包含这个区自己的名字。那个信息将是无用的 ，因为 ，为了发现那个信息，人就需要从那个SOA 记录的域名开始 －而那个就是区的名字。

8. 生存时间(TTL)

   在STD 13 中对生存时间字段的值的定义是不够清楚的，问题是关于这两点的 ：哪几位是有意义的 ？那个值是有符号的还是无符号的 ？在这里 ，明确指出，生存时间的值是一个无符号数 ，最小值是0 ，最大值是2147483647。最大值也就是2 31 - 1 。在传输的时候，这个值应当存储在生存时间字段的 32位里的31个低位中 ，而它的最高位或者说是符号位应当设置成 0.

   在实现中，如果收到的生存时间的值里面的最高位设置成 咯1，那么就应当将整个值当成 0.

   在实现中，可自行决定为自已接收到的任何的生存时间设置一个上限 ，并且将大于这个上限的任何值当成这个上限的值 。生存时间指定的是一个生存的最大时间 ，而不是一个必须生存的时间。

9. 包头中的TC(截断的) 位

   TC 位仅仅在以下情况才应当设置：需要将某个资源记录集放置到某个回复包中 ，却又无法完整地包含在其中 。位不应当在这种情况下设置：可能还会包含其它的信息 ，却没有足够的空间咯。这种情况包括对附加节区进行处理的结果。在这种情况下 ，无法整个放到回复包中去的资源记录集应当被省略 ，并且回复包按照原样发送 ，不要设置TC 位 。如果收到回复包的东西需要那些被省略的数据，那么它可以再为那些数据构建一个查询 ，并且单独发送出来。

   如果设置咯TC 位，那么无法完整放置到回复包中去的那一部分资源记录集可以被忽略掉 。如果一个DNS 客户端接收到的回复包中设置咯TC位 ， 那么它应当忽略那个回复，并且使用其它的方式再次查询 ，例如通过TCP 连接，那样就能传送更大的回复包咯 。

10. 命名问题

   有些时候，根据DNS规范[ RFC1034 , RFC1035 ]中的某些小节可以推断出：一个主机或者也有可能是一个主机的一个接口仅允许拥有一个权威或者官方名字，那个名字叫做规范名。在DNS 中没有这种要求 。

10.1. CNAME资源记录

   DNS CNAME("规范名")记录用来为一个别名提供关联的规范名｡对于每个别名 ,最多只能有一个这样的规范名｡那个名字通常应当是在DNS 中别的地方都存在的一个名字 ,然而会有某些罕见的应用 ,它们的别名在DNS 中没有对应的规范名 ｡如果使用咯DNSSEC ,那么 ,一个别名 (某个CNAME 记录的标签)可以拥有SIG､NXT 和键资源记录 , 但是不能拥有其它数据｡也就是说 ,对于DNS 中的任意标签 (任意域名),以下几点中只有一点是正确的 :

     + 存在一个CNAME 记录，并且可能存在对应的SIG、NXT 和键资源记录 ，

     + 存在一个或多个记录，没有任何一个是CNAME 记录，

     + 名字存在，但是没有关联的任何类型的资源记录，

     + 名字根本不存在。

10.1.1. CNAME术语

   传统的做法是把一个CNAME 记录的标签说成是“一个 CNAME”。这一点非常遗憾，因为"CNAME"是 “规范名 （canonical name） ” 的缩写 ，而一个CNAME 记录的标签几乎可以肯定不会是一个规范名 。然而，这是一个根深蒂固的用法。因此，需要特别注意：弄清楚所表示的是一个CNAME 资源记录的标签还是它的值(规范名) 。在这个文档中 ，一个CNAME 资源记录的标签一直都是指它的别名 。

10.2. PTR记录

   对于规范名的困惑导致咯人们认为一个PTR记录的资源记录集中应当只有一个资源记录。这是不正确的， RFC1034 的相关小节 （ 3.6.2 小节 ）指明咯 ，一个 PTR 记录的值应当是一个规范名 。 也就是说 ，它不应当是一个别名。在那个小节里面没有暗示说一个名字只能有一个 PTR 记录。 不应当推测认为有这种的限制。

   注意，由于一个PTR 记录的值不能是别名，因此，对于不与任何别名相关的PTR 记录，不需要解析。那个被查询它的PTR值的标签可能会有一个CNAME 记录。也就是说，它可能是一个别名。那个CNAME 资源记录的值 ，如果不是另一个别名，当然它也不应当是另一个别名 ，将会给出可以找到PTR 记录的位置。那个记录为PTR 类型的查询给出咯结果。这个最终结果 ，那个PTR 资源记录的值 ，就是标签，它不能是一个别名。

10.3. MX 和NS 记录

作为一个NS 资源记录的值或者一个MX 资源记录的值的一部分的域名不能是一个别名。不仅仅是规范中明确指出咯这一点，而且在这两个位置使用别名的话既不会按照预期地正常工作也不会令那个这么做的人达到自己的目的。这个域名必须拥有一个或者多个地址记录作为它的值。当前 ，那些记录就是A 记录，然而在将来可能会有其它记录类型来给出地址信息 。它也可以拥有其它资源记录 ，但是不会有CNAME 资源记录。

   对NS 或者MX 记录的搜索会导致“附加节区的处理”，在那个过程中 ，与查询的记录关联的地址记录会被附加到回复中 。这样有助于避免不必要的额外查询，因为当客户端做咯第一个查询之后，就能预料得到。

   附加节区处理不包含CNAME 记录，更不用说那些可能与从别名衍生出来的规范名关联的地址记录咯。所以 ，如果使用咯一个别名来作为某个NS 或者MX 记录的值 ，那么不会为那个NS 或者MX值返回任何地址 。这会导致额外的查询，以及每次查询引起的额外网络负担。对于DNS 管理猿来说 ，要避免这一点是简单的：每当有记录被更新或者加入时 ，解析它的别名并且直接将规范名放到受影响的记录中去 。在某些极端情况下 ，如果一个NS 查询的结果里面没有附加节区地址记录 ，可能会导致查询过程失败。

11. 名字语法

   有此时候，人们会假设域名系统只提供以下服务：将互联网主机名映射为数据 ，以及将互联网地址映射为主机名 。这是不对的 ，DNS 是一个通用的 （如果有某种限制的话）层次化数据库，并且几乎可以为任何目的存储任何类型的数据 。

   DNS本身只对可用于识别资源记录的特定标签有一个限制。那个限制与标签的长度和完整名字有关。任一个标签的长度都限制在 1 到63 个字节之间。一个完整的域名不能超过255 个字节 （包括分隔符）。长度为 0的完整名字被定义为表示DNS 树的根，并且一般写为"." 。除咯那些限制之外，可以使用任何的二进制字符串来作为任何资源记录的标签 。类似地 ，任何的二进制字符串都可以作为任何包含一个域名的记录的值 （SOA 、 NS 、 MX 、 PTR 、 CNAME以及其它任何可能会添加的类型）。对DNS 协议的实现不能向可能使用的标签施加任何限制 。特别地 ，DNS服务器不能因为某个区包含咯可能不被某些DNS 客户端程序接受的标签而拒绝为那个区服务。DNS 服务器可以让自己被配置成这样的：如果一个主要区包含一些被认为是有问题的标签 ，那么在载入的时候发出警告，甚至是拒绝载入 ， 然而 ，不应当在默认的情况下这么做。

   然而,注意,各种各样使用DNS数据的程序可能会对它们环境中可接受的特定值有限制｡例如,任意的二进制标签都可以拥有一个MX记录,但这并不意味着任意的二进制名字都可以用于一个电子邮件地址中的主机部分｡DNS客户端可以针对它们的环境来对它们用于DNS查询请求的关键字的值以及DNS返回的值施加任何限制｡如果客户端有这种限制,那么它要完全负责在使用来自DNS的数据之前检查那个数据,以确保那个数据是可接受的 ｡

   参考[ RFC1123 ]的6.1.3.5 小节 。

12. 安全性考虑

   这个文档不考虑安全性。

   特别地，4 小节中的任何东西都不与任何安全性目的相关 ，也不是用于任何安全性目的的。

   5.4.1 小节也不与安全性相关。DNS 数据的安全性是由安全DNS（Secure DNS）[RFC2065]来保障的，而那个东西与这个备忘录几乎是没有冲突的。

   作者相信，这个文档中的任何东西都不会在DNS 中增加新的安全性问题 ，也不会减轻任何的安全性问题 。对这个文档中的澄清内容进行正确的实现 ，可能会稍微地限制DNS 中无意产生的坏数据的传播，但是只有DNSSEC可能帮助解决对 DNS 数据的恶意破坏。

13. 参考

   [ RFC1034 ]   Mockapetris, P., "域名 －概念和工具 ",

               STD 13, RFC 1034 , 1987 年 11月。

   [ RFC1035 ]   Mockapetris, P., "域名 －实现和规范 ", STD 13, RFC 1035 , 1987 年 11月。

   [ RFC1123 ]   Braden, R., "互联网主机的需求 －应用和支持 ", STD 3, RFC 1123 , 1989 年 1月。

   [ RFC1700 ]   Reynolds, J., Postel, J., "被分配的数字",

               STD 2, RFC 1700 , 1994 年 10月。

   [ RFC2065 ]   Eastlake, D., Kaufman, C., "域名系统安全扩展", RFC 2065 , 1997 年 1月。

14. 致谢

   这个备忘录是在1995 和1996 年由IETF 的DNSIND 工作组讨论得出的，那个工作组的成员对这里的观点负责。特别感谢 ：Donald E. Eastlake三世和Olafur Gudmundsson,为本文档中的DNSSEC 问题提供帮助。John Gilmore指出咯这个澄清文档里面没有足够地澄清的地方。Bob Halley建议澄清一下在权威应答中放置SOA 记录的位置，并且提供了参考。同样地 ，Michael Patton、Mark Andrews、Alan Barrett和Stan Barber对很多细节提供咯帮助。Josh Littlefield帮助咯确保这个澄清文档不会在某些烦人的旮旯里引起问题。

15. 作者的地址

   Robert Elz

   计算机科学

   墨尔本大学

   Parkville, Victoria, 3052

   澳大利亚。

   电子邮件 ： kre@munnari.OZ.AU

   Randy Bush

   RGnet公司。

   5147 Crystal Springs Drive NE

   Bainbridge Island, Washington,  98110

   美国。

   电子邮件 ： randy@psg.com