BBS水木清华站∶精华区
原始文件：file.lst(make file.lst)
bind-4.9.3-BETA9
档案叙述：名称伺服器操作指引
文件编号：LRG.LDTP.GUIDE.001
翻译日期：1995/12/10
翻译维护：asdchen@pc2.hinet.net O
---------------------------------------------------------------Ｘ---
O
Name Server Operations Guide
for BIND
Release 4.9.3
Releases from 4.9
Paul Vixie1
<paul@vix.com>
Vixie Enterprises
Redwood City, CA
Releases through 4.8.3
Kevin J. Dunlap2
Michael J. Karels
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Sciences
University of California
Berkeley, CA 94720
1. 简介
柏克莱网际网路名称系统(The Berkeley Internet Name Domain
BIND)是为 BSD 作业系统所实作的一套网际网路名称伺服器。这一套
BIND 包括有一个伺服器（或称为隐形程式 "daemon"）以及一套解答
器程式库(resolver library)。名称伺服器是一种让客户端(client)
能够使用名称来称呼资源或目标并且与网路上其它物件分享这些资讯
的一项网路服务。它其实是一种电脑网路上的分散式物件资料库系统
。BIND 完全整合在 BSD（ 4.3 版或以後）的网路程式里用来储放及
撷取主机名称与位址。系统管理者可以将系统配置成使用 BIND 来取
代对主机档案 /etc/hosts 进行主机表格查阅 (host table lookup)
取得资讯的旧有方式。BSD 预设的配置是使用 BIND。
____________________
1 This author was employed by Digital Equipment Corpora-
tion's Network Systems Laboratory during the development and
release of BIND 4.9. Release 4.9.2 was sponsored by Vixie
Enterprises. Releases from 4.9.3 were sponsored by the In-
ternet Software Consortium.
2 This author was an employee of Digital Equipment Corpo-
ration's ULTRIX Engineering Advanced Development Group and
was on loan to CSRG when this work was done. ULTRIX is a
trademark of Digital Equipment Corporation.
2. 建立(building)具有名称伺服器的系统
BIND 系由两个部份所组成。 其中之一称为 resolver 是由一群
存放在 C 程式库 /lib/libc.a 里面的函式组成的使用者界面。第二
个部份是称为 named 的真正伺服器。这是一个在背景中执行并且在
所给的网路埠号上提供查询服务的隐形程式。由 UDP 以及 TCP 使用
的标准埠号在 /etc/services 里指定。
2.1. 在 libc 里的解答器函式
在建立你的 4.3BSD 系统时你可以建立 C 程式库以便使用
名称伺服器的解答器函式或是使用主机表格查阅函式来解决主机
名称与位址的解析。 4.3BSD 预设的解答器是使用名称伺服器。
较新的 BSD 系统同时包含有名称伺服器以及主机表格两种功能
端视是否有执行名称伺服器或是有 /etc/resolv.conf 档案决定
运作的方式。
建立 C 程式库使用名称伺服器会改变 gethostbyname(3N)
gethostbyaddr(3N) 以及 sethostent(3N) 的运作方式。名称伺
服器使得 gethostent(3N) 成为过时的，因为它不知道资料库里
下一行资料的含意。这些程式库呼叫以及需要查询名称伺服器的
解答器函式是一起建立的。
解答器包括有产生查询封包以及与名称伺服器交换这些封包
的函数。
在建立 4.3BSD 的 C 程式库之前，请先在 /usr/src/lib/
libc/Makefile 里面设定变数 HOSTLOOKUP 等於 named。然後你
就可以制作(make)并且安装 C 程式库以及编译器然後接著编译
4.3BSD 系统的其它部份。更详细的资讯可以参阅 "Install and
Operating 4.3BSD on the VAX" 第 6.6 节。
如果你的作业系统并非是 VAX 4.3BSD 的话，可能的情况是
你的供应商已经将解答器的支援包含在其所提供的 C 程式库里
面。你应该参考你供应商的文件以找出他们起始解答器的支援的
动作。注意到相对於 BIND 提供的解答器你供应商的解答器可能
在某些方面是过时的，而且你可能想要建立 BIND 解答器程式库
并且安装它，以及它所包含的档案，到你系统的编译／连结路径
中以便让你自己的网路应用程式能够使用较新的特色。
2.2. 名称服务
名称伺服器的基本功能是以回答查询的方式提供关於网路上
之目标的资讯。名称伺服器详细规格定义在 RFC1034， RFC1035
以及 RFC974 里面。这些文件可以在 4.3BSD 的 /usr/src/etc/
named/doc 下找到或者可以从 ftp.rs.internic.net 传输回去
。同时也建议你去阅读相关的线上手册(manual pages)说明包括
named(8)、resolver(3) 以及 resolver(5)。
使用名称伺服器而不使用主机表格查阅方式解析主机名称的
好处是避免需要为所有的名称建立一个单一的集中管理交换处。
这些资讯的认可(authority)可以授权(delegated)给网路上负责
它们的各个不同组织。
主机表格查阅函式需要有一个中央由少数人来维护整个网路
的主档(master file) 。这在只有少数机器而且负责它们的组织
可以相互合作的小网路上运作良好。但是在机器横跨组织□围的
大网路上运作得并不好。
配合名称伺服器，网路可以被分为一些领域的阶层式组织。
名称空间(name space)根据组织或是管理的□围组织成树状。每
个节点(node)，称为一个领域(domain)，都被赋予一个标签，而
领域的名称是从树根(root)到目前领域之间所有领域标签的连结
，由右至左以点隔开列出。一个标签只需在其领域里是唯一的。
整个空间被分割成数个称为区域(zone)的□围，每个区域从一个
领域开始向下扩展直到叶(leaf)领域或是开始其它区域的领域。
一台位於加州柏克莱大学的主机其主机位址□例看起来会像下面
这样：
monet.Berkekey.EDU
教育组织的最高阶层领域是 EDU，Berkeley 是 EDU 的一个副领
域(subdomain)而 monet 是该主机的名称。
____________________
|VAX is a Trademark of Digital Equipment Corporation
2.3. 关於 Hesiod，以及 HS-类别的资源记录(Resource Records)
Hesiod，系由麻省理工学院的 Athena 计画所发展，是一个
在 BIND 之上所建立的资讯服务。它的意图跟 Sun 的 NIS 类似
：由一套程式提供遍及整个设备上关於使用者、群组、网路档案
系统存取、列印能力及邮递服务等等资讯。Hesiod 与 NIS 之间
除了它使用 BIND 而非分离的伺服器程式码之外的重要差异在於
Hesiod 并不试图处理密码以及验证，而只处理那些在安全上较
不敏感的资料。 Hesiod 伺服器可以藉著在 BIND 伺服器上增加
资源记录来实作；或者它们可以当作被分开来维护的独立伺服器
来实作。
要学习以及取得 Hesiod 以匿名(anonymous)的方式 FTP 到
ATHENADIST.MIT.EDU 主机并且取得 /pub/ATHENA/hesiod.tar.Z
这个压缩的包裹(tar)档案。你不需要该套件里面的 named 以及
resolver 程式库部份因为它们的功能已经都被整合到 4.9 版的
BIND 中。要学习 Athena 计算环境里 Hesiod 部份的功能如何
使用从上述的 FTP 伺服主机取得 /pub/ATHENA/usenix/athena-
changes.PS 该份文件。那里也有一个□例的 Hesiod 原始码包
裹档案。
是否应该使用 Hesiod 类别是个见仁见智的问题，因为相同
的服务可以适当地配合 IN 类别，TXT 型态以及 CNAME 型态来
提供。每种情况， Hesiod 的程式码及文件都会建议如何设定及
使用该服务。
注意到虽然 BIND 包含有对 HS-类别查询的支援，非 IN 类
别的区域移转逻辑仍然是实验性的。
2.4. 关於″安全区域″(secure zones)
安全区域是以区域为基础在一个区域上实作 named 的安全
保护。它的设计是使用一个可以从该区域获得特别资讯的网路或
主机的许可列表。
为了区域安全(zone security) 功能的使用，named 必须以
定义 SECURE_ZONES 编译而且你最少得要有一个安全区域的 TXT
资源记录。除非所给的区域存在一个安全区域记录，在该区域里
的资料不会被加上限制。安全区域的 TXT 资源记录格式是：
secure_zone addr-class TXT string
位址类别可以是 HS 或 IN 。TXT 字串的语法不是″网路位
址：网路遮罩″就是″主机 IP 位址：Ｈ″。
″网路位址：网路遮罩″允许从一整个网路过来的查询。如
果省略网路遮罩的话，named 将会使用网路位置指定的预设网路
遮罩。
″主机 IP 位址：Ｈ″允许从一台主机过来的查询。在 ":"
之後的 "H" 是用来分别主机位址与网路位址所必须的。在相同
区域档案里允许多个安全区域 TXT 资源记录。
例如，你可以增加下列两个 TXT 资源记录来设定一个只会
回答从网路遮罩过的 130.215.0.0 该 class B 网路以及从一台
位址为 128.23.10.56 的台主机过来 Hesiod 要求的区域：
secure_zone HS TXT "130.215.0.0:255.255.0.0"
secure_zone HS TXT "128.233.10.56:H"
这个特色可以用来限制对一个 Hesiod 密码对映的存取或是
在一台防火墙(firewall)机器上分离内部与外部网际网路的位址
解析而不必为内部及外部的位址解析分别执行一个名称伺服器。
注意到你得要将你的回授界面(loopback)界面包含在你的安
全区域记录里，否则你当地的客户端将不能解析名称。
3. 区域的型态
一个″区域″是在树状领域名称系统上授权的点。它包括有除了
那些被授权给其它伺服器的名称之外从一个确定的点″向下延伸″的
所有名称。一个″授权点″ 在其″父区域(parent zone)″里有一个
或是更多的 NS 记录，在″授权区域″树根里与其相等的 NS 记录应
该要与这些记录符合（i.e., 在区域档案里的 "@" 名称）。
了解″区域″跟″领域″之间的不同对於名称伺服器的适当运作
有关键性的影响。例如，考虑 DEC.COM 这个领域，即使 DEC.COM 这
个区域仅包含对 PA.DEC.COM 以及 CRL.DEC.COM 区域的授权该领域
仍包含像是 POBOX1.PA.DEC.COM 以及 QUABBIN.CRL.DEC.COM 这样的
名称。一个区域可以确实地对映到单一个领域，但是也可以只包含一
个领域的一部份（其它部份可以授权给其它的名称伺服器）。技术性
的说法是，在树状领域名称系统上的每一个名称都是一个″领域″，
即使它是一个″终端″，也就是说，没有″副领域″。技术性的说法
是，每一个副领域都是一个领域而且除了领域名称系统的根以外每一
个领域也都是一个副领域。这个术语并不符合直觉所以你最好要阅读
RFS's 1033,1034 以及 1035 来取得对这个困难又微妙主题的完整了
解。
虽然 BIND 是一个领域名称伺服器(Domain Name Server)，它主
要处理的是区域。在 named.boot 档案里的 primary 及 secondary
宣告是指定区域，而不是领域。当你询问某人是否要成为你的领域的
次要伺服器(secondary server)时实际上是在要求对於某些区域集合
的次要服务(secondary service)。
每个区域会有一个″主要(primary)″ 伺服器，它会从一些由人
们编辑或者可能是由机器由其它人们编辑的档案产生的本地档案载入
区域内容的资料。然後会有一些″次要(secondary)″ 伺服器，它们
使用 IP/DNS 协定（意思是，次要伺服器将会以 IP/TCP 联络主要伺
服器并接取该区域）载入区域内容的资料。这些伺服器（主要伺服器
以及所有的次要伺服器）应该列在其父区域的 NS 记录里，它将会设
立一个″授权″。这些伺服器也必须列在它自己的区域档案里，通常
在 "@" 名称这个意思为目前 $ORIGIN 的″最高阶层(top level) ″
或″根(ROOT)″的神奇符号之下。你可以在区域的最高阶层 "@" NS
记录里列出不在其父区域 NS 授权的伺服器，但是你不能在父区域的
授权里列出不存在於该领域的 "@" 。（後面这个情形是称为″无用
授权(lame delegation)″ 的形式之一）。
4. 伺服器的型态
伺服器并非真的有″型态(type)″。一台伺服器可以是一些区域
的主要伺服器同时还是其它区域的次要伺服器，或者它可以只是一台
主要伺服器，或只是一台次要伺服器，或者它也可以不负责任何区域
而只是经由它的″暂存区(cache)″ 来回答查询。这份文件的上个版
本提及″主宰(master)″以及″从属(slave)″ 但是我们现在感觉到
其间的差异 － 而且对於一台名称伺服器而言型态指配并没有用处。
4.1. 暂存专用伺服器(Caching Only Server)
所有的伺服器都是暂存伺服器。意思是伺服器会暂存其接收
到的资讯来使用直到资料的暂存期满为止。一台暂存专用伺服器
是一台不负责认可任何领域的伺服器。这种伺服器提供查询服务
并且询问其它负责认可所需资讯的伺服器。所有的伺服器都会在
它们的暂存区里暂存资料直到资料的暂存期满为止，暂存期限则
根据一个为所有资源记录维护的 TTL（存留时间(Time To Live)
）栏位而定。
4.2. 远端伺服器(Remote Server)
远端伺服器是给那些想要从他们的工作站或是只有有限数量
记忆体以及中央处理器处理周期的机器来使用名称伺服器的一个
选项。使用这个选项你不必在本地的机器上执行名称伺服器就可
以执行所有使用名称伺服器的网路程式。所有的查询都由网路上
其它机器所执行的名称伺服器来服务。这种主机在技术上并不是
″伺服器″，因为它没有暂存区而且不回答查询。一台主机在其
/etc/resolv.conf 档案里只列出远端主机，而且没有在它自己
上面执行名称伺服器，有时被称为一台远端伺服器但更常被简单
地称为领域名称系统客户端(DNS client)。
4.3. 从属伺服器(Slave Server)
从属伺服器是一台总是将它无法由它自己的暂存区满足的查
询转送(forwards)出去， 到一个固定的转送伺服器(forwarding
servers)列表以取代自己与根领域或是其他领域的名称伺服器进
行交谈。送往转送伺服器的查询是递回式查询。可以有一个或更
多的转送主机，而它们都会被尝试直到该列表用完。一个从属以
及转送这样的配置一般是用在当你不希望某地的所有伺服器都与
网际网路上的其它伺服器交谈时。常有的剧情中包括一些工作站
与一台部门里具有网际网路存取能力的分时机器。这些工作站在
管理上可能被禁止存取网际网路。要让给这些工作站适当地存取
网际网路名称系统的话，这些工作站可以是这台会转送查询并且
在传回答案之前与其它名称伺服器交谈以解决该查询的分时机器
的从属。使用转送特性附加的好处是在中央的机器累积出一个更
完整的资讯暂存区而且使所有的工作站都能加以利用。从属模式
以及转送的使用在 named 启动档指令描述该节下有更进一步的
讨论。
对於要宣告一台伺服器成为从属伺服器而言并没有任何禁止
条件即使它也有主要／或次要的区域；其效果仍然是任何在本地
伺服器的暂存区或区域里的东西将会被答覆，而任何其它的东西
将会使用转送者列表(forders list)转送出去。
5. 设立你自己的领域
在设立一个将要放上公开网路的领域时管理人员应该要联络负责
该网路的组织并且请求适当的领域注册格式。一个属於多个网路的组
织（像是网际网路以及国际学术网路）应该只在一个网路上注册。
联络方式如下：
5.1. 网际网路(Internet)
在网际网路上需要设立领域资讯的站台应该联络它们网路的
注册者，即以下所列其中之一：
MILnet HOSTMASTER@NIC.DDN.MIL
other HOSTMASTER@RS.INTERNIC.NET
你也可能想要被放到 BIND 的邮递列表里，这是个在网际网路上
执行 BIND 的人们的邮寄群。这个群体讨论未来设计的决策、运
作上的问题、以及其它相关的主题。请求放到这份邮递列表的联
络位址是：
bind-request@uunet.uu.net
5.2. 国际学术网路(BITNET)
如果你是在国际学术网路上并且需要设立一个领域的话请联
络 INFO@BITNTC
5.3. 现有领域的副领域
如果你想要现有领域的一个副领域的话，你应该找出父领域
的联络点而不是要求上面所列最高阶层注册者其中之一。应该要
有个约定使 register@domain 或是 hostmaster@domain 永远都
是任何一个领域注册者的别名（有点类似 postmaster ）。然而
并没有这样的约定存在。把它当作是最後的尝试，但首先你应该
检验该领域的 SOA 记录并且送信给其内所显示的 ″负责人″。
(responsible person)
6. 档案
名称伺服器使用数个档案承载资料库。在这一节涵盖 named 所
需要这些档案以及它们的格式。
6.1. 启动档(Boot File)
这是在 named 开始启动时所读取的第一个档案。 这个档案
告诉伺服器它属於什麽型态，它负责认可哪个区域以及何处取得
初始资料。这个档案预设的位置是放在 /etc/named.boot。然而
这可以在你编译 named 的时候设定 BOOTFILE 变数加以指定或
是开始启动 names 时在指令列上指定位置。
6.1.1. Domain
可以用像下面这样一行来指定一个预设的领域给名称
伺服器
domain Berkeley.Edu
较旧的名称伺服器在它们接到一个没有 "." 且它不知道
的名称查询时使用这个资讯。较新的设计假定解答器程式
库将会对任何没有设限(unqualified) 的名称附加它自己
所认定的″预设领域(default domain)″。虽然名称伺服
器仍然可以加上支援在启动档中使用 domain 指令的选项
来编译，预设是将它省略而且我们热切地建议不要使用它
。如果你使用这个特性，那麽在你领域之外的客户端传送
没有设限的名称要求给你时将会隐含你的领域限制而不是
他们的。适合使用这个功能的地方是在客户端，在它们的
/etc/resolv.conf（或相等的）档案里。强烈地不建议在
你的启动档中使用 domain 指令。
6.1.2. Directory
这个 directory 指令指定名称伺服器应该在哪个目
录下执行，这允许在启动档案中的其它档案名称使用相对
路径名称。只能够有一个 directory 指令而且它应该在
任何其它指定档案名称的指令之前给予。
directory /var/named
如果你有很多很多的 named 档案要维护，你可能会希望
把这些 named 档案放在一个像是 /var/named 这样的目
录下并且适当地调整 directory 指令。 这个指令的主要
目的是当尝试使用 $INCLUDE 以相对目录名称将档案含入
的时候确定 named 是在适当的目录里而且允许 named 在
一个如果它觉得 urge 时可以合理 dump core 的地方。
6.1.3. Primary Service
在启动档中指示该伺服器为一台主要伺服器的指令行
看起来像是下面这样：
primary Berkeley.Edu ucbhosts
第一个栏位指定该伺服器是一台第二个栏位所叙述区域的
主要伺服器。第三个栏位是要从中读取资料的档案名称。
上述设定假定你所指定的区域是一个类别为 IN 个区
域。如果你希望指示一个不同类别那麽你可以在第一个栏
位後面附加 /类别，其中的类别不是整数数值就是标准的
助忆类别。例如指示 hesiod 类别区域的一台主要伺服器
指令行看起来像是下面这样：
primary/HS Berkeley.Edu hesiod.data
注意到这个对於 IN 以外区域类别的支援是一个编译时期
选项而你的供应商在建立你的系统时可能没有打开。
6.1.4. Secondary Service
指示次要伺服器的指令行类似主要伺服器除了它列出
取得区域资料来源的其它伺服器（通常是主要伺服器）之
位址。
secondary Berkeley.Edu 128.32.0.10 128.32.0.4 ucbhosts.bak
第一个栏位指定该伺服器是第二个栏位所叙述区域的一台
次要伺服器。该二个网路位址指定存有区域资料的名称伺
服器。注意到至少其中一台必须要是主要伺服器，而且，
除非你使用 IP/DNS 以外的协定作为你的区域移转 (zone
transfer) 机制，其它的全部都是其它次要伺服器。要求
你的次要伺服器从其它的次要伺服器拉资料通常是不聪明
的，因为如果你的网路是以不正常但是很普遍的方式连接
线路的话你可以对区域更新的传播加上延迟。试图在次要
伺服器的宣告上使用多个位址是在主要伺服器有多个网路
界面因而有多个主机位址的时候。次要伺服器透过网路从
所列出的伺服器其中之一取得其资料。这些伺服器位址会
依列出的顺序被尝试。如果在主要伺服器列表後面存在有
一个档案名称的话，该区域的资料会被倾倒到该档案作为
备份。当伺服器第一次开始启动的时候，如果可能的话将
会从备份档载入资料，然後接著会联络主要伺服器来检查
区域资料是否仍然跟得上时代。注意到以次要伺服器列出
你的伺服器并不需使它成为一个 — 父区域必须授权认可
给你的伺服器如同给主要或其它的次要伺服器，否则你将
会移转一个没有理由移转的的区域；除非父区域将你列为
该区域的伺服器没有其它的伺服器将会有理由对你查询该
区域。
如同主要伺服器你可以在 secondary 关键字的後面
加上 /类别指定该次要伺服器给一个 IN 以外的类别，eg
secondary/HS。
6.1.5. Stub Service
宣告 stub 伺服器的指令行类似次要伺服器（这个特
性在 4.9.3 是实验性的。）
stub Berkeley.Edu 128.32.0.10 128.32.0.4 ucbhosts.bak
第一个栏位指定该伺服器是第二个栏位所叙述区域的一台
stub 伺服器。
Stub 区域的意图是要确认一个区域的主要伺服器对
其子区域的伺服器一定有正确的 NS 记录。如果该主要伺
服器并非是其一个子区域的一台次要伺服器那麽它应该要
被配置为它所有子区域的 stub 区域。 Stub 区域提供一
个机制允许一个区域的 NS 记录只在一个地方加以指定。
primary CSIRO.AU csiro.dat
stub dms.CSIRO.AU 130.155.16.1 dms.stub
stub dap.CSIRO.AU 130.155.98.1 dap.stub
6.1.6. Caching Server
你不需要一行特别的指令指示一台伺服器为一台暂存
伺服器。表明其为一台″暂存专用″伺服器的是缺乏指定
认可指令行，像在启动档里的 secondary 或 primary 。
所有的伺服器，包括″暂存专用″伺服器，在启动档
里都都应该有像下面这样一行指令来准备名称伺服器的暂
存区：
cache . root.cache
所有列出的暂存档案都将会在 named 启动时被读进来而
且任何仍然有效的值都将被回复到暂存区里且在暂存档中
的根名称伺服器资讯将会被继续使用直到有一个根查询被
在你暂存档中的名称伺服器之一实际回答为止，此时该回
答将会被持续使用直到暂存期满为止而你的暂存档将会被
忽略。
如同主要以及次要伺服器， 你可以在 cache 关键字
的後面加上 /类别指定该暂存专用伺服器给一个 IN 以外
的类别，e.g., class/HS。
6.1.7. Forwarders
任何的伺服器都可以利用转问者(forwarder)。 一个
转问者是另一台能够处理递回式查询也就是自愿帮助其它
系统去尝试解析查询的伺服器。此 forwarders 指令使用
网际网路位址像下面这样指定转问者：
forwarders 128.32.0.10 128.32.0.4
有两个主要的原因会想这样做。首先，有些系统可能没有
完整的网路存取能力而且可能被阻止传送任何 IP 封包到
网际网路的其它地方而因此依赖一个可以完整存取网路的
转问者。第二个原因是该转问者把所有查询的集合当作是
它伺服器的而因此建立一个与一般工作站上的名称伺服器
相较更为丰富的资料暂存区。在效果上，该转问者变成一
个超暂存机(meta-cache)所有的主机都可以从它那里得到
好处，因而减少从这个地方到网路其它地方的查询总数。
″转问者″的使用是准备一些固定的名称伺服器位址
列表对每个查询加以尝试。一般而言这个列表只由对相关
领域经由 NS 记录查阅所找到更高的认可伺服器所组成。
如果转问者没有回答查询，那麽除非有给 slave 模式指
令，将会直接查询负责该领域的适当伺服器。
6.1.8. Slave Servers
从属模式是使用在如果因为缺乏完整网路存取能力的
缘故或者是你希望避免名称伺服器使用除了所列出以外的
其它转问者而使得转问者的使用成为解析查询唯一可行的
方法。从属模式以在启动档里的这样一行简单指令起始
slave
如果使用 slave 的话，那麽你必须指定转问者。 处於从
属模式中时，该伺服器将会转问每一个转问者每一个查询
直到找出一个答案或者是转问者列表用尽为止。该伺服器
将不会尝试去联络任何在转问者列表里所指名以外的远端
名称伺服器。
所以当 forwarders 在尝试″伺服器列表″位址的时
候，slave 使得该″伺服器列表″里只包含列出在转问者
宣告里的位址。不小心地使用 slave 指令可能引起真的
很可怕的转问回圈，因为你只有在一些同样也是从属主机
的集合而且它们其中之一或数个可以转问你时才可能停止
查询的转问。
Slave 的使用应该要非常小心地加以考虑。
6.1.9. Zone Transfer Restriction
一种可能的情况是你的组织并不希望给予任何在网际
网路上可以接触你名称伺服器的人一份你所有主机的完整
列表。虽然人们仍然可能以″重复″经过你的位址□围，
寻找 PTR 记录，并且以″缓慢″的方式建立一份你所有
主机的列表，经由区域移转协定限制你区域的输出仍然是
合理的考虑。要限制可以从你的伺服器移转区域的邻居的
列表，使用xfrnets指令。
除了你可以在主机位址外加列网路号码以外这个指令
具有跟 forwarders 相同的语法。例如如果你只想许可在
网路号码为 16 的 class A 网路里的主机从你的伺服器
移转区域的话，你可以加上这个指令
xfrnets 16.0.0.0
这种限制方式并不是很充份，未来的 BIND 版本将会许可
以每台主机为基础来指定这种存取控制而不是目前这种以
每个网路为基础的方式。注意到当位址没有明确的遮罩时
会被这个指令假定为网路，你可以视你希望限定多少而定
指定一个遮罩，也许包含该位址的所有位元那麽如此一来
只有单一主机取得转移的许可。例如，考虑
xfrnets 16.1.0.28&255.255.255.255
这将只许可 16.1.0.2 主机从你这里转移区域。注意到在
引介一个网路遮罩的 "&" 字元周围不允许有任何空白。
为与 BIND 4.9 过渡时期版本之间的相容性考量这个
xfrnets 指令也可以当作 tcplist。
6.1.10. Sorting Address
如果 BIND 想要联络的名称伺服器有多个位址，BIND
首先将会尝试它相信是″最近的″的那一个。″最近″的
定义在此是指位址的类似(similarity-of-address) ；这
是说，如果一个位址位於一个与本地主机上的界面相同的
子网路上，那麽首先会尝试那个位址。失败後，首先会再
尝试相同网路上的位址。失败後，除非在 named.boot 档
案里给定 sortlist 指令否则将会以更为随机或更不随机
(more-or-less)的顺序尝试它们。 sortlist 指令有类似
於 forwarder，xfrnets，以及 bogusns 的语法 － 你给
它一个以点设限(dotted-quad) 的网路列表而它优先使用
这些列表来″参考″一些远端名称伺服器。如果没有提供
明确的遮罩给 sortlist 里的每个成员，其中之一将会以
位址的高位元为基础来推论。
如果你是在一个 Class C 网路上且有一个 Class B
网路位於你以及网际网路的其它部份之间，你可以试著在
sortlist 指令中列出该 Class B 的网路号码来增进名称
伺服器取得回答的幸运程度。这对尝试更″远的″伺服器
之前尝试″更近的″伺服器而言应该有效果。注意到这个
动作是 BIND 4.9 新增的。
这个 sortlist 指令其它的以及较旧的效果是会使得
BIND 去排列它所产生的任何回应里的 A 记录，所以效果
如同将他们比那些没有出现的记录更早放在 sortlist 上
。这并不像你可能想像的那麽有帮助，因为许多客户端会
随机地或使用後进先出(LIFO)的方式记录 A 记录；同样
的，考虑伺服器无法猜测客户端网路拓扑这个事实，所以
因此无法对所有可能的客户端排列出真正″最近″的。在
解答器里执行排列明显地更为优良。
在实际使用上，不使用这个指令是因为它会束缚改变
迅速的资讯；一个在今天是″接近″的网路下个月可能是
″远离″的。因为 BIND 会建立远端名称伺服器回应时间
的暂存区，它会很快地聚集″合理的″伺服器，这跟″最
佳的″并不相同但已经足够近的。 BIND 未来的方向包含
以本地界面为基础选择位址（在有一个以上界面的主机）
或许以递送表(routing table) 的资讯为基础。我们并不
倾向於解决一般的 "multihomed host" 问题，但是我们
应该能够比我们现在所作的更好。除此之外，我们还希望
见到使用只存在於客户端主机上的拓扑资讯来排列回应的
的更高阶解答器程式库。
6.1.11. Bogus Name Servers
偶而会发生有些远端的名称伺服器″坏掉″的情况。
你可以在你的 named.boot 启动档里以 bogusns 指令告
诉你的名称伺服器拒绝监听或查询这些其它名称伺服器。
它的语法与 forwarder，xfrnets，及 sortlist 相同 －
你只要给它一个以点设限的网际网路位址列表。 Bogusns
位址，除非配合明显的遮罩设限，都假定是主机位址。
6.1.12. Segmented Boot Files
如果你是许多区域的次要伺服器，你可能会发现将你
的 named.boot 切成一个难得改变的静态部份（例如像是
directory，sortlist，xfrnets，以及 cache 这些指令
可以放这里），以及一个经常改变的动态部份（你所有的
primary 指令可以放在一个档案，而你所有的 secondary
指令可以放在另外一个档案里 － 而且每一个或两个档案
都可以从一些邻近的地方自动接取所以它们可以改变你的
次要区域列表而不必要求你积极协调）是方便的。你可以
经由 include 指令完成这件工作，它只需要一个档案名
称作为它的参数。档案名称的周围不需要有什麽限制。该
档案名称在名称伺服器将其工作目录到切换到 directory
指令里所指定的地方之後评估，所以如果你的系统支援它
们的话那麽你可以使用相对路径名称。
6.1.13. Number of Concurrent Subprocesses
BIND 在同一时间内产生达 10 个副程序提供给次要
伺服器接取区域使用。这个 max-fetch 指令可以像下面
这样用来超越预设的值：
max-fetch 5
6.2. 名称解答器配置(Resolver Configuration)
如果名称解答器无法找到它的配置档的话将会尝试联络本地
主机上的名称伺服器。无论如何你都应该在每一台主机上安装该
配置档，因为如果本地主机执行名称伺服器的话你也可以将本地
主机的位址列出，而且不建议任何其它指定系统层次预设领域的
方法。注意到如果你希望在你的解答器配置档里列出本地主机，
那麽你应该使用其主要的网际网路位址而不是 127.0.0.1 或是
像 0.0.0.0 这类的本地主机别名。 这个原因归归咎某些版本的
BSD 网路程式码里处理连接 SOCK_DGRAM 插槽上的错误。如果你
必须使用位址别称的话，你应该优先使用 0.0.0.0 （或简单的
"0"） 而不是 127.0.0.1，虽然这是根据你所使用的 BSD－衍生
的网路程式码不同而有不同警告，但是这两者都可能以它们自己
的方式出错。
该配置档的名称是 /etc/resolv.conf 。这个档案指示应该
将查询传送到网路上的哪台名称伺服器。即使你执行名称伺服器
建立这个档案仍然是合理的考虑，因为其内容在客户端执行第一
解答器函式次呼叫的时候将会被每一个客户端的解答器程式库所
暂存。如果你在本地上面执行名称伺服器，在你的 resolv.conf
档案里将它列出。
该 resolv.conf 包含数个指令，每行一个，形式如下：
;comment
#another comment
domain local-domain
search search-list
nameserveer server-address
sortlist sort-list
options option-list
应该要确实地给予 domain 或是 search 指令其中之一。如果给
予 search 指令，所给搜寻列表(search-list) 的第一个项目会
超越任何先前指定的本地领域(local-domain)。而 nameserver
指令可以下达三次；额外的 nameserver 指令将会被忽略。注解
行可以使用 ";" 或是 "#" 开始；注意到注解在早於 BIND 4.9
所包含的解答器中是不被许可的 － 所以如果你供应商的解答器
支援注解的话，你知道你已经在地球上了。
本地领域将会被附加到任何没有包含 "." 的查询名称上。
本地领域可以利用设定 LOCALDOMAIN 这个环境变数以每个程序
(per-proess)为基础加以超越。注意到本地领域的处理过程可以
在解答器中设定一个选项加以取消。
搜寻列表是一个会被尝试的领域列表，依序，就像是为没有
设限的领域设限领域。注意到搜寻列表处理过程可以在解答器中
设定一个选项加以取消。同时也要注意环境变数 "LOCALDOMAIN"
可以以每个程序为基础超越此搜寻列表。
伺服器位址是个集合而且被当作由解答器所产生查询的预设
目的地。这是，换句话说，是你告诉解答器它应该使用哪个名称
伺服器的方法。客户应用程式要超越这个列表是有可能的，而且
这在名称伺服器里（它自己本身也是解答器客户）以及测试程式
像是 nslookup 中经常发生。
排序列表是一个 IP 位址，网路遮罩配对的列表，所有使用
gethostname 返回的位址会以这个列表所指定的顺序排列。任何
不符合位址 － 网路遮罩配对的位址会在那些符合的位址之後才
返回。网路遮罩是一个选项而且如果没有加以指定将会使用自然
的网路遮罩。
选项列表是一个其中每个选项都超越一些解答器内部变数的
选项列表。目前所支援的选项是。
debug
在 _res.options. 中设 RES_DEBUG 位元
ndots:n
对给予 res_query() 的名称设定较低的门槛（以″点的数
目″衡量）所以具有比该数目更多点的名称将会在进行本地
领域或是搜寻列表程序之前先当作绝对名称来尝试。这个内
部变数的预设值是 "1"。
最後，如果设有 HOSTALIASES 环境变数，它被用来包含那
些包括解答器阶层别名的档案的名称。这些别名只有对那些没有
包括任何 "." 字元的名称才会应用，而且它们在查询产生之前
被应用到查询名称(query-names) 上。注意到支配本地领域以及
搜寻列表选项的解答器选项不会应用 HOSTALIAS。
6.3. 暂存区初始(Cache Initialization)
6.3.1. root.cache
名称伺服器需要知道负责认可该网路根领域的名称伺
服器。要完成这件工作我们必须以这些认可较高的位址来
准备名称伺服器的暂存区。这个档案的位置在启动档里指
定。这个档案使用这份文件後面涵盖的标准资源记录格式
(Standard Resource Record Format. aka. Masterfile
format)。
6.3.2. named.local
这个档案指定网路位址为 127.0.0.1 的本地回授界
面(local loopback interface)，更知名的称呼是本地主
主机(local host) ，的 PTR 记录。这个档案的位置在启
动档里指定。每一台名称伺服器的 127.0.0.1 这个位址
都要有一个 PTR 记录指回到 "localhost" 这个名称在适
当的运作上是一件非常重要的事。这个 PTR 记录的名称
永远都是 "1.0.0.127.IN-ADDR.ARP"。如果你想要让你的
使用者能使用主机名称验证 (hostname-authentication.
hosts.equiv or ~l.rhosts) 的话这是必须的。如同这个
PTR 所记录暗示的，在包含主机的每个领域资料里应该要
有一个 "localhost.my.dom.ain" 的位址(A)记录(位址为
127.0.0.1)。"localhost." 在 1.0.0.127.in-addr.arpa
限制下将失去它尾巴的点；然後，DEFNAMES 以及／或是
DNSRCH 解答器选项将会使得 "localhost" 的评估如同本
地的领域主机名称一样，而这个意思是在你解答器搜寻路
径的最高阶层领域（或观念上，每一个领域）最好在名称
後面有些东西。
6.4. 领域资料档案(Domain Data Files)
有两个用来指定领域资料的标准档案。 它们是 hosts 以及
host.rev。这些档案使用这份文件後面涵盖的标准资源记录格式
。注意到档案的名称是变动的；许多网路管理人员喜欢在他们所
包括的领域後面命名他们的区域档案，尤其是在所给的是一台有
许多不同区域的主要以及／或是次要伺服器这种一般常见的情况
下。
6.4.1. hosts
这个档案包含关於这个区域里的机器的的所有资料。
这个档案的位置在启动档里指定。
6.4.2. hosts.rev
这个档案指定 IN.ADDR.ARPA 这个领域。这是一个用
来允许进行位址到名称对映的特殊领域。因为网际网路主
机位址并不在领域的□围内，於是产生这个特别的领域来
允许反向对映。该 IN.ADDR.ARPA 领域前面有四个标签。
这些标签符合八个位元一组的网际网路位址。所有这四个
八位元数字都必须指定即使其中一个是零也一样；网际网
路位址 128.32.0.4 位於 4.0.32.128.IN.ADDR.ARPA 这
个领域。这种反向位址不易阅读但是允许自然地组织在一
个网路里的主机。
6.5. 标准资源记录格式(Standard Resource Record Format)
在名称伺服器资料档里的记录称为资源记录。标准资源记录
(RR)指定在 RFC1035 里。 下面是这些记录的一般性描述。
{name} {ttl} addr-class Record Type Record Specific data
资源记录有如上所示的标准格式。第一个栏位永远都是领域纪录
的名称而且它永远必须从第一列(column)开始。对於一个档案里
所有第一个以外的资源记录而言，名称可以保持空白；在这种情
况下它会使用前一个资源记录的名称。第二个栏位是一个选择性
的存留时间栏位。这指定该资料要保存在资料库中多久。使这个
栏位保持空白则预设的时间是在认可起始(Start Of Authority)
资源记录里指定（参阅下述）。第三个栏位是位址类别；目前，
只支援一种类别：给网际网路以及其它网际网路资讯的 IN 。包
含 HS 类别的有限支援，这是给 MIT/Athena "Hesiod" 资讯的
。第四个栏位叙述该资源记录的型态。在它後面的栏位依据资源
记录的型态而定。名称以及资料栏位的大小写在载入到名称伺服
器时会被保留。所有在名称伺服器资料库里的比较以及查阅都是
不理会大小写的。
下列字元有特别的意义：
"." 在名称栏位里的一个独立的点参用目前的领域。
"@" 在名称栏位里的一个独立的 @ 表示目前的基点。
".."在名称栏位里使用两个独立的点时是代表根的无领域名称。
"\X"其中的 X 是任何数字(0-9)以外的字元，对该字元设限使其
原本的特殊意义不作用。例如， "\." 可以在一个标签里使
用点这个字元。
"\DDD"
其中的 D 是一个数字，是一组以 DDD 对应十进位值的八进
位数字。所产生的八进位值假定是文自形式而且不检查特定
意义。
"()"括号用来组成跨越一行的资料。在效果上，在括号里的行结
束符号不会被考虑。
";" 分号开始一段注解；该行剩馀的部份会被忽略。
"*" 星号代表通用字元。注意到这只是另外一个有特殊意义的字
元只有在名称伺服器搜寻选项内部才有意义。通用字元只对
某些资源记录有意义(特别是 MX) ，而且只在名称栏位 －
不是资料栏位。
任何出现名称的地方，无论是在名称栏位或是在一些用来包
含名称的资料栏位 － 如果该名称不是用"." 结束的话都会加上
目前的基点(origin)。这对於在资料後面加上目前领域而言是有
用的，像是机器名称，但是在你并不想这样做的地方可能会引起
麻烦。一个好用的规则是是这样的，如果该名称不在你建立资料
档的领域里，以"." 结束它。
6.5.1. $INCLUDE
一行包含指令是以 $INCLUDE 开始，由第一列起，而
且後面跟随著一个档案名称，而且，选择性的，跟随著一
个在读取此档时暂时的 $ORIGIN 来使用。 这个特性对於
将不同类型的资料分隔到多个档案中特别有用。一个例子
像是这样：
$INCLUDE /usr/local/adm/named/data/mail-exchanges
这行指令会被解译成载入 /usr/local/adm/named/data/
mail-exchanges 这个档案的要求。 该 $INCLUDE 指令不
会使资料载入到不同的区域或树。这只是单纯的一种允许
将所给主要区域资料组织到分隔档案的方法。甚至上面所
描述的″暂时 $ORIGIN″特性也不适合使你的资料分支到
一些其它区域 － 区域的□围只能在启动档里引介。
一个 $INCLUDE 档案的第一个资源记录必须有名称。
这是说，第一行非注解行的第一个字元必须不是空白。父
档案里目前的预设名称不会被带进 &INCLUDE 档案中。
6.5.2. $ORIGIN
这个 origin 是在资料档案中改变基点的一种方法。
该指令行从第一列开始，而後跟随著一个领域基点。这看
起来对於将一个以上的区域放到一个资料档中可能有用，
但是它不是这样作用的。名称伺服器基本上要求所给的区
域完整地对映到一些指定的档案。所以你应该非常小心地
在一个档案的最上面只使用一次 $ORIGIN 指令，或者，
在一个档案里面，用来改变到一个在该区域中″较低″的
领域 － 绝对不要改变到起其它一起的领域。
6.5.3. SOA - Start Of Authority
name {ttl} addr-class SOA Origin Person in Charge
@ IN SOA ucbvax.Berkeley.Edu. kid.ucbvax.Berkeley.Edu.(
1993041403 ;Serial
10800 ;Refresh
1800 ;Retry
3600000 ;Expire
259200) ;Minimum
认可开始，SOA ，记录指示一个区域的开始。 name 是该
区域的名称。Origin 则是存放该资料档案之主机名称。
Person in chage 是该名称伺服器负责人的邮递位址。序
号是这个资料档的版本编号；一旦资料有改变则应该递增
这个号码。旧的伺服器许可在这里使用一个幽灵 "." 而
将其它号码放在区域档案里；n.m 的意义是 "n000m" 而
不是更直觉的 "n*1000+m"（如此 1.234 转成 1000234而
不是 1234）。 这个特性因为含糊以及不可预测还有缺乏
必要而被反对。注意到使用 "YYYYMMDDNN" 式符号你仍然
可以每天做 100 次改变直到公元 4294 年。你应该选择
为你运作良好的表示符号。如果你是一个聪明的 perl 程
式设计者的话那麽你甚至可以使用 RCS 版本编号来帮你
产生你的区域序号。更新指出频率，以秒为单位，次要伺
服器要检查主要伺服器来看看是否需要更新。重试指出要
多久，以秒为单位，次要伺服器重试一次失败的区域移转
之前应该等待的时间。期限是一个上限，以秒为单位，在
次要伺服器因为无法取得更新而死掉之前使用这些资料的
期限。最小限制是区域档案里没有指定存留时间栏位的资
源记录上预设的存留秒数。如果在资源记录中指定存留时
间的话这也是一个强制的最小限制。每个区域应该只有一
个 SOA 记录。
6.5.4. NS - Name Server
{name} {ttl} addr-class NS Name servers name
名称伺服器记录，NS，列出负责所给领域的名称伺服器。
第一个名称栏位列出被列出的名称伺服器所服务的领域。
领域里的每台名称伺服器应该都要有一个 NS 记录，而每
个领域最少要有两个名称伺服器。
6.5.5. A - Address
{name} {ttl} addr-class A address
ucbarpa IN A 128.32.0.4
IN A 10.0.0.78
位址记录，A ，列出所给机器的位址。名称栏位是机器的
名称而位址是网路位址。机器的每个位址应该都要有一个
A 记录。
6.5.6. HINFO - Host Information
{name} {ttl} addr-class HINFO Hardware OS
IN HINFO VAX-11/780 UNIX
主机资讯资源记录，HINFO ，是主机的说明资料。这里列
出硬体以及在所列主机上执行的作业系统。如果你想在机
器名称里使用空白字元的话你必须限制名称。每台主机可
以有一个 HINFO 记录，因为安全上的理由大部分的领域
完全没有任何 HINFO 记录。没有应用程式依靠它们。
6.5.7. WKS - Well Know Services
{name} {ttl} addr-class WKS address protocol list of services
IN WKS 128.32.0.10 UDP who route timed domain
IN WKS 128.32.0.10 TCP ( echo telnet
discard sunrpc sftp
uucp-path systat daytime
netstat qotd nntp
link chargen ftp
auth time whois mtp
pop rje finger smtp
supdup hostnames
domain
nameserver )
知名服务记录，WKS ，描述在一个指定的位址上由特殊的
协定所支援的知名服务。服务及埠号的列表来自在 /etc/
services 里指定服务的列表。每个位址的每个协定应该
只有一个 WKS 记录。注意到 RFC 1123 对 WKS 记录的说
法：
2.2 Using Domain Name Server
...
应用程式不应该倚赖找出包含一个特定主机位址所有
服务正确列表之 WKS 记录的能力，因为该 WKS 资源
记录并不常被网际网路上的站台所使用。要确认某个
服务的存在，简单地尝试去使用它。
...
5.2.12 WKS Use in MX Processing: RFC-974,p.5
...
RFC-974[SMTP:3]建议领域系统可以查询 WKS 知名
服务记录，以便检查每一个推荐的邮递目标确实有
支援 SMTP 。随後经验已经显示 WKS 并没有获得
广泛的支持，所以在 MX 处理程序里的 WKS 步骤
不应该使用。
...
6.1.3.6 Status of RR Types
...
TXT 以及 WKS 资源记录没有被网际网路的站台
广泛采用；因为这个原因，应用程式在大部分的
领域里不能倚赖 TXT 或是 WKS 资源记录的存在
来执行。
6.5.8. CNAME - Canonical Name
aliases {ttl} addr-class CNAME Canonical name
ucbmonet IN CNAME monet
正规名称资源记录，CNAME ，对公定的，或正规的主机名
称指定一个别名或□称。这个记录应该是唯一与别名有关
的一个。其它所有的资源记录应该与正规的名称有关而不
是□称。任何含领域名称作为其值的资源记录（例如 NS
或 MX ）必须列出正规名称，不是□称。
□称在一台主机改变其名称的时候也是有用的。这种
情况下，有个 CNAME 记录通常是个好主意所以仍然使用
旧名称的人将会到达正确的地方。
6.5.9. PTR - Domain Name Pointer
{name} {ttl} addr-class PTR real name
7.0 IN PTR monet.Berkeley.Edu.
领域名称指标记录，PTR ，允许指定名称来指向一些领域
中的其它位置。上面这个 PTR 记录的例子是用来为特殊
的 IN-ADDR.ARPA 领域设定反向指标。这行是从 hosts.
rev □例档案来的。PTR 记录是 gethostbyaddr 函数所
需要的。注意尾巴的 "." 避免 BIND 附加目前的基点。
6.5.10. MX - Mail Exchange
name {ttl} addr-class MX preference value mail exchange
Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV.
*.IL. IN MX 0 RELAY.CS.NET.
邮件交换记录，MX，是用来指定配置成用来接收送往这个
领域名称的邮件的一份主机列表。每个能接收邮件的名称
都应该要有一个 MX 因为如果在递送邮件的时候没有找到
一个的话，一个 MX 将会以优先值为零的方式自行″负责
(imputed)″ 并且以该主机自己为目的地。如果你想要让
一台主机接收它自己的邮件，那麽你应该建立一个 MX 给
你主机的名称，指到你的主机名称。使这个资讯明确比让
它由远端的邮寄者自行负责要来的更好。在第一个□例中
，上面，Seismo.CSS.GOV. 是一个知道要如何递送信件到
Munnari.OZ.AU 的邮递闸道。这两台机器可能有私有网路
连线或是使用不同传送媒介。优先值(preference value)
是在有一个以上的方法递送邮件到单一机器的时候邮寄者
应该遵从的顺序。注意到较低的数字指出较高优先，而且
如果该递送的成本相同的话邮寄者将会随机地选用这些有
相同优先值的邮件交换主机以便分散系统的负载。更详细
的资讯参阅 RFC 974 说明。
通用名称包括字元 "*" 可以用来配合邮件交换记录
执行邮件递送。它们就像是在网路上简单地叙述任何寄往
该领域邮件如何转寄的伺服器。第二个例子，上面，所有
寄往 IL 领域的邮件都通过 RELAY.CS.NET 递送。这个工
作的完成系藉由建立一个通用的资源记录，其叙述 *.IL
有 RELAY.CS.NET 这个邮件交换者。通用邮件交换记录在
实际使用上并不是很有用，虽然如此，因为一旦邮件送到
所给领域的闸道後它仍然必须在该领域里递送而目前为止
不可能在一个领域之内与之外有一个明显不同的邮件交换
记录。如果在你的领域里不需要任何的邮件交换者，继续
前进并且使用通用字元。如果你想要同时在″最高阶层″
使用并且指定″内部的″邮件交换记录的话，注意到每个
指定的记录将必须以与带入最高阶层相同资料的完整重复
来″结束″。这是因为指定邮件交换记录将会引起覆盖最
高阶层通用记录的程序，而如果所给的内部领域要能接收
闸道以外过来的邮件则必须能够履行最高阶层的记录。通
用邮件交换记录是非常微妙的而且你应该小心的使用。
6.5.11. TXT - Text
name {ttl} addr-class TXT string
Munnari.OZ.AU. IN TXT "foo"
一个 TXT 记录包含自由格式(free-form)的本文资料。该
本文的语法依据其存在的领域而定；有很多系统使用 TXT
记录将本地资料编码成特定模式格式。 MIT Hesiod 是这
类系统其中之一。在资料栏位周围的限制(") 是选择性的
但是高度建议。
6.5.12. RP - Responsible Person
owner {ttl) addr_class RP mbox-domain-name TXT-domain-name
franklin IN RP ben.franklin.berkrley.edu. sysadmins.berkeley.edu.
负责人记录，RP，指出一台主机的负责人或是负责群
组的名称。通常会想要能够指出某特定主机的负责实体。
当那台主机当掉或发生故障时，你会想要联络这些可能可
以回复该主机的团体。
第一个栏位，邮箱的领域名称(mbox-domain-name)，
是指定负责人邮箱的领域名称所使用。它在区域档案中的
格式是使用领域名称系统对邮箱的编码惯例，相同於使用
在认可开始(SOA) 记录里面的负责人(Person-in-charge)
栏位。在上面的例子中，邮箱的领域名称显示被编码成为
"<ben@franklin.berkeley.edu>" 。根领域名称（只有一
个 "."）可以用来指定没有邮箱是可用的。
第二个栏位，TXT-domain-name，是由存在的 TXT 记
录所使用的领域名称。随後的(subsequent)查询可以用来
在TXT 领域名称中撷取相关的 TXT 资源记录。在上面的
例子中，"sysadmins.berkeley.edu." 是可以包括一些文
字如名子以及电话号码的 TXT 记录的名称。
负责人记录的格式是不分大小写的。在单一个名称中
多个负责人记录可以出现在资料库里，可是它们应该要有
相同的存留时间(TTLs)。
这个 RP 记录仍然是实验性的；不是所有的名称伺服
器都有实作它或是认得它。
6.5.13. AFSDB - DCE or AFS Server
name {ttl} addr-class AFSDB subtype server host name
toaster.com. IN AFSDB 1 jack.toaster.com.
toaster.com. IN AFSDB 1 jill.toaster.com.
toaster.com. IN AFSDB 2 tracker.toaster.com.
AFDSB 记录是用来指定在这个领域名称下所宣传提供某种
分散式服务的主机。一个副型态值(subtype) （类似邮件
交换记录中的″优先值″）指出所给名称提供何种型式的
分散式服务。副型态 1 指出该名称主机是所给领域名称
里给 AFS cell 使用的 AFS(R) 资料库伺服器。副型态 2
指出该名称伺服器以所给的领域名称提供 intra-cell 名
称服务给 DCE(R) cell named 使用。在上面的例子中，
jack.toaster.com 以及 jill .toaster.com 被宣告成为
给 toaster.com AFS cell 使用的 AFS 资料库伺服器，
所以因此 AFS 客户端所希望从 toaster.com 取得的服务
会被重导到这两台主机以取得进一步的资讯。第三个记录
宣告 tracker.toaster.com 存有 DCE cell toaster.com
的根的目录伺服器，所以希望参考 DCE 服务的 DCE 客户
端应该联络 tracker.toaster.com 该主机以取得进一步
的资讯。DCE 副型态记录通常伴随一个用来指定其它被用
来存取 DCE cell 其它细节资讯的 TXTP 记录。RFC 1183
包含有使用这个记录型态更多的细节资讯。
这个 AFSDB 记录仍然是实验性的； 不是所有的名称
伺服器都有实作它或是认得它。
6.6. 关於存留时间的讨论
经由在 SOA 记录中的 Minimum 栏位指定给记录以及区域的
存留时间非常重要。高的数值将会导致较低的 BIND 网路流量以
及较快的回应时间。较低的数值将会趋向产生很多要求但是将会
允许较快地广播改变。
只有改变以及从该领域删除才会被 TTLs 影响。新增的广播
则根据 SOA 里的更新值。
经验显示各站对他们区域所使用的预设 TTLs 从 0.5 到 7
天左右。你也许想要考虑提高预设的 TTL 值到这份指引中先前
前版本中所说从一天(86400秒)到三天(23900秒)。这会激烈地减
少对你名称伺服器进行要求的数目。
如果你需要快速地的广播改变跟删除，在改变的几天前减少
Minimun 栏位可能是聪明的，然後执行修改本身并接著增加 TTL
到它原先的值。
如果你知道你的区域是颇为稳定的（你主要是增加新记录而
没有规律地改变旧的）那麽你甚至可能希望考虑比三天还要高的
TTL 值。
注意到在任何情况下，使记录的 TTL 低於 SOA 更新延迟是
没有意义的，因延迟是要求次要伺服器去取得一份新修改的区域
拷贝的时间。
6.7. □例档案
下列章节包含给名称伺服器使用的□例档案。这涵盖不同型
态伺服器的启动档以及领域资料库档案的□例。
6.7.1. Boot Files
6.7.1.1. Primary Server
;
; Boot file for Primary Name Server
;
; type domain source file or host
;
directory /usr/local/adm/named
primary Berkeley.Edu ucbhosts
primary 32.128.in-addr.arpa ucbhosts.rev
primary 0.0.127.in-addr.arpa named.local
cache . root.cache
6.7.1.2. Secondary Server
;
; Boot file for Secondary Name Server
;
; type domain source file or host
;
directory /usr/local/adm/named
secondary Berkeley.Edu 128.32.0.4 128.32.0.10 ucbhosts.bak
secondary 32.128.in-addr.arpa 128.32.0.4 128.32.0.10 ucbhosts.rev.bak
primary 0.0.127.in-addr.arpa named.local
cache . root.cache
6.7.1.3. Caching Only Server
;
; Boot file for Caching Only Name Server
;
; type domain source file or host
;
directory /usr/local/adm/named
cache . root.cache
primary 0.0.127.in-addr.arpa named.local
6.7.2. Remote Server / DNS Client
6.7.2.1. /etc/resolv.conf
domain Berkeley.Edu
nameserver 128.32.0.4
nameserver 128.32.0.10
sortlist 130.155.160.0/255.255.240.0 130.155.0.0
6.7.3. root.cache
;
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: May 11, 1994
; related version of root zone: 940516
;
. 99999999 IN NS NS.INTERNIC.NET.
NS.INTERNIC.NET. 99999999 IN A 198.41.0.4
. 99999999 IN NS NS1.ISI.EDU.
NS1.ISI.EDU. 99999999 IN A 128.9.0.107
. 99999999 IN NS C.NYSER.NET.
C.NYSER.NET. 99999999 IN A 192.33.4.12
. 99999999 IN NS TERP.UMD.EDU.
TERP.UMD.EDU. 99999999 IN A 128.8.10.90
. 99999999 IN NS NS.NASA.GOV.
NS.NASA.GOV. 99999999 IN A 128.102.16.10
99999999 IN A 192.52.195.10
. 99999999 IN NS NS.NIC.DDN.MIL.
NS.NIC.DDN.MIL. 99999999 IN A 192.112.36.4
. 99999999 IN NS AOS.ARL.ARMY.MIL.
AOS.ARL.ARMY.MIL. 99999999 IN A 128.63.4.82
99999999 IN A 192.5.25.82
. 99999999 IN NS NIC.NORDU.NET.
NIC.NORDU.NET. 99999999 IN A 192.36.148.17
; End of File
6.7.4. named.local
@ IN SOA ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. (
1994072100 ; Serial
10800 ; Refresh
1800 ; Retry
3600000 ; Expire
259200 ) ; Minimum
IN NS ucbvax.Berkeley.Edu. ; pedantic
1 IN PTR localhost.
6.7.5. host.rev
;
; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05
;
@ IN SOA ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. (
1986020501 ; Serial
10800 ; Refresh
1800 ; Retry
3600000 ; Expire
259200 ) ; Minimum
IN NS ucbarpa.Berkeley.Edu.
IN NS ucbvax.Berkeley.Edu.
0.0 IN PTR Berkeley-net.Berkeley.EDU.
IN A 255.255.255.0
0.130 IN PTR csdiv-net.Berkeley.EDU.
4.0 IN PTR ucbarpa.Berkeley.Edu.
6.0 IN PTR ernie.Berkeley.Edu.
7.0 IN PTR monet.Berkeley.Edu.
10.0 IN PTR ucbvax.Berkeley.Edu.
6.130 IN PTR monet.Berkeley.Edu.
6.7.6. Hosts
;
; @(#)ucb-hosts 1.2 (berkeley) 88/02/05
;
@ IN SOA ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. (
1988020501 ; Serial
10800 ; Refresh
1800 ; Retry
3600000 ; Expire
259200 ) ; Minimum
IN NS ucbarpa.Berkeley.Edu.
IN NS ucbvax.Berkeley.Edu.
localhost IN A 127.1
; note that 127.1 is the same as 127.0.0.1; see inet(3n)
ucbarpa IN A 128.32.4
IN A 10.0.0.78
IN HINFO VAX-11/780 UNIX
arpa IN CNAME ucbarpa
ernie IN A 128.32.6
IN HINFO VAX-11/780 UNIX
ucbernie IN CNAME ernie
monet IN A 128.32.7
IN A 128.32.130.6
IN HINFO VAX-11/750 UNIX
ucbmonet IN CNAME monet
ucbvax IN A 10.2.0.78
; 128.32.10 means 128.32.0.10; see inet(3n)
IN A 128.32.10
; HINFO and WKS are widely unused,
; but we'll show them as examples.
IN HINFO VAX-11/750 UNIX
IN WKS 128.32.0.10 TCP ( echo telnet
discard sunrpc sftp
uucp-path systat daytime
netstat qotd nntp
link chargen ftp
auth time whhois mtp
pop rje finger smtp
supdup hostnames
domain
nameserver )
vax IN CNAME ucbvax
toybox IN A 128.32.131.119
IN HINFO Pro350 RT11
toybox IN MX 0 monet.Berkeley.Edu.
csrg IN MX 0 Ralph.CS
IN MX 0 Zhou.CS
IN MX 0 Painter.CS
IN MX 0 Riggle.CS
IN MX 0 Terry.CS
IN MX 0 Kevin.CS
7. 领域管理
这一节包含开始、控制以及除错的资讯。
7.1. /etc/rc.local
主机名称应该使用 hostname(1) 设为完整的领域形式名称
。下列的项目应该要加到 /etc/rc.local 以便在启动的时候即
开始启动 named 伺服器。
if [ -f/etc/named ]; then
/etc/named [option] & echo -n ' named' >/dev/console
fi
这通常直接跟在开始 syslogd 该行下面。不要尝试从 inetd 去
执行 named。这将会连续地重新启动该名称伺服器并且摧毁暂存
的功用。
7.2. /etc/named.pid
当 named 成功地启动时它会将其程序识别码(process ID)
写入 /etc/named.pid 这个档案。这对於想要传送信号给 named
的程式很有用。这个档案的名称可以在编译 named 的时候定义
给 PIDFILE 一个新的名称加以改变。
7.3. /etc/hosts
该 gethostbyname 程式库呼叫可以查出 named 是否正在执
行。如果它判断 named 并没有执行它将会查阅 /etc/hosts 来
解析位址。这个选项的加入用来允许 ifconfig(8C) 配置机器的
本地位址以及使系统管理人员在系统处於单人模式下时能够存取
网路。将本地机器的界面位址以及另外一些机器的名称与位址放
进 /etc/hosts 里是值得建议的所以系统管理人员在系统处於单
人模式下的时候可以从另外一台机器 rcp 档案。该 /etc/hosts
的格式没有改变。参阅 hosts(5) 以便获得更多资讯。因为读取
/etc/hosts 的速度很慢，当系统处於多人模式的时候不建议该
选项的使用。
7.4. 信号(Signals)
有数个信号可以送进 named 程序中使它不必重新启动该程
序即可执行作业。
7.4.1. Reload
SIGHUP － 引发 named 读取 named.boot 并且重新
载入资料库。当你改变″主要″资料档案之後而且你希望
named 的内部资料库反应该项改变时这会有用。如果你使
用 FORCED_RELOAD 选项来建立 BIND 的话，那麽 SIGHUP
对於所有″次要″区域序号检查的排程(scheduleing) 也
有效果，这可以导致区域移转比正常排程更早发生。一般
序号比较只有在区域的认可记录中指定的间隔时间来临时
才会执行。
7.4.2. Debugging
当 named 执行不正常时，首先查看 /var/log/mess-
ages 并且检查任何由 syslog 记录的讯息。下一步是送
一个信号给它看看到底发生什麽事。除非你使用 -d 选项
执行它，named 在标准输出设备或是标准错误设备上说的
很少。每一件 named 必须说的它都告诉 syslog 。
SIGINT － 倾印目前的资料库及暂存区到 /var/tmp/
named_dump.db 里去。这将会给你一些对於资料库是否有
正确地载入的指引。这个档案名称可以在编译 named 的
时候定义给 DUMPFILE 一个新的名称加以改变。
注意：下列的两个信号只有在 named 配合 DEBUG 的定义
编译时才能运作。
SIGUSR1 － 打开除错。其後的每个 USR1 递增除错
阶层。输出放进 /var/tmp/named.run 中。这个档案名称
可以在编译 named 的时候定义给 DEBUGFILE 一个新的
名称加以改变。
SIGUSR2 － 完全关闭除错。
要取得更多除错细节，将解答器函式编译到 /lib/libc.a
的时候定义 DEBUG。
SIGWINCH － 如果 named 配合 QRYLOG 的定义编译
这会套上对所有进入查询的追踪。追踪结果送往 syslog
，而且是无限制的，但是它对於追踪问题非常有用。
要加上对所有查询的追踪来执行在指令行上指定 -q 旗标
。如果你规律地记录查询那麽你也许希望使用在 contrib
目录下的 dnsstats 状态指令稿来分析这些结果。
ACKNOWLEDGEMENTS -- 4.9.3
The <bind-workers@vix.com> mailing list was once again
of great help; this release would not be nearly as ready for
prime time if not for their efforts. Special commendations
are owed to Robert Elz, Don "Truck" Lewis, Bob Heiney, Mark
Andrews, Berthold Paffrath, Ruediger Volk, and Peter Koch.
Digital Equipment Corporation, Hewlett Packard, Silicon
Graphics, and SunSoft all made hardware available for inte-
gration testing; this made the release far more solid than
it would otherwise have been. More hardware loans are wel-
come -- if you are a system vendor and you would like BIND
to run ``out of the box'' on your platform and are willing
to lend some rusty old hardware for the purpose, please con-
tact me (<paul@vix.com>) to make the arrangements.
Special thanks to the Internet Software Consortium for
funding this work. (Contact <isc-info@isc.org> if your
organization would like to participate in funding future
releases.)
ACKNOWLEDGEMENTS -- through 4.9
The alpha-test group was extremely helpful in furnish-
ing improvements, finding and repairing bugs, and being
patient. I would like to express special thanks to Brian
Reid of Digital Equipment corporation for funding this work.
Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew
Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath,
Fuat Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis,
Christophe Wolfhugel, and a cast of dozens all helped out
above and beyond the call of duty. Special thanks to Phil
Almquist, who got the project started and contributed a lot
of the code and fixed several of the worst bugs.
ACKNOWLEDGEMENTS -- through 4.8.3
Many thanks to the users at U.C. Berkeley for falling
into many of the holes involved with integrating BIND into
the system so that others would be spared the trauma. I
would also like to extend gratitude to Jim McGinness and
Digital Equipment Corporation for permitting me to spend
most of my time on this project.
Ralph Campbell, Doug Kingston, Craig Partridge, Smoot
Carl-Mitchell, Mike Muuss and everyone else on the DARPA
Internet who has contributed to the development of BIND. To
the members of the original BIND project, Douglas Terry,
Mark Painter, David Riggle and Songnian Zhou.
Anne Hughes, Jim Bloom and Kirk McKusick and the many
others who have reviewed this paper giving considerable
advice.
This work was sponsored by the Defense Advanced
Research Projects Agency (DoD), Arpa Order No. 4871 moni-
tored by the Naval Electronics Systems Command under con-
tract No. N00039-84-C-0089. The views and conclusions con-
tained in this document are those of the authors and should
not be interpreted as representing official policies, either
expressed or implied, of the Defense Research Projects
Agency, of the US Government, or of Digital Equipment Corpo-
ration.
REFERENCES
[Birrell] Birrell, A. D., Levin, R., Needham, R. M., and
Schroeder, M.D., "Grapevine: An Exercise in Dis-
tributed Computing." In Comm. A.C.M. 25,
4:260-274 April 1982.
[RFC819] Su, Z. Postel, J., "The Domain Naming Convention
for Internet User Applications." Internet Request
For Comment 819 Network Information Center, SRI
International, Menlo Park, California. August
1982.
[RFC974] Partridge, C., "Mail Routing and The Domain Sys-
tem." Internet Request For Comment 974 Network
Information Center, SRI International, Menlo Park,
California. February 1986.
[RFC1032] Stahl, M., "Domain Administrators Guide" Internet
Request For Comment 1032 Network Information Cen-
ter, SRI International, Menlo Park, California.
November 1987.
[RFC1033] Lottor, M., "Domain Administrators Guide" Internet
Request For Comment 1033 Network Information Cen-
ter, SRI International, Menlo Park, California.
November 1987.
[RFC1034] Mockapetris, P., "Domain Names - Concept and
Facilities." Internet Request For Comment 1034
Network Information Center, SRI International,
Menlo Park, California. November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation
and Specification." Internet Request For Comment
1035 Network Information Center, SRI Interna-
tional, Menlo Park, California. November 1987.
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names
and Other Types." Internet Request For Comment
1101 Network Information Center, SRI Interna-
tional, Menlo Park, California. April 1989.
[RFC1123] R. Braden, Editor, "Requirements for Internet
Hosts -- Application and Support" Internet Request
For Comment 1123 Network Information Center, SRI
International, Menlo Park, California. October
1989.
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and Mock-
apetris, P., "New DNS RR Definitions" Internet
Request For Comment 1183 Network Information
Center, SRI International, Menlo Park, California.
October 1990.
[Terry] Terry, D. B., Painter, M., Riggle, D. W., and
Zhou, S., The Berkeley Internet Name Domain
Server. Proceedings USENIX Summer Conference,
Salt Lake City, Utah. June 1984, pages 23-31.
[Zhou] Zhou, S., The Design and Implementation of the
Berkeley Internet Name Domain (BIND) Servers.
UCB/CSD 84/177. University of California, Berke-
ley, Computer Science Division. May 1984.
[Mockapetris]
Mockapetris, P., Dunlap, K, Development of the
Domain Name System ACM Computer Communications
Review 18, 4:123-133. Proceedings ACM SIGCOMM '88
Symposium, August 1988.
[Liu] Liu, C., Albitz, P., DNS and BIND O'Reilly & Asso-
ciates, Sebastopol, CA, 502 pages, ISBN
0-937175-82-X 1992
BBS水木清华站∶精华区