所有这些数据以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有多个别名
指定的名字服务器不存在
临时错误
如果未请求循环查询或不支持循环查询,则响应可以可能是:
- 认证权威服务器指出名字不存在
- 临时错误