【51CTO.com獨家特稿】筆者在公司的工作之一是負責維護公司的CDN，基本上是天天打bind打交道；在用源碼安裝完一臺新的bind9.4后準備做主從復制時，驚奇的發現居然出現了問題(主DNS是bind9.1):

這是在從DNS上出現的問題一：

Mar 26 16:04:17 gdst named[18464]: client   
115.207.47.199#20601: view any: query (cache) '112.2.5.221.in-  
addr.arpa/PTR/IN' denied  
Mar 26 16:04:17 gdst named[18464]: client   
115.207.47.199#20602: view any: query (cache)   
'dx.3158.com.domain/A/IN' denied  
Mar 26 16:04:17 gdst named[18464]: client   
115.207.47.199#20603: view any: query (cache)   
'dx.3158.com.domain/AAAA/IN' denied  
Mar 26 16:04:17 gdst named[18464]: client   
115.207.47.199#20604: view any: query (cache) 'y163.net/A/IN'   
denied  
Mar 26 16:04:17 gdst named[18464]: client   
115.207.47.199#20605: view any: query (cache)   
'y163.net/AAAA/IN' denied  
Mar 26 16:04:18 gdst named[18464]: client   
115.207.47.199#20606: view any: query (cache) '112.2.5.221.in-  
addr.arpa/PTR/IN' denied  
Mar 26 16:04:18 gdst named[18464]: client   
115.207.47.199#20607: view any: query (cache)   
'dx.3158.com.domain/A/IN' denied  
Mar 26 16:04:18 gdst named[18464]: client   
115.207.47.199#20608: view any: query (cache)   
'dx.3158.com.domain/AAAA/IN' denied  
Mar 26 16:04:18 gdst named[18464]: client   
115.207.47.199#20609: view any: query (cache) 'y163.net/A/IN'   
denied  
Mar 26 16:04:19 gdst named[18464]: client   
115.207.47.199#20610: view any: query (cache)   
'y163.net/AAAA/IN' denied  
Mar 26 16:04:19 gdst named[18464]: client   
115.207.47.199#20611: view any: query (cache) '112.2.5.221.in-  
addr.arpa/PTR/IN' denied  
Mar 26 16:04:19 gdst named[18464]: client   
115.207.47.199#20612: view any: query (cache)   
'dx.3158.com.domain/A/IN' denied  
Mar 26 16:04:19 gdst named[18464]: client   
115.207.47.199#20613: view any: query (cache)   
'dx.3158.com.domain/AAAA/IN' denied  
Mar 26 16:04:19 gdst named[18464]: client   
115.207.47.199#20614: view any: query (cache) 'y163.net/A/IN'   
denied  
Mar 26 16:04:20 gdst named[18464]: client   
115.207.47.199#20615: view any: query (cache)   
'y163.net/AAAA/IN' denied  
Mar 26 16:04:21 gdst named[18464]: client   
60.215.129.103#53455: view any: query (cache)   
'www.google.com/A/IN' denied  
Mar 26 16:04:49 gdst named[18464]: client   
121.14.128.68#53455: view CHINANET: query (cache)   
'www.google.com/A/IN' denied  
Mar 26 16:04:59 gdst named[18464]: client   
221.171.1.147#53455: view CHINANET: query (cache)   
'www.google.com/A/IN' denied  

發現新版的對cache的處理有所改變

新版本的BIND對 allow-query 有著不同的處理，新增加了一個allow-query-cache 的選項。

QUOTE:allow-query Specifies which hosts are allowed to ask   
ordinary DNS questions. allow-query may also  
be specified in the zone statement, in which case it overrides the   
options allow-query statement.  
If not specified, the default is to allow queries from all hosts.  
 
QUOTE:allow-query-cache Specifies which hosts are allowed to   
get answers from the cache. The default is the  
builtin acls localnets and localhost.  
The way to set query access to the cache is now via allow-query-  
cache. This differs from earlier  
versions which used allow-query. 

 BIND 9.4 的手冊上還特別注釋了

QUOTE:allow-query-cache is now used to specify access to the
cache.

解決方法如下：即在從DNS的options里添加一條：

key "rndc-key" {  
       algorithm hmac-md5;  
       secret "Rox3q+3f0gp8MKyQXx2zWw==";  
};  
controls {  
       inet 127.0.0.1 port 953  
            allow { localhost; } keys { "rndc-key"; };  
};  
options {  
version "9.8.12";  
directory "/var/named";  
pid-file "named.pid";  
allow-query { any; }; //此處為添加  
}; 

另一個關于主從復制的問題就是，如果bind采用了智能view功能的話，如果主DNS是電信的IP的話，從DNS非電信線路(即鐵通或其它)，如果均采用單IP是不能進行主從復制的，除非是雙IP；如果只有單IP的話可采取bind的TSIG key來解決此問題。在處理上述問題時，得到了linuxtone站長netseek幫助，這里表示感謝。

維護的DNS服務器主要有三個:一主一從一備，由于公司的架構采用了CDN方案，所以namd.conf針對"okspace.com"的出現位置就有三處:即電信、網通及其它，加上三個服務器，每次手動用vim刪除okspace.com時就必須修改九處，維護起來很麻煩；更為不爽的是，有些zone經常需要刪除，特別的麻煩，所以特地寫了個shell以減清自己的負擔，達到安全刪除的目的。變量domain中的文件內容自己可以定義，簽于生產環境下bind都是源碼安裝，這里就以named.conf文件為主。

vim /root/delzone.sh  
#!/bin/bash  
domain='zone\ "okspace.cn"'   
if [ -e /var/named/chroot/etc/named.conf ];then  
sed -i "/$domain/,/};/d" /var/named/chroot/etc/named.conf  
else   
sed -i "/$domain/,/};/d" /var/named/chroot/var/named/named.rfc1912.zones  
fi 

用sftp將此腳本傳到其它DNS服務器，很輕松的完成工作，用此語法結合grep -rl可寫出更強大的刪除腳本；用shell腳本已經很長時間了，越來越喜歡它。

關于DNS主從復制，這里說明下：

①如果主DNS和從DNS都是用root用戶的，不需要考慮權限問題，即/var/named寫權限不需要更改任何地方，即不需要更改為named或給7權限。

②多使用rndc,這命令強大無比;配置時多用tail -f /var/log/messages，我就是系統日志來排錯的

③如果測試結果中出現Non-authoritative answer: //非授權的回答,說明來自其他DNS服務器或緩存.

④啟動區域傳輸的機制有以下3種:一是輔DNS服務器剛啟動;二是SOA記錄中的刷新間隔到達;三是master DNS設置了主動通知輔DNS數據有變化。監于生產服務器的嚴謹性，如果有問題，麻煩通知下撫琴煮酒——yuhongchun027@163.com，我會***時間改正。

【51CTO獨家特稿，非經授權謝絕轉載，合作媒體轉載請注明原文出處及！】