調整與設定正解/反解、Zone Transfer運作
中小企業DNS Server實戰應用(下)

2008-11-25
本文上集介紹過如何架設Caching-only DNS Server、使用DNS客戶端工具、架設內部專用的DNS Server(正向解析)。中集則介紹架設內部專用的反解DNS Server、DNS Server與DHCP整合應用(Dynamic DNS)。而本次下集將介紹架設DNS Slave Server(包括正解、反解)、Zone Transfer運作以及相關調整與設定。
若以先前架好的DNS Server來說,在人數與主機數量都不多的中小企業環境內以這樣的主機提供服務就游刃有餘了。依照以往的經驗來看,Linux DNS Server鮮少發生當機或軟體故障的情況,比較要擔心的,反而是來自於硬體故障所造成的服務停擺,幸好DNS通訊本身就具備良好的備援機制,允許同時架設多台(通常是兩台)Server提供客戶端主機DNS查詢的需求,來達成兩台DNS Server相互備援的功能。  

架設兩台DNS Server之後,如果每一Zone都設定成Master的話,更改紀錄時就必須一台一台修改,比較麻煩,所以通常建議配置成Master/Slave架構,架構完成以後只要更改Master的紀錄就可以了,此時Slave也會自動更新紀錄,管理也比較方便。談到兩台之間Record資料傳輸與同步的方式,是使用Zone Transfer來達成,接下來就以「架設Slave Server」順便了解Zone Transfer的運作方式。  

架設正向解析Slave Server  

先準備一台Slave Server,然後筆者將在這台主機上解說,並測試Zone Transfer。Zone Transfer的動作主要是將某個Zone的所有Record(紀錄)一次都抓回來,這裡測試的方法是在Slave主機使用指令「host -l ol 172.18.0.35」來向Master主機172.18.0.35做ol網域的Zone Transfer動作。此次Zone Transfer並未成功,原因是Master主機的「TCP 53埠」尚未開啟。如果不太瞭解,直接執行「host」指令,可以找到簡單的說明。

由於會用到Zone Transfer功能,所以在Master主機執行「system-config-securitylevel」指令開啟TCP 53埠。須留意的是,Zone Transfer使用的埠號是53,且採用TCP通訊,與一般查詢時使用的53埠UDP通訊方式不同。

回到Slave主機再次測試,一切就正常了,資料顯示如下圖所示。其實,也可以使用dig配合AXFR這種type來測試,例如執行指令「dig ol axfr @172.18.0.35」。

請注意,如果DNS Server沒有特別調整過,預設值是「允許任何主機來做Zone Transfer」,這樣一來所有的Record就會被有心人士探查到,是不安全的做法。等到Master/Slave Server都設定得差不多了之後,再來探討Zone Transfer的安全性。  

新增ol網域且角色為Slave  

確定Slave主機可以Zone Transfer Master主機ol網域資料之後,就可以開始在Slave主機上新增ol網域且角色為Slave的設定。

NOTE
Slave主機同樣也要安裝Bind軟體,如同本文上集所介紹,在調整yum正常之後,執行「yum install bind」指令即可。

在Slave主機開啟「/etc/named.conf」模仿Master主機的設定,修改後的檔案內容如下:

以上「zone "ol"」這一大段是用來新增ol網域這次的角色為Slave(檔案內容中設定成「type slave」)。而options區段內,directory設定成「/var/named」,所以之後提到的file(record檔案)皆放置在「/var/named/」目錄下,所以「file "slaves/ol.bak"」就是放在「/var/named/slaves/ol.bak」這個位置。  

該次設定有幾項特點,分述如下:
●這次是當slave,也就是「type slave」。
●也就因為設定「type slave」,所以要指明Master主機在哪裡;使用masters參數設定找Master主機(IP為172.18.0.35),例如「masters { 172.18.0.35; };」那一行的設定。
●「file "slaves/ol.bak"」將Zone Transfer回來的資料放在「/var/named/slaves/」目錄下的ol.bak檔案。不直接放在「/var/named/ol.bak」的原因主要是因為權限問題(待會兒再詳述)。  

另外,DDNS是找Master更新即可,所以Slave就可以把allow-update那行設定註解起來(關於DDNS請參考本文中集)。寫好了之後,執行指令「/etc/init.d/named restart」重新啟動named,將從Master主機Zone Transfer有關ol網域的資料,然後寫入「/var/named/slaves/ol.bak」檔案中。第一次重啟named會出現的FAILED訊息,並不影響設定。記得使用指令「chkconfig named on」設定下次開機自動啟動named。

Zone Transfer後檔案的寫入權限  

與上一期的DDNS狀況類似,進行DDNS時使用帳號named寫入「/var/named/data/」目錄。而Zone Transfer後的資料,所使用的權限也是named這個帳號,但寫入「/var/named/slaves/」目錄。  

使用指令「ps ax | grep named」可觀察到named執行期間用了「-u named」這個選項,代表使用帳號named存取資料。  

此外,「/var/named/」目錄下有個「slaves/」目錄,權限剛好是named這個帳號可以寫入,所以在「/etc/named.conf」中的「zone "ol"」區段內使用「file "slaves/ol.bak";」,就是將檔案放在能夠擁有讀寫權限的這裡。

假如將上例的「file "slaves/ol.bak";」設定成「file "ol.bak";」(表示檔案「/var/named/ol.bak」在此情況下會寫入失敗),重新啟動named後,使用指令「tail /var/log/messages」觀察「/var/log/messages」的尾端,會有「dumping master file: tmp-ZoXK7PLGoU: open: permission denied」的類似訊息,主要是Zone Transfer回來的資料要寫到ol.bak時,寫入的權限不足所造成。

NOTE
錯誤示範的測試練習完成後,記得要改回來原本正確的,並且重啟named使之生效。

Slave主機Firewall設定  

Slave主機只要能夠被DNS一般查詢即可,並不需要提供Zone Transfer功能,意味著只需要開啟UDP 53埠,至於TCP 53埠(主要用在Zone Transfer),除非特殊需要,否則應該不必開啟。

TIPS
「system-config-securitylevel」指令可輕鬆調整Slave主機開啟UDP 53埠,是類似Master主機開啟TCP 53埠的方式,故不再贅述。

測試Slave主機ol網域的紀錄  

Slave主機在Firewall設定完成後,使用其他台Client主機以dig指令測試一下,應該沒有甚麼問題,例如執行指令「dig @172.18.0.191 ns1.ol」是向Slave主機(IP為172.18.0.191)詢問ns1.ol的紀錄,依下圖來看,結果是有紀錄(會跟Master主機的資料一樣)。

新增Slave主機後的注意事項  

在完成「架設正解Slave Server」之後,此時Slave知道Master的主機資訊(主機名稱為ns1.ol,IP是172.18.0.35),但是Master還不曉得Slave的主機資訊(主機名稱為ns2.ol,使用IP是172.18.0.191),這時候要到Master主機加上兩筆紀錄:一筆是「Slave主機是Name Server紀錄」,另一筆為「Slave主機的A紀錄」。  

在新增紀錄的期間,因為先前使用DDNS(動態DNS)的關係觸動了SELinux,顧及主機安全的保護機制,在此順道說明。  

使用DDNS時,新增紀錄注意事項  

在本文中集時提到,使用DDNS時會產生結尾為.jnl的檔案(journal),也就是「日誌」檔案,也因為這個日誌檔案的關係,使得要修改紀錄的時候,必須先停止named的運作(讓jnl同步回原來的檔案),再更改原來檔案的紀錄內容,修改之後於named啟動前,記得要把jnl檔案砍掉,運作才會比較正常。  

經由動態更新後的ol網域,其SOA序號會比原先紀錄檔案內的序號大。可以利用指令「dig ol soa」來觀察當時SOA紀錄的序號比原先在ol.db檔案內的序號大。如下圖所示,2008081512大於2008081511。

例如,要在Master主機修改ol網域紀錄資料時,要先使用指令「/etc/init.d/named stop」讓named停止運作,這時候在jnl的最新資料,就會回寫到紀錄檔案。原以為事情就這樣搞定,但卻被SELinux阻擋住而回寫失敗。  

處理SELinux阻擋回寫的動作  

jnl檔案回寫失敗後,會在相同目錄下(「/var/named/data/」)產生tmp-XXXXXXXXXX檔案,觀察ol.db檔案SOA紀錄的序號,會發現這依然是舊的檔案(還是2008081511)。

執行指令「tail /var/log/messages」觀察「/var/log/messages」的尾端,會看到因權限不足所造成的寫入失敗訊息「dumping master file: rename: data/ol.db: permission denied」,以及SELinux阻擋的相關資訊與因應之道「For complete SELinux messages. run sealert -l 10f19abd-f4ba-4a6a-9b0c-473d9fd3cf4e」。

接著照SELinux指示的,執行指令「sealert -l 10f19abd-f4ba-4a6a-9b0c-473d9fd3cf4e」,其中會看到使用setsebool相關的一行指令「setsebool -P named_disable_trans=1」,用來關閉SELinux針對named服務的保護,就會允許named的jnl檔案回寫紀錄檔案。

執行指令「setsebool -P named_disable_trans=1」,並在重新啟動named(兩次)之前與之後,觀察「/var/named/data/」目錄下的檔案security context與檔案權限,應該都能夠讓named正常讀寫(tmp-XXXXXXXXXX也可以清掉)。

NOTE
檔案的security context調整正確後,其實就可以將「setsebool -P named_disable_trans=0」調整回預設值有保護的狀態。

本文所介紹的DDNS,建議使用在信任的內部網路區域內,若應用在Internet,就顯得不夠安全。若要提供較安全的Internet DDNS服務,可以考慮採用DDNS,本身有較安全的機制,這機制促使客戶端更新DDNS資料時需要key與密碼,甚至可搭配key利用named.conf中update-policy參數,限定用哪個key才能update哪些資料,達到既方便又安全的動態DNS服務。

TIPS
也可以自行設計Web-Based畫面做出帳號密碼驗證的機制,讓使用者欲修改的紀錄資料先寫到資料庫去,再依照資料庫的內容更新DDNS資料。

Master主機增加兩筆關於「Slave主機是Name Server」的紀錄

了解DDNS與SELinux所造成的一些狀況和處理方法之後,接下來在Master主機新增NS紀錄指向到ns2.ol、ns2.ol的A紀錄指向到Slave主機的IP 172.18.0.191,完成後,Slave主機就叫做ns2.ol。

首先使用指令「/etc/init.d/named stop」,將named停掉(因為DDNS jnl的關係,改紀錄前要停named)。  

接著,編寫紀錄檔案「/var/named/data/ol.db」加上「NS ns2.ol.」和「ns2 A 172.18.0.191」,一筆是ns2.ol主機正式加入NS(Name Server行列,另一筆是Slave主機命名ns2.ol的A紀錄指向IP 172.18.0.191。加上的這兩筆ns2相關紀錄時,請模仿ns1的那兩筆紀錄來新增。請注意範例中NS紀錄要加在$ORIGIN .區段ol SOA紀錄下方、A紀錄則是加在$ORIGIN ol.區段。  

另外,紀錄檔案的SOA序號2008081512記得至少要加1,例如增加成2008081513。重啟named之前,記得執行指令「rm /var/named/data/ol.db.jnl」砍掉jnl檔案。  

修改完成之後,使用指令「/etc/init.d/named start」啟動named,並測試新增的紀錄是否正常。

如果忘記砍掉jnl檔案就啟動named的話,在「/var/log/messages」尾段將會出現「zone ol/IN: journal rollforward failed: journal out of sync with zone」錯誤訊息,可能會出現讓整個zone資訊都變得查不到的怪現象。

有關SOA紀錄序號增加的動作  

剛才加上兩筆紀錄重新啟動named後,Master主機會「notify」(通知)ns2.ol主機來做紀錄資料的更新。在Master主機序號大於Slave主機的情況下,Slave紀錄資料就會更新,更新成功後兩台的序號就會相同,例如2008081513。  

使用nsupdate指令更改DDNS紀錄  

使用編輯紀錄檔的方式更改DNS紀錄,較適用於沒有DDNS情況下。在有DDNS的情形下,要先停用named,改完後還要砍掉jnl檔案再啟動named,著實麻煩。其實,也可以應用動態更新的指令「nsupdate」增減DDNS紀錄。  

接著,就以新增ol網域一個名為test的A紀錄指向IP 172.18.0.103來做介紹:  

在Master主機使用指令「nsupdate」進入nsupdate運作模式下,接著輸入「server 127.0.0.1」,意思是要向主機127.0.0.1要求資料更新,因前一集已設定過「allow-update { localhost; };」,所以會被允許。然後輸入「zone ol」,表示要更新ol網域。緊接著,輸入「update add test.ol 21600 A 172.18.0.103」新增test.ol其TTL為21600的A紀錄指向172.18.0.103,之後執行「send」送出。最後,鍵入「quit」指令結束,離開nsupdate模式。

TIPS
如果不是新增紀錄而是要刪除紀錄,將「add」改成「delete」即可。

架設反解Slave Server  

正解Slave Server完成後,接著順道處理反解的部分。  

測試反解Zone Transfer  

已經有先前打好的基礎觀念,測試反解Zone Transfer,應該就易如反掌。執行指令「host -l 18.172.in-addr.arpa 172.18.0.35」,針對主機172.18.0.35(也就是Master)做172.18.Y.Z網域反解Zone Transfer,正常訊息如下圖。

TIPS
使用dig指令也可以達到同樣的效果,例如「dig -x 172.18 axfr@172.18.0.35」。

新增172.18.Y.Z反解網域且角色為slave  

在Slave主機開啟「/etc/named.conf」,參考「Master主機named.conf設定」與「此檔案ol網域slave設定」,增加檔案內容如下:

與正解的ol網域slave設定非常類似,差別只在zone名稱變成「18.172.in-addr.arpa」與file的檔案名稱改成「172.18.bak」(依舊是放在「slaves/」目錄下)。  

寫好之後,接著重啟named,然後觀察是否正確產生檔案172.18.bak,再使用dig指令「dig -x 172.18.0.35 @172.18.0.191」向Slave主機做測試。  

其他小細節  

其實還有兩個小動作尚未完成,說明如下:  

增加反解網域關於ns2.ol的NS與PTR紀錄  

這次直接使用nsupdate指令來增加這兩筆紀錄,取代編輯檔案的方式,順便介紹反解網域的DDNS更新方法如下:  

在Master主機使用指令「nsupdate」進入nsupdate運作模式下,先輸入「server 127.0.0.1」,再執行「zone 18.172.in-addr.arpa」更新172.18.Y.Z反解網域。接著,輸入「update add 18.172.in-addr.arpa 21600 NS ns2.ol」新增反解網域NS紀錄指向到ns2.ol、輸入「update add 191.0.18.172.in-addr.arpa 21600 PTR ns2.ol」新增172.18.0.191反解PTR紀錄指向到ns2.ol。隨後輸入「send」送出,並執行「quit」結束,離開nsupdate模式。

TIPS
nsupdate模式下輸入的內容,可以先儲存成一個文字檔案(例foo.txt) ,再使用「nsupdate foo.txt」執行即可,使用上會比較方便。

另一種不必停止named就可以編輯修改DDNS紀錄檔案的方式,適用於bind 9.3以後的版本,例如可先使用指令「rndc freeze ol」凍結住ol網域。此時變得無法DDNS更新(如下圖的「update failed: REFUSED」訊息),但卻是最適合直接修改紀錄檔案的時候,待更改完成後,再執行指令「rndc unfreeze ol」解凍結即可。

設定「/etc/dhcpd.conf」增加Slave主機當DNS Server  

為了讓內部區域網路使用DHCP的客戶端主機能夠在ns1.ol故障時,名稱解析自動改用ns2.ol這台DNS Server,必須修改DHCP Server發配出去的名稱解析伺服器,將原來只詢問ns1.ol的設定,改成ns1.ol問不到的時候問ns2.ol。  

接下來編輯DHCP Server設定檔案「/etc/dhcpd.conf」,修改內容如下:  

將原來的「option domain-name-servers 172.18.0.35;」這一行,改成這樣「option domain-name-servers 172.18.0.35, 172.18.0.191;」(加上ns2.ol的IP 172.18.0.191)。記得執行指令「/etc/init.d/dhcpd restart」重新啟動dhcpd,使其生效。

結語  

到現在為止,這裡架設的DNS主機都是放在區域網路內,沒有直接對外服務的風險,所以前三篇文章都是以實用性為主,比較沒有顧慮到安全方面的防護,在下一期的文章中,主要就是追加介紹DNS主機安全相關的常見調整設定實戰應用。  

作者註:
前期(本刊第33期「中小企業DNS Server實戰應用(中)」一文,第97頁中提到在do與done之間的$i會取值(對應到for i in的「i」)成為20 21 22等等(一共執行四十次),「>>」意思是會補(Append)在「/var/named/ol.db」檔案的尾端。應為共執行二十次,僅此更正。)


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!