介紹forwarders、acl與view等設定以及網域名稱購買
中小企業DNS Server安全防護實作

先前的文章介紹是以「先求有、再求好」方式架設「能夠使用、提供功能」的DNS Server為主，至於安全性方面仍待加強，底下就先從zone transfer安全性開始談起。  

限制zone transfer來源主機  

先前已談過預設建置的主機是「允許任何來源主機做zone transfer動作」，這樣會導致任何一台主機都可以將所有紀錄探查出來，感覺較不安全，一般建議設定成「master主機允許slave來做zone transfer」且「slave主機不允許zone transfer」。  

在master主機限制zone transfer來源只能是slave  

要做到這個限制的關鍵參數是「allow-transfer」。編輯master主機named.conf檔案，加入一行「allow-transfer { 172.18.0.191; };」（172.18.0.191是slave主機IP）。  

上述這一行擺放的位置若是在options區段，影響範圍為所有的zone；若只是擺放在某個zone區段，就只有在這個區段內才有效果（例如只放在ol的zone）。下圖是將「allow-transfer { 172.18.0.191; };」這行設定放在options區段的快照。修改好設定檔案之後，記得執行指令「/etc/init.d/named restart」重新啟動named，使其生效。

測試時，分別到slave主機（IP是172.18.0.191）和非slave主機執行指令「dig ol axfr @172.18.0.35」，應該只有slave主機能夠向master主機zone transfer資料，其他非slave主機向master做zone transfer應該會失敗，將如下圖所示出現「Transfer failed.」訊息。

TIPS

查詢反解zone transfer指令也可使用dig，例如「dig -x 172.18 axfr @172.18.0.35」

在slave主機限制不開放zone transfer  

編輯slave主機的named.conf檔案，加入一行「allow-transfer { none; };」設定，此行的設定意思是「任何一台來源主機都不允許zone transfer」。

設定好了之後，同樣必須重新啟動named以及測試能否被zone transfer。如果不行，才是正確的。

NOTE

先前並未在slave主機開啟TCP 53埠，因為被防火牆擋住，所以原本zone transfer就不會成功。

在有防火牆與應用程式的設定檔案雙重保護下，就算是防火牆不小心開放TCP 53埠，還有應用程式這一層保護（依然不允許zone transfer）。  

應用named chroot機制提升安全性  

在執行指令「yum list | grep bind」後，會看到一個名為「bind-chroot」套件，它能夠提升DNS Server的安全性。接著，就使用指令「yum install -y bind」將其安裝起來吧！

觀察安裝bind-chroot後的DNS Server  

使用指令「ps ax | grep named」後，觀察到「/usr/sbin/named -u named -t /var/named/chroot」的重點在於「-t」選項與其後面銜接的「/var/named/chroot」參數。

在這種情況下，實際DNS Server相關設定與資料擺放的位置是在「/var/named/chroot/」目錄下。利用「ls -l」指令可以觀察到原本設定檔案「/etc/named.conf」變成軟連結到「/var/named/chroot/etc/named.conf」。同樣地，利用「ls -l」指令觀察原本的zone紀錄檔案「/var/named/data/ol.db」與「/var/named/data/172.18.db」，則發現它們分別軟連結到「/var/named/chroot/var/named/data/ol.db」和「/var/named/chroot/var/named/data/172.18.db」。

觀察「/var/named/chroot/」目錄，發現裡面有一個精簡的根目錄結構，精簡到只能運行named而已，如下圖所示。

真正的設定檔案和zone紀錄檔案都已經改放在「/var/named/chroot/etc/named.conf」、「/var/named/chroot/var/named/data/{ol.db,172.18.db}」。未來若要修改設定或zone紀錄檔案，建議直接修改「/var/named/chroot/」目錄下的資料。  

有bind-chroot的情況下比較安全，因為named運行期間是chroot到「/var/named/chroot/」目錄下在執行的，所以named就無法存取原先的根目錄，就算是遇到named資訊安全漏洞的問題，被攻擊的範圍比較小，也較不會影響整台Linux運作。

NOTE

筆者建議剛接觸DNS Server的時候，一開始先不要安裝bind-chroot的用意，是讓學習的難度降低，等到學得差不多都懂了，再補裝上去。

關於recursion設定  

本文曾在上集介紹過dns查詢的流程，基本上DNS client端發問的都是recursion查詢，預設的DNS Server也是允許recursion查詢。有些DNS Server可能為了增加安全性而將recursion功能關閉。接下來，說明DNS Server開放recursion查詢與不開放recursion查詢的差異：  

開放recursion與拒絕recursion差異  

在開放recursion查詢的情況下，Client端詢問的所有查詢，不論這個答案是Server自己提供的資訊，或是向別台Server詢問得到的解析，DNS Server都會盡力回答。相反地，在拒絕recursion查詢的情況之下，就只會回答自己管理的zone解析以及根主機資訊兩項。  

開放recursion查詢	不僅回答自己管理的zone解析，還幫忙向其他Server詢問
拒絕recursion查詢	Server僅僅回答自己管理的zone解析以及根主機資訊

舉例來說，向自行架設的DNS Server詢問www2.babyface.com.tw解析，預設為開放recursion查詢，所以就算這個查詢不是自己管理的zone，也會代為詢問出解析，如下圖所示執行指令「dig www2.babyface.com.tw @ns1.ol」。

筆者向Yahoo的DNS Server（ns1.yahoo.com）下達指令「dig www2.babyface.com.tw @ns1.yahoo.com」，此Server就沒有回答www2.babyface.com.tw，應該是對方拒絕recursion查詢的關係。

如果向Yahoo的DNS Server（ns1.yahoo.com）下達指令「dig www.yahoo.com @ns1.yahoo.com」（www.yahoo.com應該是它管理的紀錄），該Server就會回答www.yahoo.com解析。

NOTE

是不是Yahoo DNS Server管理的zone（以及紀錄），可由TTL是否減少而快速探查，或是由仔細查看dig指令回應內容中的「flags:aa」來判斷（先前recursion查詢成功的flags:為ra）

關閉recursion時機  

至於什麼時機會將recursion功能關閉，一是為了讓DNS Server更加地安全，只回應需要回答的查詢；另一個考量的原因是，避免浪費無謂的頻寬去回答不一定需要回應的查詢。  

通常建議開放recursion給信任的client端，對其他client端則可以關閉recursion查詢功能。信任的client端通常是內部主機，而對於ISP業者來說，指的則是它的客戶。  

設定開啟或不開啟recursion  

設定開啟或不開啟recursion，可以透過「allow-recursion」（類似allow-transfer格式）或「recursion yes」（或是no）來進行。例如，編輯named.conf檔案時加入「recursion no; };」後，即可關閉recursion功能。

上述的方法是整個關掉（或是開啟），若是針對某些來源IP來做開放，使用「allow-recursion」會比較方便。例如，編輯named.conf加入「allow-recursion { 172.18.0.0/16; };」，設定來源IP是172.18網段才允許recursion查詢。

NOTE

「recursion」和「allow-recursion」都只能設定在options區段，不能設在zone區段。

forwarders應用  

開放recursion查詢的Name Server可搭配forwarders選項功能，此功能將Client端DNS查詢forward（轉送）給某（幾）台DNS Server來得到回應。設定forwarders選項的原因，不外乎是希望得到更快速DNS查詢回應。  

選項forwarders範例  

例如開啟named.conf檔案，在options區段加入「forwarders { 168.95.1.1; 168.95.192.1; };」，如此設定會將DNS查詢forward給ISP的168.95.1.1與168.95.192.1這兩台Name Server。  

請注意，兩個IP之間的分隔符號是「;」分號。最後，記得重新啟動named使設定生效。

設定forwarders選項比較需要注意的地方是，千萬別錯誤設定指向到較遠的Name Server，例如明明是使用Seednet ISP線路，卻設定成forwarders到Hinet Name Server（應該就近forward到Seednet Name Server查詢才對），這樣錯誤的設定反而會造成反效果，查詢時的反應速度可能比不設定forwarders還要緩慢。

NOTE

遇到更換DNS Server對外IP時，倘若ISP業者也更換的話，最好檢查一下forwarders的設定是否適當。

檔案語法檢查工具  

在編輯named.conf與zone紀錄檔案的時候，難免會出現輸入錯字或是語法有誤的情況而不自知，建議使用「named-checkconf」指令來檢查named.conf檔案內容的正確性，以及使用「named-checkzone」指令來檢查zone紀錄檔案內容是否正確。  

語法檢查工具使用範例  

「named-checkconf」指令的使用方法是直接執行即可，若有錯誤，就會立刻顯示出來，參數頂多加上設定檔案named.conf位置（已做chroot的話，建議搭配「-t」選項以及「/var/named/chroot」參數）。當檔案存放路徑十分特殊的時候，才需要多下達參數。  

至於zone紀錄檔案的檢查比較複雜些，例如「named-checkzone ol /var/named/chroot/var/named/data/ol.db」指令可用來檢查ol zone紀錄檔案，而「named-checkzone 18.172.in-addr.arpa /var/named/chroot/var/named/data/172.18.db」指令則用於檢查172.18.Y.Z反解網域。

自行定義acl  

可以在named.conf中替某些IP或網段定義成名稱，以方便後續的應用，想這樣做的話，則使用acl這個選項，至於後續的應用，可使用「allow-transfer」、「allow-recursion」或「allow-query」等參數。  

使用acl範例  

「acl slave { 172.18.0.191; };」的作用是定義slave這個名稱為172.18.0.191這個IP。而「acl example { 172.19.0.0/16; 10.; };」則定義example這個名稱是172.19.0.0/16以及10.開頭的這個兩個網段（使用/16或直接「.」結尾，都可以用來表達網段）。至於「acl except { ! 192.168.2.0/24; };」，則定義except這個名稱是「除了192.168.2.0/24這個網段之外」（應用!驚嘆號可用來「反向選擇」；使用/24代表遮罩255.255.255.0）。舉例來說，定義好acl slave這個名稱之後，先前設定的「allow-transfer { 172.18.0.191; };」就可以改寫成「allow-transfer { slave; };」。

內建的acl名稱  

還記得我們曾經在slave主機named.conf設定allow-transfer選項成none嗎？這個「none」就是內建的acl名稱之一，代表著「沒有一個IP是」的意思，除了none之外，內建的acl名稱還有：  

●「any」代表任何來源主機/IP。
●「localhost」代表DNS主機本身所使用的IP，包括eth0、eth1、ppp0、lo等等。
●「localnets」代表DNS主機所使用的IP網段，同樣包括eth0、eth1、ppp0、lo這些介面。  

例如，設定named.conf選項「allow-query { any; };」，則表示允許所有來源IP來查詢DNS紀錄。  

使用view功能  

bind 9版view實用功能是能夠依照不同的來源IP／網段，回答不同的解析答案。舉個例子來說：假設管理foo.com.tw這個zone，區域網路網段IP是192.168.2.0/255.255.255.0，若是希望來自192.168.2.0/24網段發出詢問www.foo.com.tw紀錄，解析成192.168.2.168這個IP；而其他外部IP（例如4.5.6.7這個IP）來查詢www.foo.com.tw則是回應成公開IP（例如211.21.50.85）。  

以往要達到上述功能，都必須架設兩台Name Server，一台對內解析、一台對外解析，至於為何需要內外解析不同，最常遇到是因為NAT（Network Address Translate）架構造成這個需求。假如需要在master/slave配置，總共需要管理四台Name Server。簡而言之，導入bind 9 view功能有內外兩台合併成一台的優勢。  

view功能範例  

使用view功能，習慣性會先用acl定義網段名稱，之後再使用view來做出不同的來源IP詢問，回應不同解析的需求。  

底下是一個相當精簡「有view功能」的named.conf檔案內容：

其中，「acl lan { 192.168.2.0/24; };」定義lan是192.168.2.0/24網段。"inside"表示是給內部看的view區段。在inside的view中，「match-clients { lan; };」意思是符合的來源IP是lan這個acl名稱，也就是192.168.2.0/24這個網段。「zone "foo.com.tw"」內的file是「"foo.com.tw.in.db"」這個檔案，寫的解析應該有一筆設定需要解成內部的WWW指到192.168.2.168（依照先前舉的例子來設定）。  

至於"outside"，是給外部看的view區段。在outside的view中，「match-clients { any; };」意思是符合所有來源IP（除了先前的inside那個view中match-clients的lan以外）。「zone "foo.com.tw"」內的file是「"foo.com.tw.out.db"」這個檔案，寫的解析應該有一筆需要解成外部的www指到211.21.50.85（同樣也是依照先前舉的例子來設定）。接下來，輸入foo.com.tw.in.db和foo.com.tw.out.db這兩個zone紀錄檔案內容。重新啟動named，並使用不同的來源IP client端，測試結果是否如預期一般。

NOTE

在有view的情況下，master/slave之間zone transfer變得比較複雜些，因為被view隔開成兩個相同名稱的zone（例如foo.com.tw）。如果都需要transfer，可以在slave主機named.conf中分別針對內外兩個foo.com.tw zone設定transfer-source選項來指明transfer的來源IP。此時master/slave主機應該會有兩個以上的IP，而且必須分別互相連線得到才可以。

對外公開網域名稱的管理  

我們一開始設定管理的是一個毋須對外的ol網域，至於談到要管理對外公開的網域名稱（如foo.com.tw），直覺方式是仿造先前學習的ol網域，仿製成XXX.com.tw的zone。可別以為做出XXX.com.tw，往後全世界就能查得到！還有兩件事情要做：一個是「主機對外服務（用到公開IP）」另一個是「處理網域名稱授權的事情」。  

要讓全世界都能夠詢問，勢必要將主機對外（使用Public IP或NAT轉址進來皆可）。將主機對外之後，全世界並不會「主動」向這台（或是這兩台；一台master、一台slave）詢問它管理的zone，所以還要向上層處理「向下授權」的事情才妥當。處理「向下授權」需要費用並且設定正確之後，全世界才能夠正常地詢問到我們所管理以XXX.com.tw結尾的相關紀錄，例如www.XXX.com.tw指向3.4.5.6。  

主機對外服務  

將主機對外服務不是難事，花錢買線路並調整成正確的IP即可，而且通常買的是固定IP。接著，探討依照中小企業購買網際網路線路，如何配合DNS Server配置。  

類型一：「一條線路、僅僅一個IP」

那就只能一台對外，很可能只架設master而沒有slave，就算已架slave也無法同時對外（不會有人想要輪流對外吧？）。

類型二：「一條線路、多個IP」

建議架設master/slave架構，兩台皆對外服務，以便當一台主機掛掉的時候，另一台主機能夠繼續提供服務。

類型三：「多條線路、多個IP，同一機房地點」

分散在不同線路的兩台主機，可保有其中一條線路中斷，另一條線路的主機能夠繼續服務之優勢。

類型四：「多條線路、多個IP，不同機房地點」

散在不同地點、不同線路的兩台主機。當其中一個機房地點大停電（或是大災難）時，另一個地點的主機能夠繼續服務。

網域名稱申購與設定  

在台灣要購買網域名稱，通常是連接到「http://www.twnic.net.tw/」，進入網頁之後，先到左上角查看想要申請的網域名稱是否已經被別人買走（其實就是whois指令查到的結果）。右上圖是此網域名稱尚未被人購買的畫面。台灣的網域名稱，已經由民間代為銷售，所以可以去其中任何一家購買。

買好之後，就會得到一組帳號密碼，用來管理網域名稱的相關資訊。其中與我們最相關的是DNS管理（也就是whois紀錄的修改），填寫的欄位各家大同小異，舉例如下（通常最多五個空白行填寫）：  

如果是類型一。假設網域名稱foo.com.tw、公開IP是2.3.4.5，填寫的範例如下：

DNS 主機名稱	IP 位址
ns1.foo.com.tw	2.3.4.5
ns2.foo.com.tw	2.3.4.5

如果是類型二、三、四，這三種類型其實設定類似。假設網域名稱foo.com.tw，而公開IP是2.3.4.5、5.6.7.8，填寫範例如下：

DNS 主機名稱	IP 位址
ns1.foo.com.tw	2.3.4.5
ns2.foo.com.tw	5.6.7.8

設定好DNS管理之後，就等於處理好向上層要求「向下授權」的事情。可以使用指令「whois foo.com.tw」來確認修改是否正確。另外，DNS Server上的NS紀錄與對應的A紀錄最好與whois查出來的一致，運作才會順暢。例如「dig foo.com.tw ns」、「dig ns1.foo.com.tw」與「dig ns2.foo.com.tw」指令回應的資訊，應該要和「whois foo.com.tw」顯示的資訊相符。