第三章:配置和区域文件

第三章:配置和区域文件3.1. 介绍3.1.1. named.conf 基本文件3.1.2. example.com 基本区域文件3.1.3. 其他 Zone 文件3.1.4. localhost Zone 文件3.1.5. localhost 反向映射 Zone 文件3.2. 权威名称服务器3.2.1. 主要权威名称服务器3.2.2. 二级权威名称服务器3.3. 解析器(缓存名称服务器)3.3.1. 其他区域文件3.3.1.1. 根服务器(Hint)区域文件3.3.1.2. 私有IP反向映射区域文件3.3.2. 解析器配置3.3.3. 转发解析器配置3.3.4. 选择性转发解析器配置3.4. 负载平衡3.5. Zone File3.5.1. 资源记录3.5.1.1. RRs的文本表达3.5.2. MX记录的探讨3.5.3. 设置 TTLs3.5.4. IPv4中的反向映射3.5.5. 其他区域文件指令3.5.5.1. @ 符号3.5.5.2. $ORIGIN 指令3.5.5.3. $INCLUDE 指令3.5.5.4. $TTL 指令3.5.6. BIND主文件扩展名:$GENERATE指令3.5.7. 附加文件格式

3.1. 介绍

BIND 9使用一个名为 named.conf 的配置文件,该文件通常位于 /etc/namedb/usr/local/etc/namedb 中。

注: 如果 rndc 在本地使用(与BIND 9在同一主机上),则可能存在额外的文件 rndc.conf ,尽管 rndc 在没有此文件的情况下运行。如果 rndc 是从远程主机运行的,则必须存在 rndc.conf 文件,因为它定义了链接特性和属性。

根据系统的功能,需要一个或多个区域文件。

本章和后续章节中给出的示例对 named.confexample.com 的区域文件都使用了标准的基本格式。目的是让读者看到随着功能的添加或删除,从一个共同的基础开始的演变。

3.1.1. named.conf 基本文件

此文件说明了 named.conf 使用的典型格式和布局样式,并提供了一个基本的日志服务,可以根据用户的需要进行扩展:

loggingoptions 块以及 category (类别)、channel (通道)、directory (目录)、file (文件)和 severity (严重性)语句都将在本ARM的相应章节中进一步描述。

3.1.2. example.com 基本区域文件

以下是 example.com 域的完整区域文件,其中说明了许多常见功能。文件中的注释在适当的情况下解释了这些功能。区域文件由描述区域特征或属性的 Resource Records (RR —— 资源记录)组成。

这种类型的区域文件通常被称为 forward-mapped zone file (正向映射区域文件),因为它将域名映射到其他值,而 reverse-mapped zone file (反向映射区域文件)将IP地址映射到域名。区域文件被称为 example.com ,除了它是它所描述的区域的域名之外,没有任何理由;与往常一样,用户可以自由使用任何适合他们需求的文件命名约定。

3.1.3. 其他 Zone 文件

根据配置,可能或应该存在其他区域文件。这里简要介绍了它们的格式和功能。

3.1.4. localhost Zone 文件

所有最终用户系统都附带了 hosts 文件(通常位于 /etc 中)。此文件通常配置为将名称 localhost (应用程序在本地运行时使用的名称)映射到环回地址。有人合理地认为,因此并不严格要求为 localhost 提供正向映射区域文件。本手册确实在所有配置示例中使用BIND 9分发文件 localhost-forward.db (通常在 /etc/namedb/master/usr/local/etc/namedb/master 中),原因如下:

  1. 许多用户出于安全原因选择删除 hosts 文件(它是严重域名重定向/中毒攻击的潜在目标)。
  2. 系统通常首先使用 hosts 文件(如果存在)查找任何名称(包括域名),然后使用DNS。但是,nsswitch.conf 文件(通常在 /etc 中)控制此顺序(通常为hosts: file dns),允许根据本地需要更改顺序或完全删除file值。除非BIND管理员控制此文件并知道其值,否则假设localhost已正确前向映射是不安全的。
  3. 提醒用户,对localhost的不必要查询在公共网络上形成了大量的DNS查询,这会影响所有用户的DNS性能。

但是,用户可以自行选择不实施此文件,因为根据操作环境的不同,它可能不是必需的。

为了完整起见,显示了BIND 9分发文件 localhost-forward.db 格式,并提供了IPv4和IPv6本地主机解析。区域(域)名称是 localhost

注: 一定年龄或性格的读者可能会注意到本文件中提到的已故的,令人悼念的道格拉斯·诺埃尔·亚当斯。

3.1.5. localhost 反向映射 Zone 文件

此区域文件允许任何请求与环回IP(127.0.0.1)关联的名称的查询。需要此文件来防止不必要的查询到达公共DNS层次结构。为了完整起见,显示了BIND 9分发文件 localhost.rev

3.2. 权威名称服务器

这些为用户查询其支持的区域提供权威答案:例如,描述域名 example.com 的区域数据。权威名称服务器可能支持一个或多个区域。

每个区域可以被定义为 primary 区域或 secondary 区域。主区域直接从文件系统读取其区域数据。辅助区域使用称为 zone transfer (区域传输)的过程从主区域获取其区域数据。主要和次要区域都为其区域提供权威数据;主区域或次区域的查询答案没有区别。权威名称服务器可以支持主区域和辅助区域的任何组合。

注: 术语 primarysecondary 并不意味着任何访问优先级。解析程序(为用户查询提供完整答案的名称服务器)不知道(也无法发现)权威答案是来自主名称服务器还是辅助名称服务器。相反,解析器使用该区域的权威服务器列表(必须至少有两个),并为列表中的每个服务器维护往返时间(Round Trip Time——RTT),即响应查询所需的时间。解析器使用最低值服务器(最快)作为其区域的首选服务器,并继续这样做,直到其RTT变得高于其列表中下一个最慢的服务器,此时该服务器成为首选服务器。 出于向后兼容性的原因,BIND 9将 “primary” 和 “master” 视为同义词,以及 “secondary” 和 “slave” 。

下图显示了主名称服务器和辅助名称服务器之间的关系。下文详细解释了这一过程。

primary-secondary.webp

Authoritative Primary and Secondary Name Servers

以下文本中括号内的数字是指上图中的编号项目:

  1. 权威的主名称服务器总是从(1)本地或网络文件存储中加载(或重新加载)其区域文件。

  2. 权威的辅助名称服务器总是通过 zone transfer (区域传输)操作从主服务器加载其区域数据。区域转移可以使用 AXFR (完整区域转移)或 IXFR (增量区域转移),但前提是主名称服务器和辅助名称服务器都支持该服务。区域转移过程(AXFR或IXFR)的工作原理如下:

    1. 区域的辅助名称服务器读取(3和4)SOA RR定期。间隔由授权开始(SOA)RR的refresh (刷新)参数定义。
    2. 次级将从初级接收到的SOA RR的 serial number (序列号)参数与其当前区域数据的SOA RR中的序列号进行比较。
    3. 如果接收到的序列号在算术上大于(高于)当前序列号,则次端使用AXFR或IXFR(取决于主端和次端配置)通过端口53上的TCP发起区域传输(5)(6)。
  3. SOA RR的典型推荐区域刷新时间(辅助读取或轮询区域SOA RR的主区域的时间间隔)是小时的倍数,以减少流量负载。因此,最坏情况下的区域变化传播可能需要很长时间。

  4. 可选的 NOTIFY(RFC 1996)特征(2)是自动配置的;使用 notify 语句以关闭该功能。每当主服务器加载或重新加载一个区域时,它都会向配置的辅助服务器(或多个辅助服务器)发送一条NOTIFY消息,并且可以选择性地配置为使用 also-notify 向其他主机发送NOTIFY信息声明还通知声明。NOTIFY消息只是向辅助服务器指示主服务器已加载或重新加载该区域。在接收到NOTIFY消息后,次要响应表示它已收到NOTIFY,并立即从主要响应读取SOA RR(如上文第2a节所述)。如果区域文件已更改,传播几乎是即时的。

权威示例都使用NOTIFY,但会标识所使用的语句,以便在不需要时可以将其删除。

3.2.1. 主要权威名称服务器

基本示例中的区域文件未被修改,但 named.conf 文件已被修改,如下所示:

添加的语句和块在上面的文件中进行了注释。

在相应的章节中详细描述了 zone 块、allow-query (允许查询)、allow-query-cache (允许查询缓存)、allow-transfer (允许传输)、file (文件)、notify (通知)、recursion (递归)和 type (类型)语句。

3.2.2. 二级权威名称服务器

区域文件 local-host-forward.dblocalhost.rev 与基本示例相比没有修改。example.com 区域文件不是必需的(区域文件是通过区域传输从主服务器获取的)。 named.conf 文件已被修改,如下所示:

添加的语句和块都在上面的文件中进行了注释。

在相应的章节中详细描述了 zone 块、allow-query (允许查询)、allow-query-cache (允许查询缓存)、allow-transfer (允许传输)、file (文件)、notify (通知)、recursion (递归)和 type (类型)语句。

如果不使用NOTIFY,则不需要对此 named.conf 文件进行任何更改,因为它是发起NOTIFY消息的主文件。

注: 当读者认为他们理解了主要和次要内容时,事情就会变得更加复杂。辅助区域也可以是其他辅助区域的主区域:默认情况下,named 会为它加载的每个区域发送NOTIFY消息。指定 notify primary-only ;在名为“仅为其加载的主要区域发送NOTIFY消息”的次要原因的区域块中。

3.3. 解析器(缓存名称服务器)

解析器(resolvers)处理递归用户查询(recursive user queries)并提供完整答案;也就是说,它们向DNS层次结构发出一个或多个迭代查询(iterative queries)。在获得完整答案(或错误)后,解析器将答案传递给用户并将其放入缓存中。后续用户对同一查询的请求将从解析器的缓存中得到答复,直到缓存答案的TTL到期,然后将从缓存中刷新;请求相同信息的下一个用户查询会导致对DNS层次结构的一系列新查询。

解析器经常被称为各种令人困惑的名称,包括缓存名称服务器(caching name servers)、递归名称服务器(recursive name servers)、转发解析器(forwarding resolvers)、区域解析器(area resolvers)和全方位服务解析器(full-service resolvers)。

下图显示了解析器如何在典型的网络环境中运行:

resolver-forward.webp

Resolver and Forwarding Resolver

  1. 最终用户系统都以本地 stub resolver (存根解析器)作为标准功能进行分发。如今,大多数存根解析器还提供本地缓存服务,以加快用户响应时间。

  2. 存根解析器的功能有限;具体来说,它不能跟踪推荐(referrals)。当存根解析器从本地程序(如浏览器)接收到对名称的请求,并且答案不在其本地缓存中时,它会向本地配置的解析器(5)发送递归用户查询(recursive user query)(1),该解析器的缓存中可能有可用的答案。如果没有,它会向DNS层次结构发出迭代查询(iterative queries)(2)以获得答案。对于Linux和Unix主机,本地系统向其发送用户查询的解析器配置在/etc/resolv.conf 中;对于Windows用户,可以通过“控制面板”或“设置”界面进行配置或更改。

  3. 或者,用户查询可以被发送到 forwarding resolver (转发解析器)(4)。乍一看,转发解析器似乎毫无意义,因为它们似乎只是一个简单的传递,而且与存根解析器一样,需要一个全方位服务的解析器(5)。然而,转发解析器可能是网络中非常强大的补充,原因如下:

    1. 成本和性能。转发解析器(4)上的每个 recursive user query (递归用户查询)(1)都会产生两条消息——查询及其答案。解析器(5)可能必须发出三个、四个或更多个查询对(2)才能获得所需的答案。流量大幅减少,提高了性能或降低了成本(如果链路被关税化)。此外,由于转发解析器通常在多个主机之间共享,其缓存更有可能包含答案,从而再次提高了用户性能。
    2. 网络维护。转发解析器(4)可用于减轻本地管理的负担,它提供了一个可以管理远程名称服务器更改的单一点,而不必更新所有主机。因此,特定网络部分或区域中的所有主机都可以配置为指向转发解析器,该解析器可以配置为根据需要流式传输DNS流量,并随着时间的推移以最小的努力进行更改。
    3. 对交通进行消毒。特别是在较大的专用网络中,使用转发解析器结构流式传输DNS流量可能是明智的。例如,转发解析器(4)可以被配置为处理所有域内流量(相对安全),并将所有外部流量转发给 hardened (强化)解析器(5)。
    4. 隐形网络。转发解析器广泛应用于隐形或分裂网络。
  4. 转发解析器(4)可以被配置为将所有流量转发到解析器(5),或者仅转发选择性流量(5)而直接解析其他流量(3)。

注意: 虽然上图显示了通过接口(1)到达的递归用户查询,但没有什么可以阻止它们通过公共网络通过接口(2)到达。如果对可以发送此类查询的源IP没有限制,则解析器称为开放解析器。事实上,当世界还年轻的时候,互联网就是这样运作的。许多事情已经发生了变化,看似友好、慷慨的行为可能被流氓行为者用来制造各种问题,包括拒绝服务(Denial of Service —— DoS)攻击。解析程序应始终配置为限制可以使用其服务的IP地址。BIND 9提供了许多语句和块,以简化定义这些IP限制和配置封闭解析器(closed resolver)。这里给出的解析器示例都使用各种技术配置了封闭解析器。

3.3.1. 其他区域文件

3.3.1.1. 根服务器(Hint)区域文件

解析程序(尽管不一定是转发解析程序)需要访问DNS层次结构。为此,他们需要知道13个 root servers 的地址(IPv4和/或IPv6)。这是通过提供一个根服务器区域文件来实现的,该文件包含在标准BIND 9发行版中,名为 named.root (通常位于 /etc/namedb/usr/local/namedb 中)。此文件也可从IANA网站获得(https://www.iana.org/domains/root/files).

注: 许多发行版出于历史原因重命名此文件。有关实际文件名,请参阅相应的分发文档。

提示(hint)区域文件使用 type hint 语句和区域(域)名称“.”(通常为无声点)引用。

注: 根服务器IP地址多年来一直保持稳定,并可能在不久的将来保持稳定。BIND 9在其可执行文件中有一个根服务器列表,这样即使省略了此文件,过期或损坏的BIND 9仍然可以运行。因此,许多示例配置省略了提示文件。这里给出的所有示例都包括提示文件,主要是为了提醒配置的功能,而不是绝对必要的。

3.3.1.2. 私有IP反向映射区域文件

解析程序被配置为当请求的信息不在其缓存中或未在任何本地区域文件中定义时,向公共DNS层次结构发送迭代查询(iterative queries)。许多网络广泛使用私有IP地址(由RFC 1918RFC 2193RFC 5737RFC 6598定义)。从本质上讲,这些IP地址在各种用户区域文件中进行了前向映射。但是,某些应用程序可能会发出 reverse map (反向映射)查询(将IP地址映射到名称)。如果一个或多个反向映射区域文件中没有定义私有IP地址,解析器会将它们发送到DNS层次结构,在那里它们只是无用的流量,从而减缓所有用户的DNS响应。

私有IP地址可以使用标准反向映射技术或使用 empty-zones-enable (空区域启用)语句来定义。默认情况下,此语句设置为 empty-zones-enable yes; 因此通过向任何请求发送NXDOMAIN错误响应(指示名称不存在)来自动防止不必要的DNS流量。然而,一些应用程序可能需要对这种反向映射请求的真实答案,否则它们将无法运行。邮件系统特别执行反向DNS查询作为一线垃圾邮件检查;在这种情况下,反向映射的区域文件是必不可少的。这里为解析器和转发解析器提供的示例配置文件为私有IP地址192.168.254.4提供了一个反向映射区域文件,该地址是基区域文件中的邮件服务器地址,作为反向映射技术的说明。该文件名为 192.168.254.rev ,区域名称为 254.168.192.in-addr.arpa

3.3.2. 解析器配置

解析器为一组定义的IP地址提供递归查询支持。因此,它是一个封闭的( closed )解析器,不能用于更广泛的网络攻击。

zoneacl 块,以及 allow-queryempty-zones-enablesfilenotifyrecursiontype 语句在相应章节中有详细描述。

提醒一下,对于以下递归查询,此解析器的配置不会访问DNS层次结构(不使用公共网络):

  1. 答案已在缓存中。
  2. 域名是localhost(区域localhost)。
  3. 是127.0.0.1(地址arpa中的区域0.0.127.)的反向映射查询。
  4. 是192.168.254/24(地址arpa中的区域254.168.192.)的反向映射查询。
  5. 是对任何本地IP的反向映射查询(empty-zones-enable语句)。

所有其他递归查询都将导致访问DNS层次结构以解析查询。

3.3.3. 转发解析器配置

此转发解析器配置将所有递归查询转发到IP地址192.168.250.3处的全服务解析器,而不是已定义区域的查询和其缓存中已有答案的查询,另一个地址为192.168.230.27。转发解析器将缓存来自这些服务器的所有响应。配置是关闭的,因为它定义了接受递归查询的IP地址。

还提供了其中发生选择性转发的第二配置。

在相应的章节中详细描述了 zoneacl 块,以及 allow-queryempty-zones-enablefileforwardforwardersnotifyrecursiontype 语句。

提醒一下,此转发解析器的配置 不会 转发任何递归查询,因为:

  1. 答案已在缓存中。
  2. 域名是 localhost(zone localhost)。
  3. 是127.0.0.1(地址arpa中的区域0.0.127.)的反向映射查询。
  4. 是192.168.254/24(地址arpa中的区域254.168.192.)的反向映射查询。
  5. 是针对任何本地IP的反向映射查询 (empty-zones-enable 语句)。

所有其他递归查询都将被转发以解析该查询。

3.3.4. 选择性转发解析器配置

此转发解析器配置仅将区域 example.com 的递归查询转发到192.168.250.3和192.168.230.27的解析器。除已定义区域的查询和答案已在其缓存中的查询外,所有其他递归查询都由此解析器处理。转发解析器将缓存来自公共网络和转发解析器的所有响应。配置是关闭的,因为它定义了接受递归查询的IP地址。

在相应的章节中详细描述了 zoneacl 块,以及 allow-queryempty-zones-enablefileforwardforwardersnotifyrecursiontype 语句。

提醒一下,对于以下递归查询,此解析器的配置不会访问DNS层次结构(不使用公共网络):

  1. 答案已在缓存中。
  2. 域名是 localhost(zone localhost)。
  3. 是127.0.0.1(地址arpa中的区域0.0.127.)的反向映射查询。
  4. 是192.168.254/24(地址arpa中的区域254.168.192.)的反向映射查询。
  5. 是针对任何本地IP的反向映射查询 (empty-zones-enable 语句)。
  6. 是对域名 example.com 的查询,在这种情况下,它将被转发到192.168.250.3或192.168.230.27(zone example.com)。

所有其他递归查询都将导致访问DNS层次结构以解析查询。

3.4. 负载平衡

通过在一个区域文件中为一个名称使用多个资源记录(resource records —— RR)(如多个A记录),可以在DNS中实现负载平衡的原始形式。

例如,假设有三台网络地址为10.0.0.1、10.0.0.2和10.0.0.3的HTTP服务器,一组如下的记录意味着客户端将有三分之一的时间连接到每台机器:

NameTTLCLASSTYPEResource Record (RR) Data
www600INA10.0.0.1
 600INA10.0.0.2
 600INA10.0.0.3

当解析器查询这些记录时,BIND会对其进行旋转,并以随机顺序用记录响应查询。在上述示例中,客户端随机接收顺序为1、2、3的记录;2, 3, 1; 以及3、1、2。大多数客户端使用返回的第一条记录并丢弃其余记录。

有关排序响应的更多详细信息,请参阅 options 块中的 rrset-order 语句。

3.5. Zone File

本节主要借鉴了RFC 1034,描述了资源记录(Resource Record —— RR)的概念,并解释了如何使用它们。

3.5.1. 资源记录

域名标识DNS树命名空间中的节点。每个节点都有一组资源信息,这些信息可能是空的。与特定名称关联的资源信息集由单独的RR组成。RR在集合中的顺序并不重要,不需要由名称服务器、解析器或DNS的其他部分保留。但是,出于优化目的,允许对多个RR进行排序:例如,指定首先尝试特定的附近服务器。请参阅RRset Ordering。

资源记录的组成部分包括:

以下 classes 的资源记录当前在DNS中有效:

所有者名称(owner name)通常是隐式的,而不是RR的组成部分。例如,许多名称服务器在内部为名称空间形成树或哈希结构,并将RR链离节点(chain RRs off nodes)。其余的RR部分是固定标头(类型、类、TTL),它对所有RR都是一致的,以及一个符合所描述资源需求的可变部分(RDATA)。

TTL字段是RR在缓存中可以保留多长时间的时间限制。这一限制不适用于区域内的权威数据;这也过时了,但遵循了该地区令人耳目一新的政策。TTL由管理员为数据来源的区域分配。虽然短TTL可用于最大限度地减少缓存,零TTL禁止缓存,但互联网性能的现实表明,对于典型的主机来说,这些时间应该在几天左右。如果预期会发生变化,可以在更改之前减小TTL以尽量减少不一致性,然后在更改后将其增加回原来的值。

RR的RDATA部分中的数据以二进制字符串和域名的组合形式携带。域名经常被用作DNS中其他数据的“指针”。

3.5.1.1. RRs的文本表达

RR在DNS协议的数据包中以二进制形式表示,当存储在名称服务器或解析器中时,通常以高度编码的形式表示。在RFC 1034中提供的示例中,采用了与主文件中使用的样式类似的样式来显示RR的内容。在这种格式中,大多数RR都显示在一行上,尽管可以使用括号继续显示。

行的开头给出了RR的所有者。如果一行以空白开头,则假设所有者与前一个RR的所有者相同。为了可读性,通常会包含空白行。

在所有者之后列出了RR的TTL、类型和类。类和类型使用上面定义的助记符,TTL是类型字段之前的整数。为了避免解析中的歧义,类型和类助记符是不相交的,TTL是整数,类型助记符总是最后一个。为了清楚起见,示例中经常省略IN类和TTL值。

RR的资源数据或RDATA部分是使用数据的典型表示知识给出的。

例如,消息中携带的RR可能显示为:

ISI.EDU.MX10 VENERA.ISI.EDU.
 MX10 VAXA.ISI.EDU
VENERA.ISI.EDUA128.9.0.32
 A10.1.0.52
VAXA.ISI.EDUA10.2.0.27
 A128.9.0.33

MX RR有一个RDATA部分,由一个16位数字和一个域名组成。地址RR使用标准IP地址格式来包含32位互联网地址。

上面的示例显示了六个RR,三个域名中的每一个都有两个RR。

下面是另一个可能的例子:

XX.LCS.MIT.EDU.IN A10.0.0.44
 CH AMIT.EDU. 2420

这显示了 XX.LCS.MIT.EDU 的两个地址,每个class都不同。

3.5.2. MX记录的探讨

如上所述,域服务器将信息存储为一系列资源记录,每个记录都包含有关给定域名(通常是主机,但并不总是主机)的特定信息。将RR视为一对类型化的数据,一个与相关数据匹配的域名,并存储了一些额外的类型信息,以帮助系统确定RR何时相关。

MX记录用于控制电子邮件的传递。记录中指定的数据是优先级和域名。优先级控制着尝试发送电子邮件的顺序,最低的数字排在第一位。如果两个优先级相同,则随机选择一个服务器。如果给定优先级的服务器没有响应,则邮件传输代理将回退到下一个最大优先级。优先级编号没有任何绝对意义;它们仅与该域名的其他MX记录相关。给定的域名是邮件传递到的机器。它必须有一个关联的地址记录(A或AAAA);CNAME不够。

对于给定的域,如果同时存在CNAME记录和MX记录,则MX记录出错并被忽略。相反,邮件会被传递到CNAME指向的MX记录中指定的服务器。例如:

     
example.com.INMX10mail.example.com.
 INMX10mail2.example.com.
 INMX20mail.backup.org.
mail.example.com.INA10.0.0.1 
mail2.example.com.INA10.0.0.2 

尝试将邮件传递到 mail.example.commail2.example.com (以任何顺序);如果这两个都不成功,则尝试传递到 mail.backup.org

3.5.3. 设置 TTLs

RR字段的生存时间(TTL)是一个以秒为单位表示的32位整数,主要由解析器在缓存RR时使用。TTL描述了RR在丢弃之前可以缓存多长时间。区域文件中当前使用以下三种类型的TTL。

所有这些TTL默认为秒单位,但可以明确指定单位:例如 1h30m

3.5.4. IPv4中的反向映射

反向名称解析(即从IP地址到名称的转换)是通过 in-addr.arpa 域和PTR记录实现的。in-addr.arpa域中的条目按从左到右的最小到最大的顺序排列。这与通常写入IP地址的顺序相反。因此,IP地址为10.1.2.3的机器将具有相应的in-addr.arpa名称3.2.1.10.in-addr.arpa。此名称应具有一个PTR资源记录,其数据字段是机器的名称,或者如果机器有多个名称,则可以选择多个PTR记录。例如,在 example.com 域中:

$ORIGIN2.1.10.in-addr.arpa
3IN PTR foo.example.com.

注: 本例中的 $ORIGIN 行仅用于提供上下文;它不一定出现在实际使用中。此处仅用于表示该示例与所列的来源有关。

3.5.5. 其他区域文件指令

DNS“主文件”格式最初在 RFC 1035 中定义,随后被扩展。虽然格式本身是类独立的,但区域文件中的所有记录必须属于同一类。

主文件指令包括 $ORIGIN$INCLUDE$TTL

3.5.5.1. @ 符号

在标签(或名称)字段中使用时,asperand或at符号(@)表示当前原点。在区域文件的开头,是<zone_name>,后面是一个尾随点(.)。

3.5.5.2. $ORIGIN 指令

语法:$ORIGIN domain-name [comment]

$ORIGIN 设置附加到任何不合格记录的域名。当第一次读取区域时,会有一个隐式的 $ORIGIN <zone_name>. ;注意后面的圆点。如果当前 $ORIGIN 不是绝对的(absolute),则将其附加到 $ORIGIN 参数中指定的域。

等价于

3.5.5.3. $INCLUDE 指令

语法:$INCLUDE filename [origin] [comment]

这将读取和处理 filename ,就像它此时包含在文件中一样。filename 可以是绝对路径,也可以是相对路径。在后一种情况下,它是从 named 的工作目录中读取的。如果指定了origin ,则使用设置为该值的 $ORIGIN 处理文件;否则,将使用当前的$ORIGIN

一旦读取文件,源(origin)和当前域名将恢复到$INCLUDE之前的值。

注: RFC 1035规定,在 $INCLUDE 之后应恢复当前来源,但它没有说明是否也应恢复当前域名。BIND 9可以恢复这两个值。这可以被解释为与 RFC 1035 的偏差、特征或两者兼而有之。

3.5.5.4. $TTL 指令

语法:$TTL default-ttl [comment]

这将为具有未定义TTL的后续记录设置默认生存时间(TTL)。有效TTL的范围为0-2147483647秒。

$TTLRFC 2308 中定义。

3.5.6. BIND主文件扩展名:$GENERATE指令

语法:$GENERATE range owner [ttl] [class] type rdata [comment]

$GENERATE 用于创建一系列资源记录,这些记录仅通过迭代器彼此不同。

举例:

$GENERATE 可用于轻松生成支持 RFC 2317 中描述的sub-/24反向委托所需的记录集:

等价于:

此示例创建了一组a和MX记录。请注意,MX的 rdata 是一个带引号的字符串;处理 $GENERATE 时,引号会被删除:

等价于:

此示例使用修饰符生成A和AAAA记录;AAAA owner 名称是使用半字节模式生成的:

等价于:

$GENERATE 指令是BIND扩展名,不是标准区域文件格式的一部分。

3.5.7. 附加文件格式

除了标准文本格式外,BIND 9还支持读取或转储其他格式的区域文件。

raw 格式是区域数据的二进制表示,其方式类似于区域传输中使用的方式。由于它不需要解析文本,因此加载时间大大缩短。

对于主服务器,应通过 named-compilezone 命令从文本区域文件生成 raw 格式的区域文件。对于辅助服务器或动态区域,如果 masterfile-format 选项指定了其中一种格式,则当 named 转储区域传输后的区域内容或应用先前更新时,会自动生成区域文件。

如果 raw 格式的区域文件需要手动修改,则必须首先通过 named-compilezone 命令将其转换为 text 格式,然后在编辑后转换回来。例如: