DNS 越來越重要，尤其未來 IPv6 這個需要 128bits 位址的玩意兒。因為我們連 IPv4 的 32bits 都背不起來了， 128bits 要怎麼背？ 這時主機名稱自動解析為 IP 就很重要啦！那就是 DNS。但是 DNS 的架設有點麻煩，重點是原理的部分比較不好理解。 因此在這個小節當中，讓我們先來談談與網路主機名稱有關的一些知識，這樣架設 DNS 才不會出問題。
目前的網際網路世界使用的是所謂的 TCP/IP 協定，其中 IP 為第四版的 IPv4 。不過，這個 IPv4 是由 32 位元所組成，為了人腦已經轉成四組十進位的數字了，例如 12.34.56.78 這樣的格式。當我們利用 Internet 傳送資料的時候，就需要這個 IP ，否則資料封包怎麼知道要被送到哪裡去？
單一檔案處理上網的年代： /etc/hosts
然而人腦對於 IP 這種數字的玩意兒，記憶力實在是不怎麼樣。但是要上 Internet 又一定需要 IP，怎麼辦？為了應付這個問題， 早期的朋友想到一個方法，那就是利用某些特定的檔案將主機名稱與 IP 作一個對應， 如此一來，我們就可以透過主機名稱來取得該主機的 IP 了！真是個好主意，因為人類對於名字的記憶力可就好多了！ 那就是 /etc/hosts 這個檔案的用途了。
可惜的是，這個方法還是有缺憾的，那就是主機名稱與 IP 的對應無法自動於所有的電腦內更新， 且要將主機名稱加入該檔案僅能向 INTERNIC 註冊，若 IP 數量太多時，該檔案會大到不像話，也就更不利於其他主機同步化了。 如下圖所示，用戶端電腦每次都得要重新下載一次檔案才能順利聯網！
圖 19.1-1、早期透過單一檔案進行網路連線的示意圖
在第四章 4.2.1 裡面我們約略談過 /etc/hosts 這個檔案的用法，基本上該檔案內容就是『IP 主機名稱 主機別名一 主機別名二...』。在裡面最重要的就是 localhost 對應到 127.0.0.1 這個咚咚！你千萬不能刪除該筆記錄的。這裡也再次強調，在你的私有網域內部，最好將所有的私有 IP 與主機名稱對應都寫入這個檔案中啦！
分散式、階層式主機名稱管理架構： DNS 系統
早期網路尚未流行且電腦數量不多時，/etc/hosts 倒是還夠用的，但自從 90 年代網路熱門化後，單一檔案 /etc/hosts 的聯網問題就發生上面講的狀況啦！為了解決這個日益嚴重的問題，柏克萊大學發展出另外一套階層式管理主機名稱對應 IP 的系統， 我們稱它為 Berkeley Internet Name Domain, BIND ，這個系統可就優秀的多了～ 透過階層式管理，可以輕鬆的進行維護的工作～太棒了！這也是目前全世界使用最廣泛的領域名稱系統 (Domain Name System, DNS) 哩～透過 DNS ，我們不需要知道主機的 IP ，只要知道該主機的名稱，就能夠輕易的連上該主機了！
DNS 利用類似樹狀目錄的架構，將主機名稱的管理分配在不同層級的 DNS 伺服器當中，經由分層管理， 所以每一部 DNS 伺服器記憶的資訊就不會很多，而且若有 IP 異動時也相當容易修改！因為你如果已經申請到主機名稱解析的授權， 那麼在你自己的 DNS 伺服器中，就能夠修改全世界都可以查詢到的主機名稱了！而不用透過上層 ISP 的維護呢！ 自己動手當然是最快的啦！
由於目前的 IPv4 已經接近發送完畢的階段，因此未來那個 128bits 的 IPv6 會逐漸熱門起來。那麼你需要背 128bits 的 IP 來上網嗎？想必是不可能的！因此這個可以透過主機名稱就解析到 IP 的 DNS 服務，可以想像的到，它會越來越重要。此外，目前全世界的 WWW 主機名稱也都是透過 DNS 系統在處理 IP 的對應，所以，當 DNS 掛點時，我們將無法透過主機名稱來連線，那就幾乎相當於沒有 Internet 了！
因為 DNS 是這麼的重要，所以即使我們沒有架設它的必要時，還是得要熟悉一下它的原理才好。因此，跟 DNS 有關的 FQDN、Hostname 與 IP 的查詢流程，正解與反解、合法授權的 DNS 伺服器之意義，以及 Zone 等等的知識作一個認識才行！
| Tips: 在底下的說明當中，我們有時會提到 DNS 有時會提到 BIND ，這有什麼不同？ 由上面的說明裡面，你可以瞭解到， DNS 是一種網際網路的通訊協定名稱， 至於 Bind 則是提供這個 DNS 服務的軟體～這樣你瞭解了嗎？！ |
 |
完整主機名稱： Fully Qualified Domain Name (FQDN)
第一個與 DNS 有關的主機名稱概念，就是『主機名稱與領域名稱 (hostname and domain name)』的觀念，以及由這兩者組成的完整主機名稱 Fully Qualified Domain Name, FQDN 的意義了。在討論這個主題之前，我們來聊一聊比較生活化的話題：
- 以區域來區分同名同姓者的差異： 網路世界其實有很多人自稱為『鳥哥』的，包括敝人在下小生我啦！那麼你怎麼知道此鳥哥非彼鳥哥呢？ 這個時候你可以利用每個鳥哥的所在地來作為區分啊，比如說台南的鳥哥與台北的鳥哥等。 那萬一台南還有兩個人自稱鳥哥怎麼辦？沒關係，你還可以依照鄉鎮來區分呢！比如說台南北區的鳥哥及台南中區的鳥哥。 如果將這個咚咚列出來，就有點像這樣：
是否就可以分辨每個鳥哥的不同點了呢？呵呵！沒錯！就是這樣！那個地區就是『領域 (domain) 』，而鳥哥就是主機名啦！鳥哥、北區、台南
鳥哥、中區、台南
鳥哥、台北
......
- 以區域號碼來區分相同的電話號碼： 另外一個例子可以使用電話號碼來看，假如高雄有個 1234567 而台南也有個 1234567，那麼(1)你在高雄直接撥接 1234567 時，他會直接掛入高雄的 1234567 電話中，(2)但如果你要撥到台南去，就得加入 (06) 這個區碼才行！我們就是使用區碼來做為辨識之用的！此時那個 06 區碼就是 domain name，而電話號碼就是主機名稱啦！
有沒有一點點瞭解鳥哥想表達的啦？我們上面講到，DNS 是以樹狀目錄分階層的方式來處理主機名稱，那我們知道樹狀目錄中， 那個目錄可以記錄檔名。那麼 DNS 記錄的哪個咚咚跟『目錄』有關？就是那個領域名稱。領域名稱底下還可以記錄各個主機名稱， 組合起來才是完整的主機名稱 (FQDN)。
舉例來說，我們常常會發現主機名稱都是 www 的網站，例如 www.google.com.tw, www.seednet.net, www.hinet.net 等等，那麼我們怎麼知道這些 www 名稱的主機在不同的地方呢？就需要給他領域名稱囉！也就是 .google.com.tw, .seednet.net, .hinet.net 等等的不同，所以即使你的主機名稱相同，但是只要不是在同一個領域內，那麼就可以被分辨出不同的位置囉！
我們知道目錄樹的最頂層是根目錄 (/)，那麼 DNS 既然也是階層式的，最頂層是啥呢？每一層的 domain name 與 hostname 又該怎麼分？我們舉鳥哥所在的崑山科大的 WWW 伺服器為例好了 (www.ksu.edu.tw) ：
圖 19.1-2、分階層的 DNS 架構，以崑山科大為例 (hostname & domain name)
在上面的例子當中，由上向下數的第二層裡面，那個 .tw 是 domain name ，而 com, edu, gov 則是主機的名稱，而在這個主機的名稱之管理下，還有其他更小網域的主機，所以在第三層的時候，基本上，那個 edu.tw 就變成了 domain name 了！而崑山科大與成大的 ksu, ncku 則成為了 hostname 囉！
以此類推，最後得到我們的主機那個 www 是主機名稱，而 domain name 是由 ksu.edu.tw 那個名字所決定的！自然，我們的主機就是讓管理 ksu.edu.tw 這個 domain name 的 DNS 伺服器所管理的囉！這樣是否瞭解了 domain name 與 hostname 的不同了呢？
| Tips: 並不是以小數點 (.) 區分 domain name 與 hostname 喔！某些時刻 domain name 所管理的 hostname 會含有小數點。 舉例來說，鳥哥所在的資訊傳播系並沒有額外的 DNS 伺服器架設，因此我們的主機名稱為 www.dic ，而 domain name 還是 ksu.edu.tw ，因此全名為 www.dic.ksu.edu.tw 哩！ |
|
19.1.2 DNS 的主機名稱對應 IP 的查詢流程
約略瞭解了 FQDN 的 domain name 與 hostname 之後，接下來我們要談一談這個 DNS 的： (1)階層架構是怎樣？ (2)查詢原理是怎樣？總是要先知道架構才能知道如何查詢主機名稱的吶！所以底下我們先來介紹一下整體的 DNS 階層架構。
DNS 的階層架構與 TLD
我們依舊使用台灣學術網路的 DNS 伺服器所管理的各 domain 為例，將最上層到崑山科大 (ksu) 時，之間的各層繪製如下圖：
圖 19.1-3、從最上層到崑山科大之間的 DNS 階層示意圖
在整個 DNS 系統的最上方一定是 . (小數點) 這個 DNS 伺服器 (稱為 root)，最早以前它底下管理的就只有 (1)com, edu, gov, mil, org, .net 這種特殊領域以及 (2)以國家為分類的第二層的主機名稱了！這兩者稱為 Top Level Domains (TLDs) 喔！
- 一般最上層領域名稱 (Generic TLDs, gTLD)：例如 .com, .org, .gov 等等
- 國碼最上層領域名稱 (Country code TLDs, ccTLD)：例如 .tw, .uk, .jp, .cn 等
先來談談一般最上層領域 (gTLD) 好了，最早 root 僅管理六大領域名稱，分別如下：
| 名稱 | 代表意義 |
| com | 公司、行號、企業 |
| org | 組織、機構 |
| edu | 教育單位 |
| gov | 政府單位 |
| net | 網路、通訊 |
| mil | 軍事單位 |
但是網際網路成長的速度太快了，因此後來除了上述的六大類別之外，還有諸如 .asia, .info, .jobs (註1) 等領域名稱的開放。此外，為了讓某些國家也能夠有自己的最上層領域名稱，因此， 就有所謂的 ccTLD 了。這樣做有什麼好處呢？因為自己的國家內有最上層 ccTLD ，所以如果有 domain name 的需求，則只要向自己的國家申請即可，不需要再到最上層去申請囉！
授權與分層負責
既然 TLD 這麼好，那麼是否我們可以自己設定 TLD 呢？當然不行！因為我們得向上層 ISP 申請領域名稱的授權才行。例如台灣地區最上層的領域名稱是以 .tw 為開頭，管理這個領域名稱的機器 IP 是在台灣，但是 .tw 這部伺服器必須向 root (.) 註冊領域名稱查詢授權才行 (如上圖 19.1-3 所示)。
那麼每個國家之下記錄的主要下層有哪些領域呢？基本上就是原先 root 管理的那六大類。 不過，由於各層 DNS 都能管理自己轄下的主機名稱或子領域，因此，我們的 .tw 可以自行規劃自己的子領域名稱喔！ 例如目前台灣 ISP 常提供的 .idv.tw 的個人網站就是一例啊！
再強調一次，DNS 系統是以所謂的階層式的管理，所以，請注意喔！那個 .tw 只記錄底下那一層的這數個主要的 domain 的主機而已！至於例如 edu.tw 底下還有個 ksu.edu.tw 這部機器，那就直接授權交給 edu.tw 那部機器去管理了！也就是說『 每個上一層的 DNS 伺服器所記錄的資訊，其實只有其下一層的主機名稱而已！ 』至於再下一層，則直接『授權』給下層的某部主機來管理囉！呵呵！所以你就應該會知道 DNS 到底是如何管理的吧！
會這樣設定的原因不是沒有道理的！這樣設計的好處就是：每部機器管理的只有下一層的 hostname 對應 IP 而已，所以減少了管理上的困擾！而下層 Client 端如果有問題，只要詢問上一層的 DNS server 即可！不需要跨越上層，除錯上面也會比較簡單呢！
透過 DNS 查詢主機名稱 IP 的流程
剛剛說過 DNS 是以類似『樹狀目錄』的型態來進行主機名稱的管理的！所以每一部 DNS 伺服器都『僅管理自己的下一層主機名稱的轉譯』而已， 至於下層的下層，則『授權』給下層的 DNS 主機來管理啦！這樣說好像很繞口，好吧！我們就以下圖來說一說原理囉：
圖 19.1-4、透過 DNS 系統查詢主機名稱解譯的流程
首先，當你在瀏覽器的網址列輸入 http://www.ksu.edu.tw 時，你的電腦就會依據相關設定 (在 Linux 底下就是利用 /etc/resolv.conf 這個檔案) 所提供的 DNS 的 IP 去進行連線查詢了。由於目前最常見的 DNS 伺服器就屬 Hinet 的 168.95.1.1 這個 DNS，所以我們就拿他來做例子吧！嗯！這個時候，hinet 的這部伺服器會這樣工作：
- 收到用戶的查詢要求，先查看本身有沒有紀錄，若無則向 . 查詢：
由於 DNS 是階層式的架構，每部主機都會管理自己轄下的主機名稱解譯而已。因為 hinet 並沒有管理台灣學術網路的權力， 因此就無法直接回報給用戶端。此時 168.95.1.1 就會向最頂層，也就是 . (root) 的伺服器查詢相關 IP 資訊。
- 向最頂層的 . (root) 查詢：
168.95.1.1 會主動的向 . 詢問 www.ksu.edu.tw 在哪裡呢？但是由於 . 只記錄了 .tw 的資訊 (因為台灣只有 .tw 向 . 註冊而已)，此時 . 會告知『我是不知道這部主機的 IP 啦，不過，你應該向 .tw 去詢問才對，我這裡不管！ 我跟你說 .tw 在哪裡吧！』
- 向第二層的 .tw 伺服器查詢：
168.95.1.1 接著又到 .tw 去查詢，而該部機器管理的又僅有 .edu.tw, .com.tw, gov.tw... 那幾部主機，經過比對後發現我們要的是 .edu.tw 的網域，所以這個時候 .tw 又告訴 168.95.1.1 說：『你要去管理 .edu.tw 這個網域的主機那裡查詢，我有他的 IP ！』
- 向第三層的 .edu.tw 伺服器查詢：
同理可證， .edu.tw 只會告訴 168.95.1.1 ，應該要去 .ksu.edu.tw 進行查詢，這裡只能告知 .ksu.edu.tw 的 IP 而已。
- 向第四層的 .ksu.edu.tw 伺服器查詢：
等到 168.95.1.1 找到 .ksu.edu.tw 之後， Bingo ！.ksu.edu.tw 說：『沒錯！這部主機名稱是我管理的～ 我跟你說他的 IP 是...所以此時 168.95.1.1 就能夠查到 www.ksu.edu.tw 的 IP 囉！
- 記錄暫存記憶體並回報用戶：
查到了正確的 IP 後，168.95.1.1 的 DNS 機器總不會在下次有人查詢 www.ksu.edu.tw 的時候再跑一次這樣的流程吧！ 粉遠粉累的吶！而且也很耗系統的資源與網路的頻寬，所以呢，168.95.1.1 這個 DNS 會很聰明的先記錄一份查詢的結果在自己的暫存記憶體當中，以方便回應下一次的相同要求啊！ 最後則將結果回報給 client 端！當然啦，那個記憶在 cache 當中的資料，其實是有時間性的，當過了 DNS 設定記憶的時間 (通常可能是 24 小時)，那麼該記錄就會被釋放喔！
整個分層查詢的流程就是這樣，總是得要先經過 . 來向下一層進行查詢，最終總是能得到答案的。這樣分層的好處是：
- 主機名稱修改的僅需自己的 DNS 更動即可，不需通知其他人：
當一個『合法』的 DNS 伺服器裡面的設定修改了之後，來自世界各地任何一個 DNS 的要求，都會正確無誤的顯示正確的主機名稱對應 IP 的資訊，因為他們會一層一層的尋找下來。所以，要找你的主機名稱對應的 IP 就一定得要透過你的上層 DNS 伺服器的紀錄才行！因此，只要你的主機名字是經過上層『合法的 DNS』伺服器設定的，那麼就可以在 Internet 上面被查詢到啦！呵呵！很簡單維護吧，機動性也很高。
- DNS 伺服器對主機名稱解析結果的快取時間：
由於每次查詢到的結果都會儲存在 DNS 伺服器的快取記憶體中，以方便若下次有相同需求的解析時，能夠快速的回應。 不過，查詢結果已經被快取了，但是原始 DNS 的主機名稱與 IP 對應卻修改了，此時若有人再次查詢， 系統可能會回報舊的 IP 喔！所以，在快取內的答案是有時間性的！通常是數十分鐘到三天之內。 這也是為什麼我們常說當你修改了一個 domain name 之後，可能要 2 ~ 3 天後才能全面的啟用的緣故啦！
- 可持續向下授權 (子領域名稱授權)：
每一部可以記錄主機名稱與 IP 對應的 DNS 伺服器都可以隨意更動他自己的資料庫對應， 因此主機名稱與網域名稱在各個主機底下都不相同。舉例來說， idv.tw 是僅有台灣才有這個 idv 的網域～ 因為這個 idv 是由 .tw 所管理的，所以只要台灣 .tw 維護小組同意，就能夠建立該網域喔！
好啦！既然 DNS 這麼棒，然後我們又需要架站，所以需要一個主機的名稱，那麼我們需要架設 DNS 了嗎？當然不是，為什麼呢？剛剛鳥哥提到了很多次的『合法』的字眼，因為他就牽涉到『授權』的問題了！ 我們在第十章當中也提到，只要主機名稱合法即可，不見得需要架設 DNS 的啦！
| 例題：
透過 dig 實作出本小節談到的 . --> .tw --> .edu.tw --> .ksu.edu.tw --> www.ksu.edu.tw 的查詢流程，並分析每個查詢階段的 DNS 伺服器有幾部？
答：
事實上，我們可以透過第四章約略談過的 dig 這個指令來實作出喔！使用追蹤功能 (+trace) 就能夠達到這個目的了。使用方式如下：
|
DNS 使用的 port number
好了，既然 DNS 系統使用的是網路的查詢，那麼自然需要有監聽的 port 囉！沒錯！很合理！那麼 DNS 使用的是那一個 port 呢？那就是 53 這個 port 啦！你可以到你的 Linux 底下的 /etc/services 這個檔案看看！搜尋一下 domain 這個關鍵字，就可以查到 53 這個 port 啦！
但是這裡需要跟大家報告的是，通常 DNS 查詢的時候，是以 udp 這個較快速的資料傳輸協定來查詢的， 但是萬一沒有辦法查詢到完整的資訊時，就會再次的以 tcp 這個協定來重新查詢的！所以啟動 DNS 的 daemon (就是 named 啦) 時，會同時啟動 tcp 及 udp 的 port 53 喔！所以，記得防火牆也要同時放行 tcp, udp port 53 呢！
什麼？DNS 伺服器的架設還有『合法』與『不合法』之分喔？不是像其他的伺服器一樣，架設好之後人家就查的到嗎？ 非也非也！為什麼呢？底下我們就來談一談。
向上層領域註冊取得合法的領域查詢授權
我們在第十章也講過，申請一個合法的主機名稱就是需要註冊， 註冊就是需要花錢啦！那麼註冊取得的資料有兩種，一種是第十章談到的 FQDN (主機名稱)，一種就是申請領域查詢權。所謂的 FQDN 就是我們只需要主機名，詳細的設定資料就由 ISP 幫我們搞定。例如圖 19.1-4 所示， 那部 www.ksu.edu.tw 的詳細主機名稱對應 IP 的資料就是請管理 .ksu.edu.tw 那個領域的伺服器搞定的。
那什麼是領域查詢授權呢？同樣用圖 19.1-4 來解釋，我們的 .ksu.edu.tw 必須要向 .edu.tw 那部主機註冊申請領域授權，因此，未來有任何 .ksu.edu.tw 的要求時， .edu.tw 都會說：『我不知道！ 詳情請去找 .ksu.edu.tw 吧！』此時，我們就得要架設 DNS 伺服器來設定 .ksu.edu.tw 相關的主機名稱對應才行喔！ 是否很像人類社會的『授權』的概念？
也就是說，當你老闆充分的『授權』給你某項工作的時候，從此，要進行該項工作的任何人， 從老闆那邊知道你才是真正『有權』的人之後，都必須要向你請示一樣！^_^！所以囉，如果你要架設 DNS ，而且是可以連上 Internet 上面的 DNS 時，你就必須要透過『上層 DNS 伺服器的授權』才行！這是很重要的觀念喔！
讓我們歸納一下，要讓你的主機名稱對應 IP 且讓其他電腦都可以查詢的到，你有兩種方式：
- 上層 DNS 授權領域查詢權，讓你自己設定 DNS 伺服器，或者是；
- 直接請上層 DNS 伺服器來幫你設定主機名稱對應！
擁有領域查詢權後，所有的主機名資訊都以自己為準，與上層無關
很多朋友可能都有過申請 DNS 領域查詢授權的經驗，在申請時，ISP 就會要你填寫 (1)你的 DNS 伺服器名稱以及 (2)該伺服器的 IP。既然已經在 ISP 就填寫了主機名稱與 IP 的對應，所以，即使我的 DNS 伺服器掛點了，在 ISP 上面的主機名稱應該還是查到的 IP 吧？答案是：『錯！』查不到的！為什麼呢？
DNS 系統記錄的資訊非常的多，不過重點其實有兩個，一個是記錄伺服器所在的 NS (NameServer) 標誌，另一個則是記錄主機名稱對應的 A (Address) 標誌。我們在網路上面查詢到的最終結果，都是查詢 IP (IP Address) 的，因此最終的標誌要找的是 A 這個記錄才對！我們以鳥哥註冊的 .vbird.org 來說明好了，鳥哥去註冊時， 記錄在 ISP 的 DNS 伺服器名稱為 dns.vbird.org，該筆記錄其實就是 NS ，並非 A ，如下圖所示：
圖 19.1-5、記錄的授權主機名稱與實際 A 記錄的差異
上圖中，雖然在 godaddy 伺服器內有記錄一筆『要查詢 .vbird.org 時，請到 dns.vbird.org (NS) 去查，這個管理者的 IP 是 140.116...』，但是這筆記錄只是告訴我們要去下一個伺服器找，並不是最終的 A (IP Address) 的答案，所以還得要繼續往下找 (隨時記得圖 19.1-4 的查詢流程)。此時，有幾種結果會導致 dns.vbird.org 的 IP 找不到，或者是最終的 IP 與 godaddy 記錄的不同的結果喔！那就是：
- dns.vbird.org 伺服器掛點時： 如果 dns.vbird.org 這部主機掛點，那麼在上圖顯示『查詢』箭頭的步驟會被中斷，因此就會出現『連線不到 dns.vbird.org 的 IP』的結果。因為無論如何，DNS 系統都會去找到最後一個含有 A 位址的記錄啊！
- dns.vbird.org 伺服器內的資料庫忘記補上資料時： 如果鳥哥在自己的伺服器資料庫中，忘記加上 dns.vbird.org 的記錄時，最終的結果還是會顯示『找不到該伺服器的 IP』；
- dns.vbird.org 伺服器內的資料庫資料編寫不一致時： 如果是在鳥哥自己伺服器的資料庫內的 dns.vbird.org 所記錄的 IP 與 godaddy 的不同，最終的結果會以鳥哥記錄的為準。
總之，你在 ISP 上面填寫的主機名稱只是一個參考用的，最終還是要在你自己 DNS 伺服器當中設定好才行！ 雖然可以自己惡搞一下，不過，通常大家還是會讓 ISP 上面的 DNS 伺服器主機名與自己的資料庫主機名一致， 亦即上圖中，中間與最下面方框內的 dns.vbird.org 的 NS 及 A 都對應到同一個 IP 就是了。
正解的設定權以及 DNS 正解 zone 記錄的標誌
那誰可以申請正解的 DNS 伺服器架設權呢？答案是：都可以！只要該領域沒有人使用， 那你先搶到了，就能夠使用了。不過，因為國際 INTERNIC 已經定義出 gTLD 以及 ccTLD 了，所以你不能自訂例如 centos.vbird 這種網域的！還是得要符合上層 DNS 所給予的領域範圍才行。舉例來說，台灣個人網站就常使用 *.idv.tw 這樣的領域名稱。
那正解檔的 zone 裡面主要記錄了什麼東西呢？因為正解的重點在由主機名稱查詢到 IP，而且每部 DNS 伺服器還是得要定義清楚，同時，你可能還需要架設 master/slave 架構的 DNS 環境，因此，正解 zone 通常具有底下幾種標誌：
- SOA：就是開始驗證 (Start of Authority) 的縮寫，相關資料本章後續小節說明；
- NS：就是名稱伺服器 (NameServer) 的縮寫，後面記錄的資料是 DNS 伺服器的意思；
- A：就是位址 (Address) 的縮寫，後面記錄的是 IP 的對應 (最重要)；
反解的設定權以及 DNS 反解 zone 記錄的標誌
正解的領域名稱只要符合 INTERNIC 及你的 ISP 規範即可，取得授權較為簡單 (自己取名字)。那反解呢？反解主要是由 IP 找到主機名稱，因此重點是 IP 的所有人是誰啦！因為 IP 都是 INTERNIC 發放給各家 ISP 的，而且我們也知道，IP 可不能亂設定 (路由問題)！所以囉，能夠設定反解的就只有 IP 的擁有人，亦即你的 ISP 才有權力設定反解的。那你向 ISP 取得的 IP 能不能自己設定反解呢？答案是不行！除非你取得的是整個 class C 以上等級的 IP 網段，那你的 ISP 才有可能給你 IP 反解授權。否則，若有反解的需求，就得要向你的直屬上層 ISP 申請才行！
那麼反解的 zone 主要記錄的資訊有哪些呢？除了伺服器必備的 NS 以及 SOA 之外，最重要的就是：
- PTR：就是指向 (PoinTeR) 的縮寫，後面記錄的資料就是反解到主機名稱囉！
每部 DNS 都需要的正解 zone： hint
現在你知道一個正解或一個反解就可以稱為一個 zone 了！那麼有沒有那個 zone 是特別重要的呢？有的，那就是 . 啊！ 從圖 19.1-4 裡面我們就知道，當 DNS 伺服器在自己的資料庫找不到所需的資訊時， 一定會去找 . ，那 . 在哪裡啊？所以就得要有記錄 . 在哪裡的記錄 zone 才行啊！這個記錄 . 的 zone 的類型，就被我們稱為 hint 類型！這幾乎是每個 DNS 伺服器都得要知道的 zone 喔！
所以說，一部簡單的正解 DNS 伺服器，基本上就要有兩個 zone 才行，一個是 hint ，一個是關於自己領域的正解 zone。舉鳥哥註冊的 vbird.org 為例，在鳥哥的 DNS 伺服器內，至少就要有這兩個 zone：
- hint (root)：記錄 . 的 zone；
- vbird.org：記錄 .vbird.org 這個正解的 zone。
你會發現我沒有 vbird.org 這個 domain 所屬 IP 的反解 zone ，為什麼呢？請參考上面的詳細說明吧！ 簡單的說，就是因為反解需要要求 IP 協定的上層來設定才行！
正反解是否一定要成對？
好了，正反解需不需要成套產生，在這裡不用多說明了吧？^_^！請注意喔，在很多的情況下， 尤其是目前好多莫名其妙的領域名稱產生出來，所以，常常會只有正解的設定需求而已。不過也不需要太過擔心啦， 因為通常在反查的情況中，如果你是使用目前台灣地區最流行的 ADSL 上網的話，那麼 ISP 早就已經幫你設定好反解了！例如：211.74.253.91 這個 seednet 的浮動式 IP 反查的結果會得到 211-74-253-91.adsl.dynamic.seed.net.tw. 這樣的主機名稱！所以在一般我們自行申請領域名稱的時候，你只要擔心正解的設定即可！ 不然的話，反正反解的授權根本也不會開放給你，你自己設定得很高興也沒有用呀！ ^_^
事實上，需要正反解成對需求的大概僅有 mail server 才需要吧！由於目前網路頻寬老是被垃圾、廣告郵件佔光， 所以 Internet 的社會對於合法的 mail server 規定也就越來越嚴格。如果你想要架設 mail server 時， 最好具有固定 IP ，這樣才能向你的 ISP 要求設定反解喔！以 hinet 為例的反解申請：
19.1.6 DNS 資料庫的類型：hint, master/slave 架構
你知道的，DNS 越來越重要，所以，如果你有註冊過領域名稱的話，就可以發現，現在 ISP 都要你填寫兩部 DNS 伺服器的 IP 哩！因為要作為備援之用嘛！總不能一部 DNS 掛點後，害你的所有主機名稱都不能被找到～那真麻煩～
但是，如果有兩部以上的 DNS 伺服器，那麼網路上會搜尋到哪一部呢？答案是，不知道！因為是隨機的～ 所以，如果你的領域有兩部 DNS 伺服器的話，那這兩部 DNS 伺服器的內容就得完全一模一樣，否則，由於是隨機找到 DNS 來詢問，因此若資料不同步，很可能造成其他用戶無法取得正確資料的問題。
為了解決這個問題，因此在 . (root) 這個 hint 類型的資料庫檔案外，還有兩種基本類型，分別是 Master (主人、主要) 資料庫與 Slave (奴隸、次要) 資料庫類型。這個 Master/Slave 就是要用來解決不同 DNS 伺服器上面的資料同步問題的。 所以底下讓我們來聊聊 Master/Slave 吧！
Master：
這種類型的 DNS 資料庫中，裡面所有的主機名稱相關資訊等，通通要管理員自己手動去修改與設定， 設定完畢還得要重新啟動 DNS 服務去讀取正確的資料庫內容，才算完成資料庫更新。一般來說，我們說的 DNS 架設，就是指設定這種資料庫的類型。同時，這種類型的資料庫，還能夠提供資料庫內容給 slave 的 DNS 伺服器喔！
Slave：
如前所述，通常你不會只有一部 DNS 伺服器，例如我們前面的例題查詢到的 .ksu.edu.tw 就有 3 部 DNS 伺服器來管理自己的領域。那如果每部 DNS 我們都是使用 Master 資料庫類型，當有用戶向我要求要修改或者新增、刪除資料時， 一筆資料我就得要做三次，還可能會不小心手滑導致某幾部出現錯誤，此時可就傷腦筋了～因此，這時使用 Slave 類型的資料庫取得方式就很有用！
Slave 必須要與 Master 相互搭配，若以 .ksu.edu.tw 的例子來說，如果我必須要有三部主機提供 DNS 服務，且三部內容相同， 那麼我只要指定一部伺服器為 Master ，其他兩部為該 Master 的 Slave 伺服器，那麼當要修改一筆名稱對應時，我只要手動更改 Master 那部機器的設定檔，然後，重新啟動 BIND 這個服務後，呵呵！其他兩部 Slave 就會自動的被通知更新了！這樣一來，在維護上面可就輕鬆寫意的多了～
| Tips: 如果你設定 Master/Slave 架構時，你的 Master 主機必須要限制 只有某些特定 IP 的主機能夠取得你 Master 主機的正反解資料庫權限才好！ 所以，上面才會提到 Master/Slave 必須要互相搭配才行！ |
|
Master / Slave 的查詢優先權？
另外，既然我的所有 DNS 伺服器是需要同時提供 internet 上面的領域名稱解析的服務， 所以不論是 Master 還是 Slave 伺服器，他都必須要可以同時提供 DNS 的服務才好！ 因為在 DNS 系統當中，領域名稱的查詢是『先搶先贏』的狀態，我們不會曉得哪一部主機的資料會先被查詢到的！ 為了提供良好的 DNS 服務，每部 DNS 主機都要能正常工作才好啊！而且，每一部 DNS 伺服器的資料庫內容需要完全一致，否則就會造成用戶端找到的 IP 是錯誤的！
Master / Slave 資料的同步化過程
那麼 Master/Slave 的資料更新到底是如何動作的呢？請注意，Slave 是需要更新來自 Master 的資料啊！所以當然 Slave 在設定之初就需要存在 Master 才行喔！基本上，不論 Master 還是 Slave 的資料庫，都會有一個代表該資料庫新舊的『序號』，這個序號數值的大小，是會影響是否要更新的動作唷！ 至於更新的方式主要有兩種：
- Master 主動告知：例如在 Master 在修改了資料庫內容，並且加大資料庫序號後， 重新啟動 DNS 服務，那 master 會主動告知 slave 來更新資料庫，此時就能夠達成資料同步；
- 由 Slave 主動提出要求：基本上， Slave 會定時的向 Master 察看資料庫的序號， 當發現 Master 資料庫的序號比 Slave 自己的序號還要大 (代表比較新)，那麼 Slave 就會開始更新。如果序號不變， 那麼就判斷資料庫沒有更動，因此不會進行同步更新。
由上面的說明來看，其實設計資料庫的序號最重要的目的就是讓 master/slave 資料的同步化。那我們也知道 slave 會向 master 提出資料庫更新的需求，問題是，多久提出一次更新，如果該次更新時由於網路問題，所以沒有查詢到 master 的序號 (亦即更新失敗)，那隔多久會重新更新一次？這個與 SOA 的標誌有關，後續談到正、反解資料庫後， 再來詳細說明吧！
如果你想要架設 Master/Slave 的 DNS 架構時，兩部主機 (Master/Slave) 都需要你能夠掌控才行！網路上很多的文件在這個地方都有點『閃失』，請特別的留意啊！因為鳥哥的 DNS 伺服器常常會聽到某些其他 DNS 的資料庫同步化需求，真覺得煩吶！
- /etc/hosts ：這個是最早的 hostname 對應 IP 的檔案；
- /etc/resolv.conf ：這個重要！就是 ISP 的 DNS 伺服器 IP 記錄處；
- /etc/nsswitch.conf：這個檔案則是在『決定』先要使用 /etc/hosts 還是 /etc/resolv.conf 的設定！
19.3 DNS 伺服器的軟體、種類與 cache only DNS 伺服器設定
談完了一些基礎概念後，接下來讓我們來聊一聊，那如何設定好 DNS 伺服器啊？這當然就得由軟體安裝談起啦！ 在這個小節，我們先不要談 DNS 記錄的正反解咚咚，只講到 hint 這個 . (root) 的 zone，談一談最簡單的僅有快取的 DNS 伺服器 (Caching only DNS server) 吧！
19.3.1 架設 DNS 所需要的軟體終於廢話都說完了！相信你大概也有點累的吧？鳥哥是蠻累的啦，因為手臂、肩頸酸痛的毛病頗嚴重....咦！講這個幹嘛？ @_@ 好啦，我們終於要來安裝 DNS 所需要的軟體了！還記得前面提過的，我們要使用的 DNS 軟體就是使用柏克萊大學發展出來的 BIND (Berkeley Internet Name Domain, BIND) 這個啦！那麼怎麼知道你安裝了沒？不就是 rpm 與 yum 嗎？自己查查看。
[root@www ~]# rpm -qa | grep '^bind' bind-libs-9.7.0-5.P2.el6_0.1.x86_64 <==給 bind 與相關指令使用的函式庫 bind-utils-9.7.0-5.P2.el6_0.1.x86_64 <==這個是用戶端搜尋主機名稱的相關指令 bind-9.7.0-5.P2.el6_0.1.x86_64 <==就是 bind 主程式所需軟體 bind-chroot-9.7.0-5.P2.el6_0.1.x86_64 <==將 bind 主程式關在家裡面！ |
上面比較重要的是那個『 bind-chroot 』啦！所謂的 chroot 代表的是『 change to root(根目錄) 』的意思，root 代表的是根目錄。早期的 bind 預設將程序啟動在 /var/named 當中，但是該程序可以在根目錄下的其他目錄到處轉移，因此若 bind 的程式有問題時，則該程序會造成整個系統的危害。為避免這個問題， 所以我們將某個目錄指定為 bind 程式的根目錄，由於已經是根目錄，所以 bind 便不能離開該目錄！所以若該程序被攻擊，了不起也是在某個特定目錄底下搞破壞而已。 CentOS 6.x 預設將 bind 鎖在 /var/named/chroot 目錄中喔！
我們主程式是由 bind, bind-chroot 所提供，那前一小節提到的，每部 DNS 伺服器都要有的 . (root) 這個 zone file 在哪裡？它也是由 bind 所提供的喔！ (CentOS 4.x, 5.x 所提供的 caching-nameserver 軟體並不存在 CentOS 6.x 當中了喔！已經被涵蓋於 bind 軟體內！)
19.3.2 BIND 的預設路徑設定與 chroot要架設好 BIND 需要什麼設定資料呢？基本上有兩個主要的資料要處理：
- BIND 本身的設定檔：主要規範主機的設定、zone file 的所在、權限的設定等；
- 正反解資料庫檔案 (zone file)：記錄主機名稱與 IP 對應的等。
BIND 的設定檔為 /etc/named.conf，在這個檔案裡面可以規範 zone file 的完整檔名喔！ 也就是說，你的 zone file 其實是由 /etc/named.conf 所指定的，所以 zone file 檔名可以隨便取啦！ 只要 /etc/named.conf 內規範為正確即可。一般來說， CentOS 6.x 的預設目錄是這樣的：
- /etc/named.conf ：這就是我們的主設定檔啦！
- /etc/sysconfig/named ：是否啟動 chroot 及額外的參數，就由這個檔案控制；
- /var/named/ ：資料庫檔案預設放置在這個目錄
- /var/run/named ：named 這支程式執行時預設放置 pid-file 在此目錄內。
/etc/sysconfig/named 與 chroot 環境
不過，為了系統的安全性考量，一般來說目前各主要 distributions 都已經自動的將你的 bind 相關程式給他 chroot 了！ 那你如何知道你 chroot 所指定的目錄在哪裡呢？其實是記錄在 /etc/sysconfig/named 裡面啦！你可以先查閱一下：
[root@www ~]# cat /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/...
哇！真是好麻煩～不過，不要太擔心！因為新版本的 CentOS 6.x 已經將 chroot 所需要使用到的目錄，透過 mount --bind 的功能進行目錄連結了 (參考 /etc/init.d/named 內容)，舉例來說，我們需要的 /var/named 在啟動腳本中透過 mount --bind /var/named /var/named/chroot/var/named 進行目錄綁定囉！所以在 CentOS 6.x 當中，你根本無須切換至 /var/named/chroot/ 了！使用正規的目錄即可喔！就是這樣簡單！^_^
| Tips: 事實上， /etc/sysconfig/named 是由 /etc/init.d/named 啟動時所讀入的，所以你也可以直接修改 /etc/init.d/named 這個 script 哩！ |
|
19.3.3 單純的 cache-only DNS 伺服器與 forwarding 功能在下一小節開始介紹正、反解 zone 的資料設定之前，在這個小節當中，我們先來談一個單純修改設定檔，而不必設計 zone file 的環境，那就是不具有自己正反解 zone 的僅進行快取的 DNS 伺服器。
什麼是 cache-only 與 forwarding DNS 伺服器呢？
有個只需要 . 這個 zone file 的簡單 DNS 伺服器，我們稱這種沒有自己公開的 DNS 資料庫的伺服器為 cache-only (僅快取) DNS server！顧名思義，這個 DNS server 只有快取搜尋結果的功能，也就是說，他本身並沒有主機名稱與 IP 正反解的設定檔，完全是由對外的查詢來提供他的資料來源！
那如果連 . 都不想要呢？那就得要指定一個上層 DNS 伺服器作為你的 forwarding (轉遞) 目標，將原本自己要往 . 查詢的任務，丟給上層 DNS 伺服器去煩惱即可。 如此一來，我們這部具有 forwarding 功能的 DNS 伺服器，甚至連 . 都不需要了！因為 . 有記錄在上層 DNS 上頭了嘛！
如同剛剛提到的，cache only 的 DNS 並不存在資料庫 (其實還是存在 . 這個 root 領域的 zone file)， 因此不論是誰來查詢資料，這部 DNS 一律開始從自己的快取以及 . 找起，整個流程與圖 19.1-4 相同。那如果具有 forwarding 功能呢？果真如此，那即使你的 DNS 具有 . 這個 zone file，這部 DNS 還是會將查詢權『委請』上層 DNS 查詢的，這部 DNS 伺服器當場變成用戶端啦！查詢流程會變這樣喔：
圖 19.3-1、具有 forwarding 功能的 DNS 伺服器查詢方式
觀察上圖的查詢方向，你會發現到，具有 forwarding 機制時，查詢權會委請上層 DNS 伺服器來處理，所以根本也不需要 . 這個位置所在的 zone 啦。一般來說，如果你的環境需要架設一個 cache-only 的 DNS 伺服器時，其實可以直接加上 forwarding 的機制，讓查詢權指向上層或者是流量較大的上層 DNS 伺服器即可。那既然 cache only 的伺服器並沒有資料庫， forwarding 機制甚至不需要 . 的 zone ，那幹嘛還得要架設這樣的 DNS 呢？是有理由的啦！
什麼時候有架設 cache-only DNS 的需求？
在某些公司行號裡頭，為了預防員工利用公司的網路資源作自己的事情，所以都會針對 Internet 的連線作比較嚴格的限制。當然啦，連 port 53 這個 DNS 會用到的 port 也可能會被擋在防火牆之外的～這個時候， 你可以在『防火牆的那部機器上面，加裝一個 cache-only 的 DNS 服務！』
這是什麼意思呢？很簡單啊！就是你自己利用自己的防火牆主機上的 DNS 服務去幫你的 Client 端解譯 hostname <--> IP 囉！因為防火牆主機可以設定放行自己的 DNS 功能，而 Client 端就設定該防火牆 IP 為 DNS 伺服器的 IP 即可！哈哈！這樣就可以取得主機名稱與 IP 的轉譯啦！所以，通常架設 cache only DNS 伺服器大都是為了系統安全囉。
實際設定 cache-only DNS server
那如何在你的 Linux 主機上架設一個 cache-only 的 DNS 伺服器呢？其實真的很簡單的啦！因為不需要設定正反解的 zone (只需要 . 的 zone 支援即可)，所以只要設定一個檔案 (就是 named.conf 主設定檔) 即可！真是快樂得不得了吶！ 另外，cache-only 只要加上個 forwarders 的設定即可指定 forwarding 的資料，所以底下我們將設定具有 forwarding 的 cache-only DNS 伺服器吧！
編輯主要設定檔： /etc/named.conf
雖然我們具有 chroot 的環境，不過由於 CentOS 6.x 已經透過啟動腳本幫我們進行檔案與目錄的掛載連結，所以請你直接修改 /etc/named.conf 即可呦！不要再去 /var/named/chroot/etc/named.conf 修改啦！ 在這個檔案中，主要是定義跟伺服器環境有關的設定，以及各個 zone 的領域及資料庫所在檔名。 在鳥哥的這個案例當中，因為使用了 forwarding 的機制，所以這個 cache-only DNS 伺服器並沒有 zone (連 . 都沒有)，所以我們只要設定好跟伺服器有關的設定即可。設定這個檔案的時候請注意：
- 註解資料是放置在兩條斜線『 // 』後面接的資料
- 每個段落之後都需要以分號『 ; 』來做為結尾！
鳥哥將這個檔案再簡化如下的樣式：
鳥哥將大部分的資料都予以刪除，只將少部分保留的資料加以小部分的修訂而已。在 named.conf 的結構中，與伺服器環境有關的是由 options 這個項目內容設定的，因為 options 裡面還有很多子參數， 所以就以大括號 { } 包起來囉。至於 options 內的子參數在上面提到的較重要的項目簡單敘述如下：[root@www ~]# cp /etc/named.conf /etc/named.conf.raw [root@www ~]# vim /etc/named.conf // 在預設的情況下，這個檔案會去讀取 /etc/named.rfc1912.zones 這個領域定義檔 // 所以請記得要修改成底下的樣式啊！ options { listen-on port 53 { any; }; //可不設定，代表全部接受 directory "/var/named"; //資料庫預設放置的目錄所在 dump-file "/var/named/data/cache_dump.db"; //一些統計資訊 statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; //可不設定，代表全部接受 recursion yes; //將自己視為用戶端的一種查詢模式 forward only; //可暫時不設定 forwarders { //是重點！ 168.95.1.1; //先用中華電信的 DNS 當上層 139.175.10.20; //再用 seednet 當上層 }; }; //最終記得要結尾符號！
- listen-on port 53 { any; };
監聽在這部主機系統上面的哪個網路介面。預設是監聽在 localhost，亦即只有本機可以對 DNS 服務進行查詢，那當然是很不合理啊！ 所以這裡要將大括號內的資料改寫成 any。記得，因為可以監聽多個介面，因此 any 後面得要加上分號才算結束喔！ 另外，這個項目如果忘記寫也沒有關係，因為預設是對整個主機系統的所有介面進行監聽的。
- directory "/var/named";
意思是說，如果此檔案底下有規範到正、反解的 zone file 檔名時，該檔名預設應該放置在哪個目錄底下的意思。預設放置到 /var/named/ 底下。由於 chroot 的關係，最終這些資料庫檔案會被主動連結到 /var/named/chroot/var/named/ 這個目錄。
- dump-file, statistics-file, memstatistics-file
與 named 這個服務有關的許多統計資訊，如果想要輸出成為檔案的話，預設的檔名就如上所述。鳥哥自己很少看這些統計資料， 所以，這三個設定值寫不寫應該都是沒有關係的。
- allow-query { any; };
這個是針對用戶端的設定，到底誰可以對我的 DNS 服務提出查詢請求的意思。原本的檔案內容預設是針對 localhost 開放而已， 我們這裡改成對所有的用戶開放 (當然啦，防火牆也得放行才行)。不過，預設 DNS 就是對所有用戶放行，所以這個設定值也可以不用寫。
- forward only ;
這個設定可以讓你的 DNS 伺服器僅進行 forward，即使有 . 這個 zone file 的設定，也不會使用 . 的資料， 只會將查詢權交給上層 DNS 伺服器而已，是 cache only DNS 最常見的設定了！
- forwarders { 168.95.1.1; 139.175.10.20; } ;
既然有 forward only，那麼到底要對哪部上層 DNS 伺服器進行轉遞呢？那就是 forwarders (不要忘記那個 s) 設定值的重要性了！由於擔心上層 DNS 伺服器也可能會掛點，因此可以設定多部上層 DNS 伺服器喔！每一個 forwarder 伺服器的 IP 都需要有『 ; 』來做為結尾！
很簡單吧！至於更多的參數我們會在後續篇幅當中慢慢介紹的。這樣就已經設定完成了最簡單的 cache only DNS server 了！
啟動 named 並觀察服務的埠口
啟動總不會忘記吧？趕快去啟動一下吧！同時啟動完畢之後，觀察一下由 named 所開啟的埠口，看看到底哪些埠口會被 DNS 用到的！
我們知道 DNS 會同時啟用 UDP/TCP 的 port 53，而且是針對所有介面，因此上面的資料並沒有什麼特異的部分。不過，怎麼會有 port 953 且僅針對本機來監聽呢？其實那是 named 的遠端控制功能，稱為遠端名稱解析服務控制功能 (remote name daemon control, rndc)。預設的情況下，僅有本機可以針對 rndc 來控制。我們會在後續的章節再來探討這個 rndc 啦，目前我們只要知道 UDP/TCP port 53 有啟動即可。# 1. 啟動一下 DNS 這玩意兒！ [root@www ~]# /etc/init.d/named start Starting named: [ OK ] [root@www ~]# chkconfig named on # 2. 到底用了多少埠口呢？ [root@www ~]# netstat -utlnp | grep named Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.100.254:53 0.0.0.0:* LISTEN 3140/named tcp 0 0 192.168.1.100:53 0.0.0.0:* LISTEN 3140/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 3140/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 3140/named tcp 0 0 ::1:953 :::* LISTEN 3140/named udp 0 0 192.168.100.254:53 0.0.0.0:* 3140/named udp 0 0 192.168.1.100:53 0.0.0.0:* 3140/named udp 0 0 127.0.0.1:53 0.0.0.0:* 3140/named
檢查 /var/log/messages 的內容訊息 (極重要！)
named 這個服務的記錄檔就直接給他放置在 /var/log/messages 裡面啦，所以來看看裡面的幾行登錄資訊吧！
上面最重要的是第一行出現的『-t ...』那個項目指出你的 chroot 目錄囉。另外，上面表格中特殊字體的部分，有寫到讀取 /etc/named.conf，代表可以順利的載入 /var/named/etc/named.conf 的意思。如果上面有出現冒號後面接數字 (:10)， 那就代表某個檔案內的第十行有問題的意思，屆時再進入處理即可。要注意的是，即使 port 53 有啟動，但有可能 DNS 服務是錯誤的，此時這個登錄檔就顯的非常重要！每次重新啟動 DNS 後，請務必查閱一下這個檔案的內容！！[root@www ~]# tail -n 30 /var/log/messages | grep named Aug 4 14:57:09 www named[3140]: starting BIND 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 -u named -t /var/named/chroot <==說明的是 chroot 在哪個目錄下！ Aug 4 14:57:09 www named[3140]: adjusted limit on open files from 1024 to 1048576 Aug 4 14:57:09 www named[3140]: found 1 CPU, using 1 worker thread Aug 4 14:57:09 www named[3140]: using up to 4096 sockets Aug 4 14:57:09 www named[3140]: loading configuration from '/etc/named.conf' Aug 4 14:57:09 www named[3140]: using default UDP/IPv4 port range: [1024, 65535] Aug 4 14:57:09 www named[3140]: using default UDP/IPv6 port range: [1024, 65535] Aug 4 14:57:09 www named[3140]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 4 14:57:09 www named[3140]: listening on IPv4 interface eth0, 192.168.1.100#53 Aug 4 14:57:09 www named[3140]: listening on IPv4 interface eth1, 192.168.100.254#53 Aug 4 14:57:09 www named[3140]: generating session key for dynamic DNS Aug 4 14:57:09 www named[3140]: command channel listening on 127.0.0.1#953 Aug 4 14:57:09 www named[3140]: command channel listening on ::1#953 Aug 4 14:57:09 www named[3140]: the working directory is not writable Aug 4 14:57:09 www named[3140]: running
Tips:
如果你在 /var/log/messages 裡面一直看到這樣的錯誤資訊：
couldn't add command channel 127.0.0.1#953: not found
那表示你還必需要加入 rndc key ，請參考本章後面的 利用 RNDC 指令管理 DNS 伺服器 的介紹，將他加入你的 named.conf 中！
測試：
如果你的 DNS 伺服器具有連上網際網路的功能，那麼透過『 dig www.google.com @127.0.0.1 』這個基本指令執行看看， 如果有找到 google 的 IP ，並且輸出資料的最底下顯示『 SERVER: 127.0.0.1#53(127.0.0.1) 』的字樣， 那就代表應該是成功啦！其他更詳細的測試請參考：19.2 小節的內容
