《DNS与BIND(第5版)》——7.3 整理文件

7.3 整理文件

当首次设置区域时,整理文件很简单:将它们全部放到一个目录中即可。这些文件中包含了一个配置文件和数个区域数据文件。然而,随着时间的推移,任务会越来越艰巨。有更多的网络加入,相应地就有更多in-addr.arpa区域。或许已经授权了一些子域,也已经开始为其他站点备份区域。一段时间后,当使用ls查看名称服务器的目录时,会发现一屏都无法列出所有内容。是时候重新整理这些文件了。BIND提供了一些功能用来帮助进行文件的整理。

BIND名称服务器支持一个叫做include的配置文件语句,它允许将一个文件的内容插入到当前的配置文件中。这个功能可以将一个非常大的配置文件分成多个较小的文件。

区域数据文件(适用于所有BIND版本)支持2条1控制语句:$ORIGIN和$INCLUDE。$ORIGIN语句可以改变一个区域数据文件的来源(origin),而$INCLUDE语句可以在当前的区域数据文件中插入新的文件。这两条控制语句并非资源记录;它们用来帮助维护DNS数据。特别是,它们让区域划分成子域的工作变得更简单:可以将每个子域的数据存放在不同的文件中。

7.3.1 使用多个目录
整理区域数据文件的方法之一,就是将其存放到不同的目录中。如果名称服务器是多个站点所在区域(正向和逆向解析)的primary,则可以将每个站点的区域数据文件分别存放到各自的目录中。另一种方法是将所有primary区域的数据文件存放到一个目录中,而将所有备份区域的数据文件存放到另一个目录中。如果选择将primary和slave区域分开的方式,那么配置文件看起来可能会像下面这个样子:

https://yqfile.alicdn.com/0853014d52eb38fbff8da697d05dd34a5261e608.png" >

这种划分方法的另一种变化,就是将配置文件分成三个文件:主文件,包含所有primary条目的文件,以及包含所有secondary条目的文件。主配置文件的内容如下所示:

https://yqfile.alicdn.com/d0d2a0b7a14bbe43d4f59429aba3adc9cc912cd6.png" >

named.conf.primary文件的内容如下所示:

https://yqfile.alicdn.com/57959b781781b84ce7b7594fca9a508e6c64a17b.png" >

named.conf.slave文件的内容如下所示:

https://yqfile.alicdn.com/fa40bcadbddb0c2535847eab54cb7064bdd13683.png" >

可能会觉得下面这种整理文件的方法会更好:将包含primary字样的配置文件放入primary子目录中,通过增加一个新的directory指令切换到此目录,并且删除每个文件名中的primary/(因为名称服务器现在就运行在该目录中)。然后对包含secondary字样的配置文件做类似的改变。遗憾的是,这种方法不起作用。BIND只允许定义一个工作目录。当名称服务器在不同目录间不断切换时,事情会变得相当混乱:例如,备份区域数据文件最终会在名称服务器切换到的上一个目录中。
**
7.3.2 改变区域数据文件的来源**
在BIND中,区域数据文件的来源(origin),默认是named.conf文件中zone语句的第二个字段。来源是一个域名,会自动附加到区域数据文件中所有不以“.”结尾的名称上。在区域数据文件中,可以使用$ORIGIN控制语句来修改来源,$ORIGIN后面跟着一个域名。(如果使用完整的域名,则不要忘记结尾的“.”!)此后,凡是不以“.”结尾的名称就会附加上新的来源。如果区域(例如movie.edu)中包含数个子域,可以使用$ORIGIN语句重新设置来源,并简化区域数据文件。例如:

https://yqfile.alicdn.com/823f88e6a68228b1f07e1ef02143f7d6e0c58b8e.png" >

本书第9章会深入讨论如何创建子域。

7.3.3 引入其他区域数据文件
一旦将区域划分成子域,就会发现,将每个子域的记录分别放在不同的文件中会比较方便。$INCLUDE控制语句可以帮助完成此项工作:

https://yqfile.alicdn.com/3881db745d3dbc9a3080efd9e0a314b4ec3d083e.png" >

要想进一步简化该文件,可以在引入文件时,在同一行指定新的来源:

https://yqfile.alicdn.com/829566561f855e4d82ccd613b0ed47f52c4d13ff.png" >

当在同一行指定来源和引入文件时,该来源只会作用于所引入的特定文件。例如,comedy.movie.edu这个来源只作用于db.comedy.movie.edu中的名称。在引入db.comedy.__movie.edu文件后,即使db.comedy.movie.edu中也有$ORIGIN控制语句,来源还是会变回$INCLUDE之前的设置。

时间: 2024-09-29 08:45:48

《DNS与BIND(第5版)》——7.3 整理文件的相关文章

《DNS与BIND(第5版)》——10.12 系统优化

10.12 系统优化 对于大多数名称服务器来说,在BIND的默认配置下就能工作得很好,然而可能其中某个还需要进一步调优.本节将讨论可以用来优化名称服务器的所有配置项. 10.12.1 区域传输区域传输会给名称服务器带来沉重的负担.所以BIND提供一些机制,可以限制slave名称服务器给master服务器带来的区域传输负载. 1.限制请求单个名称服务器传输的区域数量 在slave名称服务器上,可以限制其一次能够向单个master名称服务器请求传输的区域数量.这样master名称服务器的管理员应该会

《DNS与BIND(第5版)》——10.5 转发机制

10.5 转发机制 某些网络连接不希望发送过多的流量到外界去,可能是因为对外的连接速率低.延迟高:例如,远程办公室通过卫星连接到公司的网络.在这些情况下,可能需要将对外的DNS流量限制到最低.BIND提供了一种解决此问题的机制:转发器(forwarder). 如果需要将名称解析分流至特定的名称服务器,那么转发器也是很有用的.例如,如果网络中只有一台主机连接到Internet,并且该主机是名称服务器,则可以将其配置为其他名称服务器的转发器,这样它们就可以查询Internet上的域名了.(本书第11

《DNS与BIND(第5版)》——10.2 DNS动态更新

10.2 DNS动态更新 Internet(即通常使用TCP/IP协议的网络)如今变得愈加动态化.许多大型企业使用DHCP动态分配IP地址.几乎所有的ISP都使用DHCP为其拨号及使用线缆调制解调器(cable modem)的用户分配IP地址.为适应这种变化,DNS需要提供动态增加和删除记录的功能.RFC 2136描述了这种机制,称为DNS动态更新. BIND 8和9支持RFC 2136提出的动态更新功能.此功能允许经过授权的更新者(updater),在区域中的权威名称服务器上增加和删除资源记录

《DNS与BIND(第5版)》——7.5 日志记录

7.5 日志记录 BIND支持扩展的日志记录(logging),包括将信息写入调试文件和发送至syslog.不过,使用扩展的日志记录是有代价的:在能够有效地控制该子系统前,必须要学习很多知识.如果没有时间来实验日志记录,那么就先使用默认值,等以后有空再来研究这个主题.大部分人并不需要更改日志记录的默认行为. 日志记录有两个主要的概念:通道(channels)和类别(categories).通道用来指定日志数据的流向:syslog.文件.named的标准错误输出或是bit bucket.类别用来指

《DNS与BIND(第5版)》——10.11 回避伪装的名称服务器

10.11 回避伪装的名称服务器 作为名称服务器的管理员,可能会发现某些远程名称服务器用有害的信息作为应答,这些信息可能是过时的.不正确的.格式错误的,甚至是故意欺骗的.可以尝试通知对方的管理员来修复该问题.或者通过配置,让名称服务器不再查询该服务器,BIND 8和BIND 及其后续版本支持这个功能.下面是配置文件中的语句: 当然,需要填入正确的IP地址. 如果名称服务器停止查询的服务器,是一个区域唯一的服务器,那么不要指望能够查询到位于该区域的名称了.但愿,还存在其他服务器可以提供关于该区域的

《DNS与BIND(第5版)》——10.9 优先选择特定网络上的名称服务器

10.9 优先选择特定网络上的名称服务器 BIND 8的拓扑(topology)功能与sortlist有些相似,不过它仅用于选择名称服务器.(BIND 9直到版仍不支持拓扑功能.)本章前面曾介绍过,BIND会从同一区域的各权威名称服务器中,选择出往返时间(round-trip time,简称RTT)最短的名称服务器.事实上并非如此.BIND 8在比较RTT时,实际上会把远程名称服务器分配到以64毫秒为单位划分的多个时段中.第一时段其实只有32毫秒宽,从0到32毫秒.下一时段从33到96毫秒,依次

《DNS与BIND(第5版)》——4.2 建立区域数据

4.2 建立区域数据 建立电影大学名称服务器的第一步,是将主机表转换成等效的DNS区域数据.该数据的DNS版本有多个文件.一个文件将所有主机名映射成地址.其他文件将地址映射回主机名.名称到地址(name-to-address)的查询有时被称作正向解析(forward mapping),而地址到名称(address-to-name)的查询则被称作逆向解析(reverse mapping).每个网络都拥有自己的逆向解析数据文件. 作为本书的一个约定,将主机名映射到地址的文件称作db.DOMAIN.例

《DNS与BIND(第5版)》——10.4 增量区域传输(IXFR)

10.4 增量区域传输(IXFR) 有了动态更新和NOTIFY功能,就可以随着网络状态的改变而更新区域数据,并且这些变动可以迅速传送至区域的所有权威名称服务器.看起来很完美,不是吗? 其实不尽然.在一个大型区域中,动态更新的频率是非常惊人的.不难想象:存在这样一个大型区域,其中包含上千个客户端,可是某天管理者突然决定使用Active Directory和DHCP.现在每个客户端都要更新自己在区域中的地址记录,并且域控制器(Domain Controllers)也会更新一些记录以便通知客户端它们提

Linux服务器配置之DNS——采用BIND

众所周知,Linux虽然在桌面应用上赶不上Windows普及和易用,但也恰恰是因为其看起来很麻烦的命令行操作,使得其在安全性方面要优于为了易用而采用图形化界面的windows ,正因如此,使得Linux在服务器方面可以大展拳脚,其中尤以apache著称的LAMP和DNS服务器BIND更是使用普遍.下面说说bind的配置方法. 首先,从以前写的文章知道,我采用的操作系统是RED HAT Fedora Core 7,在安装系统的时候,在选择软件包的时候,我是采用的自定义方式,我把一些没用的软件如那些