在Linux環境下，也提供了廣泛流行的BIND服務器，它是構建DNS服務器最常用的服務器軟件。介紹BIND的安裝的文章現在很多，現在我們就一起來談一下維護的話題。我們如何才能夠了解DNS服務器的運行情況下呢，它忙不忙、負載大不大？這一切，對於系統管理員而言，是比較重要的。 想了解DNS服務器的運行狀況，可以通過查看DNS服務器在運行時所產生的日志文件來實現。 BIND 8提供了一些控制日志系統的手段，不過呢，缺省狀態所生成的日志已經夠用了，通過這些日志信息，足以了解DNS服務器現在的運行狀況了。 在缺省情況下，BIND是通過syslog來生成日志的，存放在/var/log/message文件中。注：與之相關的還有以下四個文件： /var/log/message.1 /var/log/message.2 /var/log/message.3 /var/log/message.4 其實是將日志分為了5個文件來存儲，防止文件過大，當message文件夠大後，就變成了message.1，原來的message.1就成了message.2……，message.4的內容就消失了。 由於這個文件中的日志信息是syslog生成的，所以不並是全都是關於BIND的日志信息。我們執行以下命令，將所有BIND的日志信息挑選出來： more /var/log/messagegrep named >/tmp/named.log 注：BIND服務器的進程名是named。 這樣，/var/log/message中與BIND相關的日志信息都會寫入/tmp/named.log文件中了。最主要的日志有兩種：LOG_NOTICE，LOG_INFO級的日志。 一、 LOG_NOTICE級日志 1.每次啟動BIND服務器named時，會生成一個如下所示的LOG_NOTICE級日志信息： Nov 28 10:37:45 www named[10134]: starting. named 8.2.2-P3 其中: Nov 28 10:37:45 表示服務器啟動時間 www 顯示DNS服務器所在機器名 named[10134]： 顯示DNS服務器進程名與進程ID starting. 表示正在啟動DNS服務器 named 8.2.2-p3 顯示BIND軟件版本 2.當給DNS服務器發送一個HUP信號，使DNS服務器重啟時，會生成一個如下所示的LOG_NOTICE級日志信息： Nov 28 10:37:45 www named[10134]: reloading nameserver 其中: Nov 28 10:37:45 表示服務器重啟動時間 www 顯示DNS服務器所在機器名 named[10134]： 顯示DNS服務器進程名與進程ID reloading. 表示正在重新啟動DNS服務器 nameserver 顯示正在重啟的服務器名 二、LOG_INFO級日志 在DNS服務器運行時，每隔一小時會生成一組如下所示的LOG_INFO級日志信息，反饋DNS服務器的運行狀態： Dec 26 10:23:52 www named[1033]: Cleaned cache of 26 RRset Dec 26 10:23:52 www named[1033]: USAGE 977797432 976760631 CPU=6.55u/6.24s CHILD CPU=0u/0s Dec 26 10:23:52 www named[1033]: NSTATS 977797432 976760631 0=2 A=13192 CNAME=321 PTR=11204 MX=1173 TXT=4 AAAA=32 ANY=4956 Dec 26 10:23:52 www named[1033]: XSTATS 977797432 976760631 RR=7629 RNXD=1368 RFwdR=4836 RDupR=51 RFail=159 RFErr=0 RErr=12 RAXFR=0 RLame=175 ROpts=0 SSysQ=2082 SAns=26234 SFwdQ=4520 SDupQ=1263 SErr=0 RQ=30889 RIQ=4 RFwdQ=0 RDupQ=259 RTCP=2 SFwdR=4836 SFail=6 SFErr=0 SNaAns=21753 SNXD=10276 下面我們就逐句解讀一下： 1. Dec 26 10:23:52 www named[1033]: Cleaned cache of 26 RRset 這是每一組日志信息的第一行，表示正在清空Cache。 其中： Dec 26 10:23:52 表示日志生成時間 www 顯示DNS服務器所在機器名 named[1033]： 顯示DNS服務器進程名與進程ID Cleaned cache of 26 RRset 表示正在清除cache 2. Dec 26 10:23:52 www named[1033]: USAGE 977797432 976760631 CPU=6.55u /6.24s CHILD CPU=0u/0s 這一行是USAGE行，用於統計DNS服務器占用的CPU時間。 其中： Dec 26 10:23:52 表示日志生成時間 www 顯示DNS服務器所在機器名 named[1033]： 顯示DNS服務器進程名與進程ID USAGE 行標記 977797432 976760631 977797432-976760631的值就是DNS服務器運行的總秒數 CPU=6.55u/6.24s 代表DNS服務器使用了用戶態6.55秒，系統態6.24秒（u代表user， s代表system）， CHILD CPU 代表DNS服務器子進程的CPU占用情況。 3. Dec 26 10:23:52 www named[1033]: NSTATS 977797432 976760631 0=2 A=13192 CNAME=321 PTR=11204 MX=1173 TXT=4 AAAA=32 ANY=4956 這一行是NSTATS行，用於統計接收到的查詢總數 其中： Dec 26 10:23:52 表示日志生成時間 www 顯示DNS服務器所在機器名 named[1033]： 顯示DNS服務器進程名與進程ID NSTATS 行標記 977797432 976760631 977797432-976760631的值就是DNS服務器運行的總秒數 0=2 代表未知類型的DNS查詢2個 A=13192 代表A類地址查詢13192個（最標准） CNAME=321 代表CNAME類地址查詢321個（一般是有些版本的sendmail使用CNAME程序 規范化郵件地址而發出的，還有就是dig或nslookup發出的） PTR=11204 代表指針查詢11204個（許多軟件通過這種方法來查找IP地址） MX=1173 代表郵件交換器的查詢1173個（是由郵件發送程序發起的） TXT=4 代表應用程序進行的文本查詢共有4個 AAAA=32 代表AAAA類查詢32個 ANY=4956 有些Sendmail使用的地址查詢方式，共4956個 注：還有可能有： NS=xx 代表名字服務器查詢（例如：名字服務器試圖查找根域的服務器） SOA=xx 代表輔助DNS更新 HINFO=xx 主機信息查詢 NSAP=xx 將域名映射成OSI網絡服務訪問點地址 AXFR=xx 輔助DNS的區傳送 這些在本例中並未出現。 4. Dec 26 10:23:52 www named[1033]: XSTATS 977797432 976760631 RR=7629 RNXD=1368 RFwdR=4836 RDupR=51 RFail=159 RFErr=0 RErr=12 RAXFR=0 RLame=175 ROpts=0 SSysQ=2082 SAns=26234 SFwdQ=4520 SDupQ=1263 SErr=0 RQ=30889 RIQ=4 RFwdQ=0 RDupQ=259 RTCP=2 SFwdR=4836 SFail=6 SFErr=0 SNaAns=21753 SNXD=10276 這是XSTATS行，它用於統計其它一些數據。 其中： Dec 26 10:23:52 表示日志生成時間 www 顯示DNS服務器所在機器名 named[1033]： 顯示DNS服務器進程名與進程ID NSTATS 行標記 977797432 976760631 977797432-976760631的值就是DNS服務器運行的總秒數 RR=7629 代表收到其它主機的響應共有7629個（DNS向其它機器或進程發出的查詢得到的響應數、與RQ無關） RNXD=1368 代表收到“沒有這樣的域”回答共有1368個 RFwdR=108 收到對原始查詢的響應為108個 RDupR=51 重復響應51個（當DNS在它懸而未決的查詢列表中，找不到引起該響應的原始查詢時，這個響應就是重復響應） RFail=159 收到SERVFAIL（遠程服務器錯誤）159個 RFErr=0 沒有收到FORMERR（遠程名字服務器認為本地名字服務器的查詢有格式錯誤） Rerr=12 收到除了SERVFAIL、FORMERR以外的錯誤12個 RAXFR=0 共有0次區傳送 RLame=175 收到175個壞授權（意味著有的區被授權給其它名字服務器，而這個名字服務器不是這個區的權威） ROpts=0 共收到帶有IP選項的包的個數為0 SSysQ=2082 共發出系統查詢2082個（系統查詢是由本地名字服務器進行的查詢。大多數都是針對根名字服務器的） SAns=26234 共回答了查詢26234個 SFwdQ=4520 不在這個名字服務器，而轉發共4520個 SDupQ=1263 重復查詢數1263個 SErr=0 發出的非SERVFAIL、FORMERR的錯誤總數 RQ=30889 收到的查詢共有30889個 RIQ=4 收到反向查詢4個（反向查詢是為了將地址映射為名字，現在這個功能被 PTR實現了。較早的nslookup才使用這種查詢） RFwdQ=0 沒有需要進一步處理的查詢 RDupQ=259 重復查詢共有259個 RTCP=2 通過TCP連接收到2個查詢（一般使用UDP） SFwdR=4836 來自其它名字服務器轉發的響應4836個 SFail=6 發出被認為SERVFAIL響應共6個 SFErr=0 發出的被認為FORMERR的響應個數 SNaAns=21753 非權威回答共21753 SNXD=10276 發出沒有這個域回答10276個 這些統計數據都是從DNS開啟後到現在的總統計，而非本小時內的統計數字。如何衡量DNS服務器的負載呢？很簡單，將總查詢數除以DNS運行的總時間，不就知道了嗎？在本例中：DNS服務器已運行了： 977797432-976760631=1036801秒=288小時 注：從第2、3、4行都可以得到 而總查詢請求有： 2+13192+321+11204+1173+4+32+4956=20884次 注：從第2行都可以得到,也就是每小時107次查詢請求，每秒不到2次，可見負載還是比較小的。
