构建企业级DNS系统（五）bind9日志记录

BIND支持丰富的日志记录，并且支持将日志信息写入文件和发送到syslog中。

1. BIND日志记录的重要的概念。

• 通道channel
  用于指定日志数据的流向，如syslog、文件
• 类别categories
  用于指定记录哪些日志，如查询日志queries、动态更新日志update、解析器的递归查询处理日志resolver等。

每个类别的日志数据可以指定发送到一个或者多个不同的通道channels中。
通道允许根据日志消息的严重级别来过滤输出指定级别的日志，安装严重性递减的顺序排列是critical–>error–>warning–>notice–>info–>debug [level]–>dynamic
前面5个就是syslog所使用的严重级别，后面两个是BIND特有的。
debug日志可以指定级别，如果不指定则默认BIND会认为是1级。默认的严重级别是info，这意味着如果要看调试日志则必须修改严重级别。
2. BIND日志实战举例。
下面我们通过一个简单的例子，也是DNS实际生产环境中最通用的配置举例来说明bind日志的使用方法。
在named.conf中使用logging语句配置如下：

logging {
        channel query_log {
                file "/usr/local/bind/log/query.log." versions 5 size 50m;
                print-time yes;
                severity info;
        };
        category queries { query_log;};
        channel general_log {
                file "/usr/local/bind/log/general.log." versions 5 size 50m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        category default   { general_log; };
        category general   { general_log; };
};

• 配置文件中通过channel定义了2个日志，日志数据流向均是服务器本地的文件中，通过file自语句来指定。channel的名称是根据情况自己定义。
• query_log这个channel中通过category语句指定了日志的类别是queries即查询日志，而general_log这个channel通过category语句指定了default和general两种类别的日志均输入到这个channel中。通过category设置类别的语法可见，如果需要多个类别那么则写多个即可，类别后面的花括号指定这类日志归属那个channel。
• print-time代表在日志数据中打印时间戳信息，通常如果日志流向syslog则不需要这个设置，因为syslog有也记录日期和时间。
• print-category代表日志数据中打印类别的名称。
• print-severity yes代表日志数据中打印级别。
• severity 日志级别。
• version选项用于指定文件保存多少备份版本（几个文件回滚），如果设置为unlimited则代表没有限制，此时bind将保留99个版本文件。如设置为3，那么BIND将保留file、file0、file1、file2共4个文件，每次文件的轮转顺序是把file1改为file2，把file0改为file1把file改为file0，然后新建一个file。
• size选项用于限制日志文件的增长，K代表kilobytes、M代表megabytes、G代表gigabytes。

常用的日志类别说明如下：

类别名称	类别描述
default	匹配所有未明确分配通道的类别，bind9的default不匹配未分类的BIND消息
general	所有未明确分类的BIND消息
config	配置文件的分析与处理
client	对客户端请求的处理
network	网络操作
notify	异步区域变更通知
queries	查询日志
update	动态更新日志
query-errors	关于域名请求失败的消息
resolver	递归查询处理
xfer-in	服务器接受区传送消息
xfer-out	服务器发出的区传送消息
dnssec	DNSSEC和TSIG协议处理消息

本例中query.log.打印的查询日志内容如下：

17-Jun-2020 21:25:16.607 client @0x7fef2c005670 192.168.3.1#49839 (www.example.com): query: www.example.com IN A + (192.168.3.160)
17-Jun-2020 21:25:23.172 client @0x7fef2800eef0 192.168.3.1#49862 (www.test.com): query: www.test.com IN A + (192.168.3.160)
17-Jun-2020 21:25:25.109 client @0x7fef2800eef0 192.168.3.1#49863 (www.test.com): query: www.test.com IN A + (192.168.3.160)
17-Jun-2020 21:25:26.211 client @0x7fef2800eef0 192.168.3.1#49864 (www.test.com): query: www.test.com IN A + (192.168.3.160)
17-Jun-2020 21:25:26.701 client @0x7fef2800eef0 192.168.3.1#49865 (www.test.com): query: www.test.com IN A + (192.168.3.160)
17-Jun-2020 21:30:32.277 client @0x7fef2c005670 192.168.3.1#56935 (www.test.com): query: www.test.com IN A - (192.168.3.160)
17-Jun-2020 21:30:33.639 client @0x7fef2800eef0 192.168.3.1#51568 (www.test.com): query: www.test.com IN A - (192.168.3.160)

• 上面的192.168.3.1是客户端的IP地址，后面#号后的数字是查询源端口号。
• A代表请求类型是A记录
• +号代表查询类似是期望递归，如果是-号则是不期望递归也就是收到迭代查询请求。

本例中general.log.的日志内容如下：

18-Jun-2020 00:46:44.291 lame-servers: info: network unreachable resolving './DNSKEY/IN': 2001:500:200::b#53
18-Jun-2020 00:46:44.291 lame-servers: info: network unreachable resolving './DNSKEY/IN': 2001:503:ba3e::2:30#53
18-Jun-2020 00:46:44.292 dnssec: info: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
18-Jun-2020 00:46:44.488 resolver: info: resolver priming query complete
18-Jun-2020 00:47:37.013 network: info: no longer listening on 127.0.0.1#53
18-Jun-2020 00:47:37.014 network: info: no longer listening on 192.168.3.160#53
18-Jun-2020 00:47:37.017 network: info: no longer listening on ::1#53
18-Jun-2020 00:47:37.017 network: info: no longer listening on fe80::9963:d89b:85c6:928b%2#53
18-Jun-2020 00:47:37.020 general: info: shutting down
18-Jun-2020 00:47:37.020 general: notice: stopping command channel on 127.0.0.1#953
18-Jun-2020 00:47:37.023 general: notice: exiting
18-Jun-2020 00:47:40.064 zoneload: info: managed-keys-zone: loaded serial 20
18-Jun-2020 00:47:40.067 zoneload: info: zone test.com/IN: loaded serial 1
18-Jun-2020 00:47:40.067 general: notice: all zones loaded
18-Jun-2020 00:47:40.069 general: notice: running
18-Jun-2020 00:47:40.079 notify: info: zone test.com/IN: sending notifies (serial 1)
18-Jun-2020 00:47:40.566 resolver: info: resolver priming query complete

3. BIND日志实战经验

• 开启日志必然带来bind性能的下降，尤其是在较高的业务量下大量的日志会导致解析时延的抖动。
• bind日志无法查看域名解析的结果，例如解析到的IP地址等信息，如果需要则需要进行二次开发。
• general日志其实包含了大量的信息，当出现域名解析异常及各种失败的情况下一定要习惯仔细的查看此日志。