DNS日志记录以及VIEW视图
https://blog.51niux.com/?id=122 已经记录了dns的基本知识和基本搭建过程，这里记录一些稍微高级一点的东西。
一、BIND日志
1.1 日志概念
在日志中主要有两个概念：通道（channel）和类别（category）。通道指定了应该向哪里发送日志数据（是发送给syslog，还是写在一个文件里，还是发送给named的标准错误输出，还是发送到位存储桶（bit bucket））。
通道允许根据不同的级别对消息进行过滤。下面是不同的级别列表，按照严重性递减的顺序：critical、error、warning、notice、info、debug[level]、dynamic。最后两个级别是bind 8和9特有的。
debug可以指定调试级别，默认是1.如果指定了debug 3，那么当你只是像名字服务器发送一个跟踪命令时，就会看到第三级调试信息。
如果规定了dynamic这个级别，那么名字服务器就会记录所有与调试级别匹配的日志消息。
默认的级别是info,也就是说，除非你指定了登记，否则看不到任何调试信息。
1.2 logging语句
logging {
[ channel channel_name {
( file path name
[ versions ( number | unlimited ) ]
[ size size spec ]
| syslog syslog_facility
| stderr
| null );
[ severity (critical | error | warning | notice |
info | debug [ level ] | dynamic ); ]
[ print-category yes or no; ]
[ print-severity yes or no; ]
[ print-time yes or no; ]
}; ]
[ category category_name {
channel_name ; [ channel_name ; ... ]
}; ]
...
};1. channel:
所有日志会输出到一个或多个channel中。每个通道的定义必须包括一个目的字句，用来确定所选的相关通道的信息，将会被输出到一个文件，或者到一个特殊的syslog工具，或者到一个标准错误流，或者被忽略。
目的子句为null时：会使所有发送给通道的信息被丢弃；那样的话，其他通道选项就没有意义了。
目的子句为file 时：会使通道的内容输出到一个磁盘文件。它可以包含这个文件的大小和该文件可以保存多少个版本。
如果使用versions日志文件选项：named就会自动保留多个版本的日志文件。例如，如果选择保存文件lamers.log的三个老版本，那么在它被打开的时候lamers.log.1被更名为lamers.log.2，lamers.log.0 被更名为lamers.log.1 ，lamers.log 被更名为lamers.log.0。也可以设置version unlimited，这样就没有备份版本的限制了。
如果对日志文件设置了size选项：那么仅当此文件超过了设定的大小时，系统就会进行更名。默认情况下不储存备份文件；所有存在的日志文件被简单进行追加。文件的size 选项用来限制日志的增长。如果文件超过了限制，又没有versions选项则named 就会停止写入文件。如果保留了备份版本，则备份文件如上所述进行滚动命名，然后开始创建一个新的文件。如果没有versions选项，也没有其它的机制来删除或减小日志文件，则系统就不会有数据继续写入日志中。默认状态是不限制文件的大小的。K或k代表千字节，M或m代表兆字节，G或g代表千兆字节。
syslog 目的子句是把通道指向系统日志：它的参数是一个syslog的前缀，如syslog帮助中所述。syslog是怎样处理带有这些前缀的信息，可以参考syslog.conf 的帮助信息。
severity子句：象syslog中的”priorites”一样工作，唯一区别的是用户可以直接写入一个文件，而不是使用syslog写入一个文件。不到严重级的信息将不会被通道选择；高严重级的信息将会被接受。如果用户正在使用syslog，那么syslog.conf 的优先级也会决定什么会最终通过。例如，将channel facility和severity定义成daemon和debug，就不会只记录通过syslog.conf的daemon.warning信息，后者会使severity是info和notice的信息被丢弃。如果情况相反，named就会只记录warning或更高级别的信息，而syslogd则会记录来自于通道的所有信息。
stderr目的子句：将通道输出到服务器的标准错误流。它用于服务器在前台运行的情况下，例如，当处于debug模式的时候，服务器能提供丰富的调试信息。如果服务器的全局debug级别（globe debug level）大于0，debug 模式将被激活。全局debug级别可以通过在启动named时设置“-d”参数加一个正数，或运行rndc trace来设置。如果要关闭debug模式，则将全局debug 级别设置成0，或运行rndc notrace。服务器中所有的debug信息有一个debug级别，高调试级给出更详细的输出。
2. category:
这里存在许多分类，用户可根据需要定义想看到或不想看到的日志。如果你不将某个分类指定到某些通道的话，那么在这个分类的日志信息就会被发送到default分类通道中。
default: 默认分类,default类别匹配所有未明确指定通道的类别。
general: 包括所有未明确分类的BIND消息，没有分类的日志都记录在此分类中。
database: 同BIND内部数据库相关的消息，用来存储区数据和缓存记录。
security: 允许/拒绝的请求.
config: 配置文件分析和处理.
resolver: DNS解析,包括对来自解析器的递归查询的处理。
xfer-in: 接收区域传输.
xfer-out: 发送区域传输.
notify: 异步区变动通知。
client: 处理客户端请求
network: 网络操作.
update: 动态更新事件。
queries: 客户端队列日志.
dnssec: DNSSEC和TSIG协议处理.
lame-servers: 发现错误授权。
1.3 实例介绍
# cat /etc/named.conf
logging {
channel default_debug { //定义了一个通道，名称叫做default_debug
file "/var/named/log/named.run"; //通道的字句是file，也就是将日志写到指定的文件中去
severity dynamic; //日志级别设置成了dynamic，会观察所有的调式信息。
};
channel query_info { //定义了一个query_info的通道
file "/var/named/log/query.log" versions 1 size 100m; //日志记录位置是/var/named/log/query.log，versions 1就表示当此日志文件超过100MB的时候，会把当前的文件改名为，让后新的文件继续叫做query.log来接收日志，但是一旦又超过100MB，就会将query.log.0覆盖掉。
severity info; //定义日志级别为info，默认也是这个级别。
print-category yes; //打印日志的类型
print-severity yes; //打印日志级别
print-time yes; //打印时间，不过如果是存储在syslog里面的话，就不要打印时间了，因为syslog有自己的日志时间格式
};
category queries { //这是定义了queries这个类型的日志写到下面两个通道里面去，也就是既写一份到/var/named/log/named.run文件又写一份到/var/named/log/query.log文件
query_info;
default_debug;
};
channel notify_info { //又定义了一个名称为notify_info的通道
file "/var/named/log/notify.log" versions 8 size 128m; //这个就是写入到/var/named/log/notify.log文件，可以产生notify.log.0-7共八份的备份文件，日志大小为128MB，不定义大小的话就是无线增长
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category notify { //这里就是定义了notify这个通知类型也会记录到两个通道里面去
notify_info;
default_debug;
};
channel xfer_in_log { //这是名称为接收区域传输的通道，一般应该在DNS辅助服务器上面设置
file "/var/named/log/xfer_in.log" versions 100 size 10m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel xfer_out_log { //这是名称为发送区域的通道，一般应该在DNS主服务器上面设置
file "/var/named/log/xfer_out.log" versions 100 size 10m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category xfer-in { xfer_in_log; }; //定义了接收区域类型发送到接收区域传输通道
category xfer-out { xfer_out_log; }; //定义了发送区域类型发送到发送区域传输通道
};下面查看一下几个日志里面的内容：
# tail -f /var/named/log/xfer_out.log
06-Jun-2017 20:01:21.356 xfer-out: info: client 192.168.1.104#11043 (51niux.in): transfer of '51niux.in/IN': AXFR-style IXFR started #注意这个格式是时间，category类型，日志级别，以及内容 06-Jun-2017 20:01:21.356 xfer-out: info: client 192.168.1.104#11043 (51niux.in): transfer of '51niux.in/IN': AXFR-style IXFR ended
# tail -f /var/named/log/query.log
06-Jun-2017 20:00:07.557 queries: info: client 192.168.1.102#48285 (agent1.salt.salt): query: agent1.salt.salt IN A + (192.168.1.101) 06-Jun-2017 20:00:07.562 queries: info: client 192.168.1.102#43367 (agent1.salt): query: agent1.salt IN A + (192.168.1.101) 06-Jun-2017 20:00:07.563 queries: info: client 192.168.1.102#13448 (agent1.salt.salt): query: agent1.salt.salt IN A + (192.168.1.101) 06-Jun-2017 20:00:07.565 queries: info: client 192.168.1.102#42527 (agent1.salt): query: agent1.salt IN A + (192.168.1.101) 06-Jun-2017 20:00:07.566 queries: info: client 192.168.1.102#62973 (agent1.salt.salt): query: agent1.salt.salt IN A + (192.168.1.101) 06-Jun-2017 20:01:21.353 queries: info: client 192.168.1.104#4170 (51niux.in): query: 51niux.in IN SOA -E (192.168.1.101) 06-Jun-2017 20:01:21.356 queries: info: client 192.168.1.104#11043 (51niux.in): query: 51niux.in IN IXFR -T (192.168.1.101)
# tail -f /var/named/log/notify.log
06-Jun-2017 19:57:58.991 notify: info: zone 51niux.in/IN: sending notifies (serial 2017060620) 06-Jun-2017 20:01:21.351 notify: info: zone 51niux.in/IN: sending notifies (serial 2017060621)
另外：
为了丢弃一个分类中的所有信息，可以设定null 通道：
category "xfer-out" { "null"; };
category "notify" { "null"; };
博文来自：www.51niux.com
二、 地址匹配列表和ACL
2.1 理论知识
地址匹配列表的每一项指定一个或多个IP地址。该列表中的元素可以是独立的IP地址、IP前缀或是一个已命名的地址匹配列表。
如：15.0.0.0和192.168.1.192-192.168.1.255可以写成：15/8; 192.168.1.192/26;
已命名的地址匹配列表就是有名字的地址匹配列表。要想在另一个地址匹配列表中使用已命名的地址匹配列表，必须在被引用之前用一个acl语句在named.conf中对它进行定义。如：acl name { address_match_list； };
四个预定义名字的地址匹配列表：
none : 没有任何IP地址。
any：所有的IP地址。
localhost : 本地主机。
localnets：本地主机任一网络接口所在的网络（用网络掩码屏蔽掉每个网络接口的IP地址中的主机位后所得到的）。
2.2 实例分析
实例1，限制查询：
# cat /etc/named.conf
options { //在options里面加上下面几行
//allow-query {any;};
allow-query { allow_clients; }; //将其他的查询设置都注释掉，只留现在的一条，只允许定义的allow_clients访问控制列表发起请求，这个列表名称需要提前定义好然后等待被引用。
//allow-query-cache { any; };
include "/etc/named.conf.acls"; //在文件的最末尾添加这么一句话，我们的acl语句都在这里定义，这样保证尽量少的修改named.conf配置文件
};# cat /etc/named.conf.acls #我们的acl语句都写到这个文件里面
acl allow_clients{ //allow_clients这个就是我们上面的控制列表名称，有点类似于列表变量之类的，allow_clients这个就是变量名称，{}里面就是变量allow_clients的值，类似于python的列表。
192.168.1.103; //这是很简单的一个多IP的设置，两个IP一个一行用;隔开，这里也可以定义网段之类的。
192.168.1.104;
};# service named reload #重新加载配置文件，然后分别让192.168.1.102和192.168.1.104发起解析请求，然后192.168.1.102失败,192.168.1.104成功。下面是日志里面的内容：
# tail -f /var/named/log/named.run
client 192.168.1.102#35250 (www.51niux.in): query: www.51niux.in IN A + (192.168.1.101) client 192.168.1.102#35250 (www.51niux.in): query 'www.51niux.in/A/IN' denied client 192.168.1.102#26008 (www.51niux.in): query: www.51niux.in IN A + (192.168.1.101) client 192.168.1.102#26008 (www.51niux.in): query 'www.51niux.in/A/IN' denied //从日志结果上面看,192.168.1.102是失败的 client 192.168.1.102#19843 (www.51niux.in.salt): query: www.51niux.in.salt IN A + (192.168.1.101) client 192.168.1.102#19843 (www.51niux.in.salt): query (cache) 'www.51niux.in.salt/A/IN' denied client 192.168.1.102#17778 (www.51niux.in.salt): query: www.51niux.in.salt IN A + (192.168.1.101) client 192.168.1.102#17778 (www.51niux.in.salt): query (cache) 'www.51niux.in.salt/A/IN' denied client 192.168.1.103#33191 (www.51niux.in): query: www.51niux.in IN A + (192.168.1.101) client 192.168.1.103#22706 (103.1.168.192.in-addr.arpa): query: 103.1.168.192.in-addr.arpa IN PTR + (192.168.1.101) //从日志结果看192.168.1.103是成功的
实例2，zone限制同步以及访问：
#cat /etc/named.rfc1912.zones #生产中我们主配置文件肯定只允许我们制定的辅助DNS服务来同步，另外呢，我们定义的这个域名解析服务可能并非是公网域名服务的，可能是我们机房机器内部之间为了防止IP的变得而做的一种线上生产或者测试，机器内部使用的一种域名解析服务，一般是不允许外部的机器能够访问到的。就算是内部我们可能只是希望一小部分机器能够解析，其他的机器不想其能解析到可能会造成不必要的混乱。
zone "51niux.in" IN {
type master;
file "51niux.in.zone";
allow-transfer { slave_clients;}; //定义了一个列表名称slave_clients，这个列表里面的机器才能进行区域数据同步
allow-update { none;}; //不允许动态更新这个区
also-notify { 192.168.1.104;192.168.1.103; } ;//这里貌似不支持列表名称的形式，所以我改成了IP的形式，这里通知两个IP
allow-query { test_clients; }; //然后就是这个域的访问，只允许一部分机器能访问，test_clients列表以外的机器是不为其提供服务的。
};# cat /etc/named.conf.acls #再添加两条acl记录
acl slave_clients{
192.168.1.104;
};
acl test_clients{ //这里定义了只允许192.168.1这个网段的机器来访问，在生产上，可能要指定好多公网地址段，也就是只允许公司内部的机器来使用这个特点的域名解析
192.168.1.0/24;
};# service named reload #去给51niux.in.zone加一条DNS解析记录再重新加载配置文件，然后测试一下
# tail -f /var/named/log/named.run
client 192.168.1.104#8668 (51niux.in): query: 51niux.in IN SOA -E (192.168.1.101) client 192.168.1.104#18145 (51niux.in): query: 51niux.in IN IXFR -T (192.168.1.101) client 192.168.1.103#36921 (51niux.in): query: 51niux.in IN SOA -E (192.168.1.101) client 192.168.1.103#56973 (51niux.in): query: 51niux.in IN AXFR -T (192.168.1.101) client 192.168.1.103#56973 (51niux.in): zone transfer '51niux.in/AXFR/IN' denied //可以看到192.168.1.104和192.168.1.103都收到了通知然后去同步zone数据，结果192.168.1.103失败了因为没有在slave_clients里面
# tail -f /var/named/log/query.log #从日志中可以看出192.168.1.102去解析51niux.in整个域可以，去解析其他域的请求不可以。
07-Jun-2017 15:53:21.071 queries: info: client 192.168.1.102#63803 (www.51niux.in): query: www.51niux.in IN A + (192.168.1.101) 07-Jun-2017 15:53:21.101 queries: info: client 192.168.1.102#35428 (103.1.168.192.in-addr.arpa): query: 103.1.168.192.in-addr.arpa IN PTR + (192.168.1.101) 07-Jun-2017 15:53:21.102 queries: info: client 192.168.1.102#41899 (103.1.168.192.in-addr.arpa): query: 103.1.168.192.in-addr.arpa IN PTR + (192.168.1.101) 07-Jun-2017 15:53:44.237 queries: info: client 192.168.1.102#20759 (www.baidu.com): query: www.baidu.com IN A + (192.168.1.101) 07-Jun-2017 15:53:44.238 queries: info: client 192.168.1.102#21571 (www.baidu.com): query: www.baidu.com IN A + (192.168.1.101) 07-Jun-2017 15:53:44.239 queries: info: client 192.168.1.102#22308 (www.baidu.com.salt): query: www.baidu.com.salt IN A + (192.168.1.101) 07-Jun-2017 15:53:44.239 queries: info: client 192.168.1.102#11611 (www.baidu.com.salt): query: www.baidu.com.salt IN A + (192.168.1.101) 07-Jun-2017 15:58:05.600 queries: info: client 10.16.1.12#59807 (www.51niux.in): query: www.51niux.in IN A + (192.168.1.101) //非192.168.1网段的机器啥解析请求都是失败的 07-Jun-2017 15:58:05.601 queries: info: client 10.16.1.12#41994 (www.51niux.in): query: www.51niux.in IN A + (192.168.1.101) 07-Jun-2017 15:58:05.602 queries: info: client 10.16.1.12#33425 (www.51niux.in.localdomain): query: www.51niux.in.localdomain IN A + (192.168.1.101)
#从上面的日志信息和192.168.1.102本地的ping测试可以看出，我们再实例1的时候，192.168.1.102没有在allow_clients列表中所以解析请求没有通过，现在示例2我们再51niux.in域中开放了整个网段.
三、 转发
3.1 理论小知识
前面我们的设置并没有使用转发器，请求都是我们的DNS服务器去向公网递归的查询解析结果，而一个简单的设置并不能像114.114.114.114这类DNS服务器一样既稳定解析结果能够只能解析返回的结果会很精准。显然如果我们只是像搭建一个内部的DNS服务用来内部机器解析一些内部域名来互联，而还有访问外网域名的请求，显然使用BIND提供的转发器机制，既节省了网络流量方面的问题也解决的公网域名解析的问题。
当主或辅名字服务器被配置成使用转发器时，如果解析器请求的记录已经在名字服务器的权威数据或缓存数据中了，它就用该信息作为回答，这一部分操作没有变化。不过如果记录不在数据库中，名字服务器将向转发器发送查询，在继续正常操作之前，它会等待一段很短的时间，如果没有答案，就自己同远程名字服务器联系。这里名字服务器所做的不同之处在于它向转发器发送的是一个递归查询，期待它找到答案。如果不配置转发器，名字服务器向其他名字服务器发送的都是非递归查询，并处理收到的响应，这些响应指引它到另外的名字服务器。
3.2 配置
# cat /etc/named.conf
options { //在options选项里加上下面一句或两句
recursion yes; //这句话是一定也要有的，不然下面无法将类似于www.baidu.com之类的外网解析转发出去，但是因为有下面forward only; 就会保证在转发的DNS服务器不能提供服务的时候，我们这台机器也不会去公网迭代的去进行域名解析查询。
forward only; //加上这句话就是只转发了，就算下面设置的那两个服务器宕机了还是什么无法提供解析服务，我们这个名字服务器也不会自己去向权威服务器去进行请求了，就跟普通客户机本地设置/etc/resolv.conf一个意思了。
forwarders { 114.114.114.114;223.5.5.5; }; //这就是将非本域的请求都转发到这两个服务器去进行解析服务，等待他们的返回结果。
};博文来自：www.51niux.com
四、 VIEW（视图）
4.1 介绍
BIND9引入了另一个在防火墙环境中非常有用的机制----视图（VIEW）。视图允许你为一组主机提供一种名字服务器配置，而为另一组主机提供另一种不同的配置。如果不配置任何视图的话，BIND9会自动创建一个单一的、隐含的视图，所有访问它的主机看到的都是这个视图。这就可以让我们做智能DNS解析，根据来源IP的不同给返回不同的解析IP。
4.2 view语句的定义
view view_name [class] {
match-clients { address_match_list } ; //匹配来源IP
match-destinations { address_match_list } ; //匹配目的地址
match-recursive-only { yes_or_no } ; //来自匹配用户的递归请求将会匹配该视图
[ view_option; ...] //可以使用options里面的子语句
zone-statistics yes_or_no ; ] //如果设为”yes”，服务器将会为本域储存统计信息，可以存储到在服务器选项中定义的统计文件中。
[ zone_statement; ...] //zone语句定义区
};
#虽然视图名（view_name）可以是任何标书，不过最好还是用一个描述性的名称。尽管不需要引用视图名，但是最好尽量避免与BIND自己使用的保留字冲突。尽管view语句不需要紧跟在options语句后，但必须放到options语句后面。利用match-clients view子语句，可以选择哪些主机能看到某个视图，这个自语句用地址匹配列表作为参数。如果不用match-clients指定一组主机，那么该视图将应用于所有主机。
#视图内不能使用acl语句，所以使用地址匹配列表的话，必须要在视图之外定义ACL。在view语句中，能够使用大多数的options子语句，但是这些子语句不要封装在options语句中，在view语句中要独立使用它们。还可以在view语句中用zone语句定义区，用server语句描述远程名字服务器，以及用key语句配置TSIG秘钥。
#对于匹配match-clients的主机，在视图里你锁指定的任意配置豆浆覆盖同名的全局选项（例如在options语句中的选项）。view视图的定义主机列表和语句顺序的顺序很重要，所以any应该放到最后，把自定义的主机列表视图往前放。
4.3 示例解释
示例1，在view视图中定义zone区域
# vim /etc/named.conf
options {
...
recursion no; //为了测试效果，我们将全局的递归关闭了
...
}
view "internal"{ //首先定义了一个名称叫做internal的视图
match-clients { 192.168.1.0/24; }; //匹配来源IP是192.168.1.0网段的IP，也就是我们的内网IP
recursion yes; //然后为其打开视图
zone "51niux.tn" { //然后定义了一个51niux.tn的域
type master;
file "51niux.tn-int.zone"; //文件位置，因为我们是两个视图，不同的来源IP返回不同的解析结果，所以-int做一个区分标记。
};
};
view "external" { //定义了一个名称叫做external的视图
match-clients {any; }; //这里是any也就是所有，但是上面已经定义了192.168.1.0/24，然后此视图又在后面，所以这里表示除192.168.1.0/24以外所有的来源IP列表
recursion no; //我们为其关闭了递归，这里可以不用加因为全局已经关闭了。
zone "51niux.tn" { //zone域是相同的
type master;
file "51niux.tn-ext.zone"; //不同的是文件的名称，以-ext做个区分
};
};#这里有个要注意的地方，如果你/etc/named.rfc1912.zones里面定义了其他的zone没有再view视图里面，那里的zone定义就要失效了。你重新加载配置的时候在日志里会有下面的提示：
when using 'view' statements, all zones must be in views #当使用'view'语句时，所有区域必须在视图中
# cat /var/named/51niux.tn-int.zone
$ORIGIN 51niux.tn. // ORIGIN 设定﹐说明下面的记录源出何处，请您加倍留意最后的一个小数点“ .”不能少，有这个"."我们称这样以小数点结尾的名称为“ 全域名称 ”即 FQDN 。这里表示我们这个域是51niux.tn。 $TTL 86400 @ IN SOA ns1.51niux.tn. csp ( 2017060715 3H 1H 1W 1H ) 51niux.tn. IN NS ns1.51niux.tn. 51niux.tn. IN NS ns2.51niux.tn. @ IN MX 5 mail.51niux.tn. @ IN MX 10 mail2.51niux.tn. ns1 IN A 192.168.1.101 ns2 IN A 192.168.1.102 www IN A 192.168.1.103
# cat /var/named/51niux.tn-ext.zone
$ORIGIN 51niux.tn. $TTL 86400 @ IN SOA ns1.51niux.tn. csp ( 2017060715 3H 1H 1W 1H ) @ IN NS ns1.51niux.tn. @ IN NS ns2.51niux.tn. @ IN MX 5 mail.51niux.tn. @ IN MX 10 mail2.51niux.tn. ns1 IN A 192.168.1.101 ns2 IN A 192.168.1.102 www IN A 119.75.217.109 //其他的就不修改了，就把这个www的A记录修改一下吧
# service named reload #重新加载一下配置文件，分别用一个192.168.1.0/24段的客户端和一个非这个段的IP来ping www.51niux.tn测试查看下结果，并且分别解析下外网查看下效果。
# tail -f /var/named/log/query.log
08-Jun-2017 12:10:23.939 queries: info: client 192.168.1.102#31440 (www.51niux.tn): view internal: query: www.51niux.tn IN A + (192.168.1.101) 08-Jun-2017 12:10:23.941 queries: info: client 192.168.1.102#24961 (103.1.168.192.in-addr.arpa): view internal: query: 103.1.168.192.in-addr.arpa IN PTR + (192.168.1.101) //192.168.1.0段的访问www.51niux.tn返回的是192.168.1.103 08-Jun-2017 12:10:28.411 queries: info: client 192.168.2.12#59925 (www.51niux.tn): view external: query: www.51niux.tn IN A + (192.168.1.101) 08-Jun-2017 12:10:28.414 queries: info: client 192.168.2.12#59861 (109.217.75.119.in-addr.arpa): view external: query: 109.217.75.119.in-addr.arpa IN PTR + (192.168.1.101) 08-Jun-2017 12:10:28.415 queries: info: client 192.168.2.12#50001 (109.217.75.119.in-addr.arpa): view external: query: 109.217.75.119.in-addr.arpa IN PTR + (192.168.1.101) //其他IP返回的是119.75.217.109 08-Jun-2017 12:12:30.541 queries: info: client 192.168.1.102#33936 (www.baidu.com): view internal: query: www.baidu.com IN A + (192.168.1.101) 08-Jun-2017 12:12:30.546 queries: info: client 192.168.1.102#36188 (70.218.75.119.in-addr.arpa): view internal: query: 70.218.75.119.in-addr.arpa IN PTR + (192.168.1.101) //解析百度成功 08-Jun-2017 12:12:39.821 queries: info: client 192.168.2.12#55467 (www.baidu.com): view external: query: www.baidu.com IN A + (192.168.1.101) 08-Jun-2017 12:12:39.822 queries: info: client 192.168.2.12#46516 (www.baidu.com): view external: query: www.baidu.com IN A + (192.168.1.101) 08-Jun-2017 12:12:39.824 queries: info: client 192.168.2.12#45954 (www.baidu.com.localdomain): view external: query: www.baidu.com.localdomain IN A + (192.168.1.101) //解析百度失败 08-Jun-2017 12:12:39.825 queries: info: client 192.168.2.12#44466 (www.baidu.com.localdomain): view external: query: www.baidu.com.localdomain IN A + (192.168.1.101)
示例2、小延伸指定一些IP列表主机可以上网，也是view和acl相结合
# vim /etc/named.conf
acl allow_list { 192.168.2.0/24; };
view "external" { //示例1上面这里我们没有启用recursion yes;没有启用的话，就算options设置了fowwards也是得不到外网域名的解析结果的。
recursion yes; //但是如果一旦开启了这里，那所有除了为其余的IP解析51niux.tn这个域名以外，也就为其提供公网解析服务了，可能这不是我们想要的。
allow-recursion { allow_list;}; //可能我们只是像为其余IP里面的一部分主机提供公网域名解析服务，那么就要结合acl做一个IP列表或者直接再allow-recursion里面指定要允许的IP段。
match-clients {any; }; //这就涉及到规则的先后顺序问题了，any放到最后，上面的先执行完之后，再落到这个匹配规则，所有的IP都是可以得到51niux.tn的解析结果的。
zone "51niux.tn" {
type master;
file "51niux.tn-ext.zone";
};
};#找一个192.168.1.0段的，一个192.168.2.0段的，再找一个其他段的ping 51niux.tn和ping www.baidu.com测试一下，结果是可以符合我们的效果的，这里测试结果就不贴了。
#智能解析的时候就需要view和acl相结合了，用acl定义几个IP列表，然后里面分别是电信的IP段，联通的IP段等，然后view语句里用match-clients匹配定义的acl列表，然后指向不同的zone文件，做到根据来源IP做解析。
博文来自：www.51niux.com
五、key语句
5.1 介绍
BIND 8.2 在RFC 2845使用了一种保护DNS消息的新机制，称为“事务签名”或简写成TSIG。TSIG使用共享密钥和单向散列函数来鉴别DNS消息，特别是响应和更新。
如果配置了TSIG，名字服务器或更新者将在一个DNS消息的附加数据部分添加一个TSIG记录。TSIG记录对DNS消息签名，证明消息发送者和接受者共享一个加密密钥，并保证消息在离开发送者不被修改。通过使用称为单向散列函数的特殊类型和数学公司，TSIG提供认证和数据的完整性检查。单向散列函数，也被称为加密检验和(checksum)或消息摘要（digest），它对任意大小的输入都计算出一个固定长度的散列值。单向散列函数依赖于输入的每一位，若改变输入的某一位，散列值将急剧地变化，以至于对散列函数求反并获得产生散列值的输入的操作在计算机上是不可行。TSIG使用单向散列函数称为MD5，使用MD5的变种HMAC-MD5不仅依赖于输入还依赖于密钥。
5.2 配置TSIG
为了认证而使用TSIG前，我们需要在事务处理的双方配置一个或多个TSIG密钥。
示例1：先设置使用TSIG保护51niux.in的主、辅名字服务器之间的去传送。
在主DNS服务器上面的操作：
# dnssec-keygen -a hmac-md5 -b 128 -n HOST 51niux.in #dnssec-keygen -a hmac-md5 -b 128 -n HOST 是固定的命令格式，51niux.in是我们的签名，一般都用一个有代表性的签名去生成密钥文件。
K51niux.in.+157+01431
# cat K51niux.in.+157+01431.private
Private-key-format: v1.3 Algorithm: 157 (HMAC_MD5) Key: vbo0N6NuR3DwlhWkP/7c7w== //这是我们所需要的 Bits: AAA= Created: 20170608071914 Publish: 20170608071914 Activate: 20170608071914
# cat /etc/named.conf #在主、辅助DNS服务器上面都要加上下面的语句
key 51niux.in{ //在文件最上方加上这段话，定义一个名称为51niux.in的key
algorithm hmac-md5;
secret "vbo0N6NuR3DwlhWkP/7c7w==";
};# cat /etc/named.rfc1912.zones #在主DNS上面的设置
zone "51niux.in" IN {
...
allow-transfer { key 51niux.in; }; //这句话辅DNS上面不用加，这句话的意思是只有配置文件里面也有这个key的机器才有资格同步数据，如果你再加个IP列表，就是或的关系了。
...
};# cat /etc/named.conf #在辅助DNS服务器上面还要加上下面一句话
server 192.168.1.101 { keys 51niux.in; }; //带着51niux.in的key与主机192.168.1.101发起通信，请求进行签名认证操作测试一下查看下是日志
# tail -f /var/named/log/named.run #主DNS192.168.1.101上面的日志消息
client 192.168.1.104#25636 (51niux.in): query: 51niux.in IN SOA -T (192.168.1.101) //如果辅DNS不加key就同步不了 client 192.168.1.104#25636 (51niux.in): query: 51niux.in IN AXFR -T (192.168.1.101) client 192.168.1.104#25636 (51niux.in): zone transfer '51niux.in/AXFR/IN' denied client 192.168.1.104#13695/key 51niux.in (51niux.in): query: 51niux.in IN SOA -SE (192.168.1.101) //104加了key通过了数据同步 client 192.168.1.104#59551/key 51niux.in (51niux.in): query: 51niux.in IN IXFR -ST (192.168.1.101) client 192.168.1.103#45244 (51niux.in): query: 51niux.in IN SOA -E (192.168.1.101) //103没做配置所以失败了 client 192.168.1.103#47414 (51niux.in): query: 51niux.in IN AXFR -T (192.168.1.101) client 192.168.1.103#47414 (51niux.in): zone transfer '51niux.in/AXFR/IN' denied
# tail -f /var/named/log/named.run #这是192.168.1.104上面的日志消息
client 192.168.1.101#31168: received notify for zone '51niux.in' zone 51niux.in/IN: Transfer started. transfer of '51niux.in/IN' from 192.168.1.101#53: connected using 192.168.1.104#59551 zone 51niux.in/IN: transferred serial 2017060720: TSIG '51niux.in' //TSIG签名，51niux.in是名字 transfer of '51niux.in/IN' from 192.168.1.101#53: Transfer completed: 1 messages, 24 records, 635 bytes, 0.001 secs (635000 bytes/sec) //传输成功了 zone 51niux.in/IN: sending notifies (serial 2017060720)
#在这个例子中，key语句的参数51niux.in 实际上是密钥的名称，尽管它看上去像一个域名。TSIG的RFC建议你在两台主机使用秘钥后，对密钥命名。密钥的名字在事务处理双方的一致性是非常重要的。如果不一致，该接收者将试图验证TSIG记录，并且发现自己不知道TSIG记录所声明的用于计算散列值的密钥，这就会导致错误。
#配置的关键是server语句的keys子语句，keys子语句告诉名字服务器对发送给特定远程名字服务器的查询和区传送请求进行签名。
六、zone语句记录（内容来源于网络）
6.1 zone语句定义和使用
Zone语句的定义和使用：
zone zone_name [class] [{
type ( master | slave | hint | stub | forward ) ;
[ allow-notify { address_match_list } ; ]
[ allow-query { address_match_list } ; ]
[ allow-transfer { address_match_list } ; ]
[ allow-update { address_match_list } ; ]
[ update-policy { update_policy_rule [...] } ; ]
[ allow-update-forwarding { address_match_list } ; ]
[ alsonotify
{ ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
[ check-names (warn|fail|ignore) ; ]
[ dialup dialup_option ; ]
[ file string ; ]
[ forward (only|first) ; ]
[ forwarders
{ ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
[ ixfr-base string ; ]
[ ixfr-tmp-file string ; ]
[ maintain-ixfr-base yes_or_no ; ]
[ masters [port ip_port] { ip_addr [port ip_port] [key key]; [...] } ; ]
[ max-ixfr-log-size number ; ]
[ max-transfer-idle-in number ; ]
[ max-transfer-idle-out number ; ]
[ max-transfer-time-in number ; ]
[ max-transfer-time-out number ; ]
[ notify yes_or_no | explicit ; ]
[ pubkey number number number string ; ]
[ transfer-source (ip4_addr | *) [port ip_port] ; ]
[ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ notify-source (ip4_addr | *) [port ip_port] ; ]
[ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ zone-statistics yes_or_no ; ]
[ sig-validity-interval number ; ]
[ database string ; ]
[ min-refresh-time number ; ]
[ max-refresh-time number ; ]
[ min-retry-time number ; ]
[ max-retry-time number ; ]
}];
6.2 自语句及参数解释
A. 域文件类型
master
服务器有一个主域（控制域或主域）的配置文件拷贝，能够为之提供授权解析服务。
slave
辅域（也可以叫次级域）是主域的复制。主域名服务器定义了一个辅域或多个辅域(次级域联系以更新域拷贝)的IP地址.默认下，传输是从服务器上的53端口进行的；对所有的服务器来说这是可变的，通过设定一个在IP地址表前或者在IP地址之后基于每个服务器设定端口数字。对主域名服务器的鉴别也能通过每个服务器上的TSIG键来完成。如果文件被指定了，那么任何主域配置信息改变的时候就要复制文件，并且当辅服务器重新启动的时候都会从主域名服务器上重新下载文件。这可能会导致带宽的浪费和服务器重新启动次数的增加。
注意对每个服务器的数量众多的域来说(数万或者数十万)，最好使用两级方式命名配置。
例如：一个域的服务器example.com可能把域内容放到一个叫做ex/example.com的文件中，在此, ex/只是域名前两个字符(如果把100K 的文件放入一个单独的目录中，大多数操作系统都会反应缓慢)
stub
子根域与辅域类似,子域只复制主域的NS记录而不是整个域。根域不是DNS的一个标准部分，它们是BIND运行的特有性质。
根域可以用来避免在本机重新获得该域的NS记录，代价是保存一个根域入口和一组named.conf名称服务器地址。这个用法在新设置中并不建议使用，BIND9只在有限的情况下才支持它。在BIND4/8中当前的域传输包括来自当前域的子根的NS记录。这表明，在某些情况下，用户可以为当前域设置只存在于控制服务器里的子根。BIND9服务器从不以这种方式把来自不同域的数据混合。这样的话，如果一个BIND9控制服务器服务于一个已经设定了子根域的母域，所有的当前域的次级服务器都需要设定相同的子根域。子根域也可以用来作为一种促使一个特定域的解答使用一个授权服务器的特定系。例如,在一个使用RFC2157 地址的私有网络上缓存域名服务器可以用子根域进行设置。
forward
一个”转发域”是一种在每个域基础上进行配置转发的一种方式。forward 类型的域语句包括一个转发语句和转发列表，都应用于在域内的由域名给出的查询。如果当前没有转发器语句，就会给出空列表，在域中就不会转发，也就取消了所有在选项中的转发的作用。如果你要使用此种域来改变整体转发选项的状态(”forward first”，”forward only”但是要用同一服务器作为是全局设置)你需要理解全局转发器的特点。
hint
根名称服务器在最初设置时指定使用一个”hint zone”。当配置了”hint zone”的服务器
启动的时候，它使用根线索的设置找到根的名称服务器并得到根名称服务器的最新表。
如果没有为IN类设定线索域，服务器使用一个compiled-in的默认根服务器列表。
B. 类
域名后面的选项可以对应类。如果没有指定类，系统假定为IN类。这在大多数的情况下都是正确的。
Hesiod类是以一个信息服务的名称命名的，信息服务源于MIT的Athena工程.。Hesiod类是用来在多系统数据之间共享信息，如用户、组、打印机等等。”HS”对Hesiod来说是相同的类。
MIT发展的另一个是CHAOSnet，一个在70年代中期创立的本地协议。它的域数据可以用CHAOS类设定。
C. zone 选项
allow-notify
allow-query
allow-transfer
allow-update
设定哪台主机允许为主域名服务器提交动态DNS更新。默认为拒绝任何主机进行更新。
update-policy
设定一个”简单安全更新政策”。
allow-update-forwarding
设定哪个主机能够向辅域名服务器的次级域提交动态域名服务器更新。默认值为{ none; }，意味着不能进行动态更新转发。要使用更新转发，设定allow-update-forwarding{ any; }；设定其他值而不是{ none; } 或者{ any; } 是常常起反作用的，因为主域名服务器拥有接入控制的权利，而辅域名服务器没有。
注意到激活一台次级服务器上的更新转发性质可能使主域名服务器依赖基于不安全IP地址的接入控制而可能使之受到攻击。
also-notify
只当本域notify被激活时才是有意义的。能够收到本域DNS NOTIFY信息的计算机的集合是由所有域中列明的名称服务器加上任何由also-notify设定的IP地址。一个端口可能用每个also-notify地址设定以发送通告信息到那个端口而不是默认的53端口。
also-notify 对根域是无意义的。默认值为空。
check-names
此选项应用于BIND8中以约束hosts文件中的域名的字符集和/或从网络上接收的DNS响应。BIND9不限制域名的字符集也不执行check-names选项。
database
设定储存域数据的数据库的类型。Database后面的关键词是一列whitespace-delimited(非限制空白空间)词。第一个词定义数据库类型，后续词作为数据库的参数传给数据库，解释为特殊的数据库类型。默认值为"rbt",BIND9的本地native in-memory red-black-tree 库，则此数据库没有参数如果其它数据库驱动连接到服务器上的话其他值也是可能的。这些可能的数据库包括分布式的数据库，但缺省是没有连接的。
dialup
forward
只当域有一个转发器列表的时候才是有意义的。当配置为”only”时，在转发查询失败和得不到结果时会导致查询失败；在配置为”first”时，则在转发查询失败或没有查到结果时，会在本地发起正常查询。
forwarders
用来代替全局的转发器列表。如果如故不在forward类型的域中设定，就不会有这个域查询的被转发；全局的转发设置则没有起作用。
ixfr-base
在BIND8中设定动态更新和IXFR的交易日志文件（journal）的名称。BIND9 忽略这个选项而通过附加".jnl"到域文件名后创建日志文件.
ixfr-tmp-file
BIND8的非正式选项，BIND9忽略
max-transfer-time-in
max-transfer-idle-in
notify
pubkey
在BIND8中，此选项用于为DNSSEC标记域的信号(当它们从磁盘装载的时候)的验证设定一个公共域密钥，BIND9不在装载的时候验证密钥并忽略此选项。
zone-statistics
如果设为”yes”，服务器将会为本域储存统计信息，可以存储到在服务器选项中定义的统计文件中。
sig-validity-interval
transfer-source
transfer-source-v6
notify-source
notify-source-v6
min-refresh-time
max-refresh-time
min-retry-time
max-retry-time
D. 动态更新政策
BIND9支持两个授予用户对一个域执行动态更新权限的备选方案，分别由allow-update和update-policy设定。
allow-update 的使用与以前的BIND版本相同。它授于指定用户对域中的任何名称的任何的记录更新的权利。
update-policy 是BIND9中新出现的，允许更多更新控制，定义了一个规则集，规则授予或者取消一个或多个名称被一个或多个用户更新的权利。如果动态更新要求信息被标记(也就是说,可以包含TSIG 或SIG(0)记录)，标记人的身份就能被确定。
规则在update-policy 域选项中指定，并只对主域有意义。当update-policy语句出现，这是一个allow-update的配置错误.。update-policy语句只检查信息的签名人，与源地址是不相关的。
这是一则规则的定义：
( grant | deny ) identity nametype name [ types ]
每条规则赋予或者取消授权，一旦一条信息成功的匹配一个规则，则马上执行该规则的给予或者取消操作，并且不检查其它的规则。一个规则是匹配的，就是当标记人匹配身份字段，名称匹配名称字段并且类型是在类型字段中定义的时候。
身份字段定义一个名称或者一个通配符名称，名称类型字段有四个值：
name, subdomain, wildcard 和self
name
当更新名称与原定义的名称字段相同时匹配。
subdomain
当更新名称与原定义的子域的一个名称字段相同时匹配。(包含它本身的名字)
wildcard
当更新名称与原定义的一个位于名称字段中的统配符名称的有效延伸相同时匹配
self
当更新名称与信息标记人的名称相同时匹配。忽略名称字段。
如果没有设定任何类型，规则匹配所有类型除了SIG、NS、SOA 和NXT；类型可能用
名称设定，包括"ANY"。(ANY 匹配所有类型除了NXT，NXT 不能被更新)。
