架設 DNS 所需要的套件： 終於廢話都說完了！相信您大概也有點累的吧？鳥哥是蠻累的啦，因為手臂、 肩頸酸痛的毛病頗嚴重....咦！講這個幹嘛？ @_@ 好啦，我們終於要來安裝 DNS 所需要的套件了！還記得前面提過的，我們要使用的 DNS 就是使用柏克萊大學發展出來的 BIND (Berkeley Internet Name Domain, BIND) 這個套件啦！那麼怎麼知道您安裝了沒？還記得 基礎篇 裡面的 RPM 嗎？對啦！就是使用 RPM 來檢驗囉： [root@linux ~]# rpm -qa | grep bind bind-utils-9.2.4-16.EL4 <==這個是用戶端搜尋主機名稱的相關指令 bind-9.2.4-16.EL4 <==這個才是 DNS 伺服器主程式 bind-chroot-9.2.4-16.EL4 <==將 bind 主程式關在家裡面！ ^_^ 萬一沒裝怎麼辦？嗄！還問我ㄌㄟ～趕快將您的原版光碟拿出來，然後將他安裝上去先～不會安裝？ 請自行拿出『鳥哥的 Linux 私房菜 -- 基礎學習篇』去觀察一下 RPM 的用法吧！ 當然啦，更好的作法就是利用 yum install bind 即可啊！
此外，那個 bind-chroot 是幹嘛用的？所謂的 chroot 代表的是『 change to root 』的意思， 那個 root 代表的是根目錄。早期的 bind 預設將程序啟動在 /var/named 當中，但是該程序可以在根目錄到處轉移， 因此若 bind 的程式有問題時，則該程序會造成整個系統的危害。為避免這個問題， 所以我們將某個目錄指定為 bind 程式的根目錄，由於是根目錄， 所以 bind 便不能離開該目錄！所以如果該程序被攻擊，了不起也是在某個特定目錄底下搞破壞而已。 CentOS 預設將 bind 鎖在 /var/named/chroot 目錄中喔！ ^_^
BIND 的預設路徑設定與 chroot
好了，現在我們知道 BIND 這個 DNS 伺服器的設定需要有
本身的設定檔：主要規範主機的設定、zone file 的所在、權限的設定等； ? 資料庫檔案：記錄主機名稱與 IP 對應的等。
?
其中 BIND 的設定檔為 /etc/named.conf ，而在這個檔案裡面可以規範 zone file 的完整檔名喔！ 也就是說，你的 zone file 其實是由 /etc/named.conf 所指定的，所以 zone file 檔名可以隨便取啦！ 只要 /etc/named.conf 內規範為正確即可。一般來說， CentOS 的預設目錄是這樣的：
/etc/named.conf ：這就是我們的設定檔啦！
? /etc/sysconfig/named ：是否啟動 chroot 及額外的參數，就由這個檔案控制；
? /var/named/ ：資料庫檔案預設放置在這個目錄
? /var/run/named ：named 這支程式執行時預設放置 pid-file 在此目錄內。
?
不過，為了系統的安全性考量，一般來說目前各主要 distributions 都已經自動的將你的 bind 相關程式給他 chroot 了！ 那你如何知道你 chroot 所指定的目錄在哪裡呢？就是上面提到的那個 /etc/sysconfig/named 啦！ 你可以先查閱一下： [root@linux ~]# vi /etc/sysconfig/named ROOTDIR=/var/named/chroot 事實上裡面有意義的就只有上面這一行，意思是說：『我要將 named 給他 chroot ，並且變更的根目錄為 /var/named/chroot 』喔！由於根目錄已經被變更到 /var/named/chroot 了，但 bind 的相關程式是需要 /etc, /var/named, /var/run .... 等目錄的，所以實際上咱們 bind 的相關程式所需要的所有資料會是在：
/var/named/chroot/etc/named.conf
? /var/named/chroot/var/named/zone_file1
? /var/named/chroot/var/named/zone_file..... ? /var/named/chroot/var/run/named/...
?
哇！真是好麻煩～不過，不要太擔心！因為新版本的 distributions 通常幫您作好一些連結對應了！ 舉例來說，你依舊可以使用 /etc/named.conf 來設定你的 DNS ，為什麼呢？因為 CentOS 主動的幫你將
/var/named/chroot/etc/named.conf 連結到 /etc/named.conf 囉！ 另外，絕大部分預設的 zone file 資料庫檔案也都主動的幫你做好連結了！請自行進入 /var/named 去 ls 一下吧！ ^_^
Tips:
事實上， /etc/sysconfig/named 是由 /etc/init.d/named 啟動時所讀入的， 所以你也可以直接修改 /etc/init.d/named 這個 script 哩！
另外你需要注意到的是 /var/run/named/ 這個目錄是要讓 bind 的程式
(named) 寫入用的， 所以他的權限必需要讓 named 這個使用者可以寫入才行！這個可重要的很！
? BIND 的升級：
必須請大家注意的是，這個 DNS 的 53 port 其實也不是個很安全的咚咚，所以呢，非必要，其實是不太建議啟用 DNS 的啦！不過，如果真的要安裝的話，那麼請隨時注意您的 Linux distribution 是否有定時的公告的漏洞修補套件呢？這個真的很重要，因為鳥哥很久很久以前，就是被這個 port 53 給種植了一個蠕蟲，真是討厭的很！ @_@
另外，舊版的使用者使用新的 9.x 版以後的 BIND 時，由於主動幫你設定好 chroot ， 你可能一開始會不太適應，不過，不建議你拿掉 chroot 的功能！畢竟 DNS 的 port 53 是需要 root 身份啟動的， 具有一定的危險性，所以，給他 chroot 畢竟是比較妥當啦！您說是吧！
DNS 的 master/slave 架構
在 DNS 的設定上面，基本上，您必須要已經很清楚 zone 是什麼了，否則很難繼續設定喔！會搞的一塌糊塗的～無論如何，您一定要知道的是， bind 的設定檔，就是 /etc/named.conf。 不過，由於 chroot 的關係，這個檔案也可能會在 /var/named/chroot/etc/ 當中， 另外，針對 DNS server 的類型大致上可以分為三類，分別是：
? Master：
這種類型的 DNS 本身含有領域名稱的設定檔 (就是有 Zone 啦！)， 這個設定檔就是設定正解或者是反解的『Database』囉！所以他本身是具有提供 Internet 查詢所需的資料喔！例如我可以在我的主機上面設定提供 vbird.idv.tw 這個網域，那麼我的主機就是 master 類型的主機啦！
? Slave：
假設你的 DNS 伺服器總共管理 50 部主機的 IP 與主機名稱的對應好了， 同時假設你只有一部 DNS 伺服器時，那麼萬一由於網路問題或者是主機的軟、硬體問題，導致這個服務終止了， 想一想，你那 50 部主機的 hostname 與 IP 的對應還能不能找的到？是吧！ 所以，一般來說， DNS 系統通常會建議您至少要有兩部主機提供 DNS 的服務～
不過，如果您有四部 DNS 主機提供這樣的名稱解析服務， 而且這四部是互相為備援的，也就是說，這四部主機的內容其實是一模一樣的， 那麼如果您要更動一個 IP 與名稱的對應時，就必須要手動去修訂四部主機的內容， 這樣會不會很麻煩啊？！
這個時候就有 slave 類型的 DNS 主機出現了！不過，slave主機必須要與 master 主機相互搭配喔！ 以上面的案例來說明，如果我必須要有四部主機提供 DNS 服務，且四部內容相同， 那麼我只要指定一部主機為 Master ，其他三部為該 Master 的 Slave 主機， 那麼當要修改一部名稱對應時，我只要手動更改 master 那部機器的設定檔，然後， 重新啟動 BIND 這個服務後，呵呵！其他三部 slave 就會自動的被通知更新了！ 這樣一來，在維護上面可就輕鬆寫意的多了～
Tips:
如果您設定 Master/Slave 架構時，您的 Master 主機必須要限制 只有某些特定 IP 的主機能夠取得您 Master 主機的正反解資料庫權限才好！ 所以，上面才會提到 Master/Slave 必須要互相搭配才行！
另外，既然我的所有 DNS 伺服器是需要同時提供 internet 上面的領域名稱解
析的服務， 所以不論是 Master 還是 Slave 主機，他都必須要可以同時提供 DNS 的服務才好！ 因為在 DNS 系統當中，領域名稱的查詢是『先搶先贏』的狀態， 我們不會曉得哪一部主機的資料會先被查詢到的！ 為了提供良好的 DNS 服
務，每部 DNS 主機都要能正常工作才好啊！ 而且，每一部 DNS 伺服器的資料庫內容需要完全一致，否則就會造成用戶端找到的 IP 是錯誤的！
? Cache-only：
這種類型的 DNS 主機沒有自己的資料庫，單純僅幫助 Client 端向外部的 DNS 主機要求資料而已～簡單的來說，他可以想成是一個『代理人』的角色而已～ 通常設定在防火牆上面的呢！
那麼 Master/Slave 的資料更新到底是如何動作的呢？請注意，Slave 是需要更新來自 Master 的 DNS 資料啊！所以當然 Slave 在設定之初就需要存在 Master 才行喔！好了， Master 與 Slave 的資料同步動作可以由底下的圖示來看：
圖五、Master/Slave 的 DNS 主機資料同步過程
整個更新的過程是這樣的：
1. Slave 判斷是否需要更新(1.1)：
我們可以在 Slave 設定好向 Master DNS 主機要求資料更新的週期時間，則每當到達更新時間時， Slave 會向 Master 索取是否需要更新資料，這個更新資料的判斷則以 Serial number 是否不同來進行更新喔！ 2. Master 判斷是否需要更新(1.2)： 除了由 Slave 向 Master 的查詢之外，Master 如果 DNS 資料經過變更，且想要 Slave 同步更新時，也可以主動的向 Slave 進行更新通知！ 3. 資料同步化(2)：
最後當然就是資料由 Master 傳送到 Slave 來更新 Slave 的 DNS 資料囉！ 如果您想要架設 Master/Slave 的 DNS 架構時，兩部主機 (Master/Slave) 都需要您能夠掌控才行！網路上很多的文件在這個地方都有點『閃失』， 請特別的留意啊！
底下我們就先來講一個不需要資料庫檔案的 cache only 的 DNS 伺服器吧！
單純的 cache-only 與 forwarding DNS 主機設定 ? 什麼是 cache-only 與 forwarding DNS 的主機呢？
在介紹怎麼設定每一個正反解的 zone 之前，我們先來玩一個簡單的 DNS 主機！就是 cache-only (僅快取) DNS server！顧名思義，這個 DNS server 只有 cache (快取) 的功能，也就是說，他本身並沒有主機名稱與 IP 正反解的設定檔， 完全是由對外的查詢來提供他的資料來源！
至於 forwarding (轉遞) 的 DNS server 則是將用戶端所需要查詢的資訊轉交給 forwarding DNS server 來代為查詢， 等到查詢結束後，我們的 DNS server 才將結果快取後回傳給用戶端。這兩者的整個運作流程可以看成是這個樣子：
圖六、Cache-Only 與 Forwarding DNS 主機的運作流程
觀察一下圖六上下兩個圖示，妳可以發現 cache-only 需要知道 . (root) DNS 的位址， 所以 cache-only 必須要指定出 . (root) DNS 的資料庫所在檔案才行。至於 Forwarding DNS 主機， 他是直接將查詢的資料丟給另一部上層 DNS 來查詢，本身可以不必知道 . (root) DNS 的位址！ 一般來說，如果妳的環境需要架設一個 cache-only 的 DNS server 時，其實可以直接使用 forwarding 的機制， 選擇的那部 DNS 主機流量要能夠負荷較大流量為佳！
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库LIUNX 鸟哥的架设 DNS教程适合菜鸟从零开始在线全文阅读。
相关推荐：