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日志其實包含了大量的信息，當出現域名解析異常及各種失敗的情況下一定要習慣仔細的查看此日志。

總結

以上是生活随笔為你收集整理的构建企业级DNS系统（五）bind9日志记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。