应使用配置管理维护BIND配置文件，以便在出现错误时可以轻松恢复到以前的版本。 一种方法是使用Git。 为此，您将为主服务器提供两个Git存储库：一个名为etc，另一个名为maps。 在etc中，你放置所有BIND配置文件; 在地图中，您可以放置所有区域文件。

#On a git server, in /gitrepos/dns/master directory
$ git –bare init etc
Initialized empty Git repository in /gitrepos/dns/master/etc/
$git –bare init maps
Initialized empty Git repository in /gitrepos/dns/master/maps/
#On the BIND master server if BIND is installed in, say, /opt/bind
$ cd /opt/bind
$ git clone git@gitserver.example.com:/gitrepos/dns/master/etc
$ git clone git@gitserver.example.com:/gitrepos/dns/master/maps

对于从属服务器，为etc和maps维护一个单独的repo。 所有奴隶都可以共享相同的Git仓库。

#On a git server, in /gitrepos/dns/slave directory
$ git –bare init etc
Initialized empty Git repository in /gitrepos/dns/slave/etc/
$ git –bare init maps
Initialized empty Git repository in /gitrepos/dns/slave/maps/
#On the BIND server in if BIND is installed in, say, /opt/bind
$ cd /opt/bind
$ git clone git@gitserver.example.com:/gitrepos/dns/slave/etc
$ git clone git@gitserver.example.com:/gitrepos/dns/slave/maps

要更改区域文件，请在桌面上克隆Git存储库，进行更改，测试，然后执行Git推送。 在该测试之后，在BIND主服务器上执行Git pull ..对任何从DNS服务器重复此过程。

避免直接在生产主站或从站中进行任何更改。 始终在本地Git存储库中进行更改，测试，推送到测试服务器，再次测试，然后推送到生产主机。

命名配置文件

BIND配置文件名为named.conf，是BIND工作流程的起点。 此文件控制BIND的行为和功能。 该文件的位置通常位于/ etc目录中。 该文件由子句组成，这些子句在语句中组合在一起。 您也可以在此文件中添加注释，该注释可以以＃，/ *或//开头。 如果对/ *使用C风格的注释，则必须使用* /结束它们的C风格。 BIND对named.conf的内容非常挑剔，因此在编辑此文件时要格外小心。 即使很小的语法错误也会导致BIND的加载失败。 练习8-1显示了一个名为.conf的配置示例。

练习8-1。 SAMPLE NAMED.CONF

logging语句指定日志的去向和记录的内容。 在这种情况下，我们将在日志目录中记录名为named.log的文件。 有许多严重性，例如严重，错误，警告，通知，信息，调试和动态。 让我们选择信息级别，它会记录信息和上面的所有信息，包括信息，通知，警告，严重和错误。 我建议监视日志记录以确保磁盘上有足够的空间。 在这种情况下，我们保留了五个版本的日志文件，每个文件最多为10MB。

#logging-specific statements
logging {
 channel default_log {
 file "log/named.log" versions 5 size 10m;
 severity info;
 print-time yes;
 print-severity yes;
 print-category yes;
 };
 category default {
 default_log;
 };
};

下一个子句控制常规服务器选项，例如BIND将在哪个目录中运行。 在这种情况下，我们使用chroot环境来保证安全性，因此我们需要指定/。 查询缓存和查询控件看起来很相似; 但是，区别在于allow-query适用于任何查询，包括非授权数据，而query-cache允许访问缓存中的条目。 缓存条目通常是服务器通过递归学习的条目。 您只需指定它们授予访问权限的网络是否不同; 否则，指定一个就足够了，因为另一个对访问控制列表（ACL）的行为方式相同。 您可以在https://kb.isc.org/article/AA-00503/0/Whats-the-difference-between-allow-query-cache-and-allow-recursion.html上阅读更多相关信息。

my-networks语句定义了一组稍后在ACL子句中定义的网络。 allow-transfer语句用于权威传输（AXFR）查询类型，我们仅限于我们的辅助服务器。

notify告诉BIND在主服务器上进行更改时通知从/备用服务器。 statistics-file记录有关BIND性能的统计信息，当然，pid-file记录正在运行的进程的进程ID（PID）。

#general server options
options {
 directory "/";
 allow-query-cache { my-networks; };
 allow-query { my-networks; };
 allow-recursion { my-networks; };
 allow-transfer { 10.1.1.100; 10.1.2.100; };
 notify yes;
 statistics-file "log/named.stats";
 pid-file "log/named.pid";
};

ACL是您控制BIND中数据访问的方式。 在这种情况下，在通用服务器选项子句中，我们仅允许从现在定义的my-networks进行递归。 它们包含本地主机和10.1.0.0/16的/ 16网络。

#acl-related statements
acl "my-networks" {
 127.0.0.1;
 localhost;
 localnets;
 10.1.0.0/16;
};

注意

访问控制列表（ACL）是保护谁可以访问DNS区域信息的关键。 确保始终使用ACL，并仅指定需要访问DNS区域数据的网络。

对于某些区域，您可能希望将查询重定向到代理DNS服务器。 在这种情况下，对于example.org上的传入查询，让我们将它们转发到example.org的DNS服务器，这些服务器列在转发的pragma中。 对于您认为将查询DNS服务器的每个区域，您不需要转发器区域。 您可以在http://www.zytrax.com/books/dns/ch4/#forwarding上了解转发的其他优势。

# a forwarding sample
zone "example.org" {
 type forward;
 forwarders { 199.43.132.53; 199.43.133.53; };
};

BIND允许使用名为rndc的工具管理BIND。 此工具是基于密钥的，因此我们需要一个子句来指定密钥名称，密钥文件位置和要监听的端口。

#rndc statements
include "etc/rndc.key";
controls {
 inet 127.0.0.1 port 953
 allow {127.0.0.1;} keys { "rndc-key"; };
};

BIND的引导是通过根提示服务器完成的。 您可以从http://www.internic.net/domain/named.root下载root.hints。

#dns bootstrapping statements
zone "." {
 type hint;
 file "etc/root.hints";
};

下一个条款适用于我们托管的区域，即example.com。 文件example.com.zone包含所有非PTR相关的记录，例如NS，SOA，A，CNAME，MX，TXT等。

#example.com zone
zone "example.com" {
 type master;
 file "maps/example.com.zone";
 allow-transfer {
 10.1.0.0/16;
 };
};

最后但并非最不重要的是反向查找或PTR区域文件的位置。 在这种情况下，我们为10.1.1.0/24网络指定一个。

zone "1.1.10.in-addr.arpa" {
 type master;
 file "maps/reverse/1.1.10.rev";
};

abc