19.1 什么是 DNS · 鳥哥的Linux私房菜：服務器架設篇第三版

## 19.1 什么是 DNS DNS 越來越重要，尤其未來 IPv6 這個需要 128bits 地址的玩意兒。因為我們連 IPv4 的 32bits 都背不起來了， 128bits 要怎么背？這時主機名自動解析為 IP 就很重要啦！那就是 DNS。但是 DNS 的架設有點麻煩，重點是原理的部分比較不好理解。因此在這個小節當中，讓我們先來談談與網絡主機名有關的一些知識，這樣架設 DNS 才不會出問題。 * * * ### 19.1.1 用網絡主機名取得 IP 的歷史淵源目前的因特網世界使用的是所謂的 TCP/IP 協議，其中 IP 為第四版的 IPv4 。不過，這個 IPv4 是由 32 位所組成，為了人腦已經轉成四組十進制的數字了，例如 12.34.56.78 這樣的格式。當我們利用 Internet 傳送數據的時候，就需要這個 IP ，否則數據封包怎么知道要被送到哪里去？ * 單一檔案處理上網的年代： /etc/hosts 然而人腦對于 IP 這種數字的玩意兒，記憶力實在是不怎么樣。但是要上 Internet 又一定需要 IP，怎么辦？為了應付這個問題，早期的朋友想到一個方法，那就是利用某些特定的檔案將主機名與 IP 作一個對應，如此一來，我們就可以透過主機名來取得該主機的 IP 了！真是個好主意，因為人類對于名字的記憶力可就好多了！那就是 /etc/hosts 這個檔案的用途了。可惜的是，這個方法還是有缺憾的，那就是主機名與 IP 的對應無法自動于所有的計算機內更新，且要將主機名加入該檔案僅能向 INTERNIC 注冊，若 IP 數量太多時，該檔案會大到不象話，也就更不利于其他主機同步化了。如下圖所示，客戶端計算機每次都得要重新下載一次檔案才能順利聯網！ ![](https://box.kancloud.cn/2016-05-13_5735da7ac563e.gif) 圖 19.1-1、早期透過單一檔案進行網絡聯機的示意圖在[第四章 4.2.1](http://linux.vbird.org/linux_server/0130internet_connect.php#connect_fix_IP) 里面我們約略談過 /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 服務的軟件～這樣你了解了嗎？！ ![](https://box.kancloud.cn/2016-05-13_5735736501917.gif) * 完整主機名： 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) ： ![](https://box.kancloud.cn/2016-05-13_5735da7b18f9e.gif) 圖 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](http://www.dic.ksu.edu.tw/) 哩！ ![](https://box.kancloud.cn/2016-05-13_5735736501917.gif) * * * ### 19.1.2 DNS 的主機名對應 IP 的查詢流程約略了解了 FQDN 的 domain name 與 hostname 之后，接下來我們要談一談這個 DNS 的： (1)階層架構是怎樣？ (2)查詢原理是怎樣？總是要先知道架構才能知道如何查詢主機名的吶！所以底下我們先來介紹一下整體的 DNS 階層架構。 * DNS 的階層架構與 TLD 我們依舊使用臺灣學術網絡的 DNS 服務器所管理的各 domain 為例，將最上層到昆山科大 (ksu) 時，之間的各層繪制如下圖： ![](https://box.kancloud.cn/2016-05-13_5735da7b60136.gif) 圖 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](#ps1)) 等領域名的開放。此外，為了讓某些國家也能夠有自己的最上層領域名，因此，就有所謂的 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 主機來管理啦！這樣說好像很繞口，好吧！我們就以下圖來說一說原理啰： ![](https://box.kancloud.cn/2016-05-13_5735da7b735f0.gif) 圖 19.1-4、透過 DNS 系統查詢主機名解譯的流程首先，當你在瀏覽器的網址列輸入 [http://www.ksu.edu.tw](http://www.ksu.edu.tw/) 時，你的計算機就會依據相關設定 (在 Linux 底下就是利用 /etc/resolv.conf 這個檔案) 所提供的 DNS 的 IP 去進行聯機查詢了。由于目前最常見的 DNS 服務器就屬 Hinet 的 168.95.1.1 這個 DNS，所以我們就拿他來做例子吧！嗯！這個時候，hinet 的這部服務器會這樣工作： 1. 收到用戶的查詢要求，先查看本身有沒有紀錄，若無則向 . 查詢：由于 DNS 是階層式的架構，每部主機都會管理自己轄下的主機名解譯而已。因為 hinet 并沒有管理臺灣學術網絡的權力，因此就無法直接回報給客戶端。此時 168.95.1.1 就會向最頂層，也就是 . (root) 的服務器查詢相關 IP 信息。 2. 向最頂層的 . (root) 查詢： 168.95.1.1 會主動的向 . 詢問 www.ksu.edu.tw 在哪里呢？但是由于 . 只記錄了 .tw 的信息 (因為臺灣只有 .tw 向 . 注冊而已)，此時 . 會告知『我是不知道這部主機的 IP 啦，不過，你應該向 .tw 去詢問才對，我這里不管！我跟你說 .tw 在哪里吧！』 3. 向第二層的 .tw 服務器查詢： 168.95.1.1 接著又到 .tw 去查詢，而該部機器管理的又僅有 .edu.tw, .com.tw, gov.tw... 那幾部主機，經過比對后發現我們要的是 .edu.tw 的網域，所以這個時候 .tw 又告訴 168.95.1.1 說：『你要去管理 .edu.tw 這個網域的主機那里查詢，我有他的 IP ！』 4. 向第三層的 .edu.tw 服務器查詢：同理可證， .edu.tw 只會告訴 168.95.1.1 ，應該要去 .ksu.edu.tw 進行查詢，這里只能告知 .ksu.edu.tw 的 IP 而已。 5. 向第四層的 .ksu.edu.tw 服務器查詢：等到 168.95.1.1 找到 .ksu.edu.tw 之后， Bingo ！.ksu.edu.tw 說：『沒錯！這部主機名是我管理的～我跟你說他的 IP 是...所以此時 168.95.1.1 就能夠查到 www.ksu.edu.tw 的 IP 啰！ 6. 記錄暫存內存并回報用戶：查到了正確的 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 了嗎？當然不是，為什么呢？剛剛鳥哥提到了很多次的『合法』的字眼，因為他就牽涉到『授權』的問題了！我們在[第十章](http://linux.vbird.org/linux_server/0270dynamic_dns.php)當中也提到，只要主機名合法即可，不見得需要架設 DNS 的啦！例題：透過 dig 實作出本小節談到的 . --> .tw --> .edu.tw --> .ksu.edu.tw --> www.ksu.edu.tw 的查詢流程，并分析每個查詢階段的 DNS 服務器有幾部？答：事實上，我們可以透過[第四章](http://linux.vbird.org/linux_server/0130internet_connect.php)約略談過的 dig 這個指令來實作出喔！使用追蹤功能 (+trace) 就能夠達到這個目的了。使用方式如下： ``` [root@www ~]# dig +trace www.ksu.edu.tw ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>>+trace www.ksu.edu.tw ;; global options: printcmd . 486278 IN NS a.root-servers.net. . 486278 IN NS b.root-servers.net. ....(底下省略).... # 上面的部分在追蹤 . 的服務器，可從 a ~ m.root-servers.net. ;; Received 500 bytes from 168.95.1.1#53(168.95.1.1) in 22 ms tw. 172800 IN NS ns.twnic.net. tw. 172800 IN NS a.dns.tw. tw. 172800 IN NS b.dns.tw. ....(底下省略).... # 上面的部分在追蹤 .tw. 的服務器，可從 a ~ h.dns.tw. 包括 ns.twnic.net. ;; Received 474 bytes from 192.33.4.12#53(c.root-servers.net) in 168 ms edu.tw. 86400 IN NS a.twnic.net.tw. edu.tw. 86400 IN NS b.twnic.net.tw. # 追蹤 .edu.tw. 的則有 7 部服務器 ;; Received 395 bytes from 192.83.166.11#53(ns.twnic.net) in 22 ms ksu.edu.tw. 86400 IN NS dns2.ksu.edu.tw. ksu.edu.tw. 86400 IN NS dns3.twaren.net. ksu.edu.tw. 86400 IN NS dns1.ksu.edu.tw. ;; Received 131 bytes from 192.83.166.9#53(a.twnic.net.tw) in 22 ms www.ksu.edu.tw. 3600 IN A 120.114.100.101 ksu.edu.tw. 3600 IN NS dns2.ksu.edu.tw. ksu.edu.tw. 3600 IN NS dns1.ksu.edu.tw. ksu.edu.tw. 3600 IN NS dns3.twaren.net. ;; Received 147 bytes from 120.114.150.1#53(dns2.ksu.edu.tw) in 14 ms ``` 最終的結果有找到 A (Address) 是 120.114.100.101，不過這個例題的重點是，要讓大家瞧瞧整個 DNS 的搜尋過程！在 dig 加上 +trace 的選項后，就能夠達到這個目的。至于其他的都是服務器 (NS) 的設定值與追蹤過程喔！有沒有很清楚啊？^_^。至于 A 與 NS 等相關的數據，我們在后續的 DNS 數據庫介紹中，再分別介紹啰。 * 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 呢！ * * * ### 19.1.3 合法 DNS 的關鍵：申請領域查詢授權什么？DNS 服務器的架設還有『合法』與『不合法』之分喔？不是像其他的服務器一樣，架設好之后人家就查的到嗎？非也非也！為什么呢？底下我們就來談一談。 * 向上層領域注冊取得合法的領域查詢授權我們在[第十章](http://linux.vbird.org/linux_server/0270dynamic_dns.php)也講過，申請一個合法的主機名就是需要注冊，注冊就是需要花錢啦！那么注冊取得的資料有兩種，一種是第十章談到的 FQDN (主機名)，一種就是申請領域查詢權。所謂的 FQDN 就是我們只需要主機名，詳細的設定數據就由 ISP 幫我們搞定。例如[圖 19.1-4](#fig19.1-4) 所示，那部 www.ksu.edu.tw 的詳細主機名對應 IP 的數據就是請管理 .ksu.edu.tw 那個領域的服務器搞定的。那什么是領域查詢授權呢？同樣用[圖 19.1-4](#fig19.1-4) 來解釋，我們的 .ksu.edu.tw 必須要向 .edu.tw 那部主機注冊申請領域授權，因此，未來有任何 .ksu.edu.tw 的要求時， .edu.tw 都會說：『我不知道！詳情請去找 .ksu.edu.tw 吧！』此時，我們就得要架設 DNS 服務器來設定 .ksu.edu.tw 相關的主機名對應才行喔！是否很像人類社會的『授權』的概念？也就是說，當你老板充分的『授權』給你某項工作的時候，從此，要進行該項工作的任何人，從老板那邊知道你才是真正『有權』的人之后，都必須要向你請示一樣！^_^！所以啰，如果你要架設 DNS ，而且是可以連上 Internet 上面的 DNS 時，你就必須要透過『上層 DNS 服務器的授權』才行！這是很重要的觀念喔！讓我們歸納一下，要讓你的主機名對應 IP 且讓其他計算機都可以查詢的到，你有兩種方式： 1. 上層 DNS 授權領域查詢權，讓你自己設定 DNS 服務器，或者是； 2. 直接請上層 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 ，如下圖所示： ![](https://box.kancloud.cn/2016-05-13_5735da7b86c2b.gif) 圖 19.1-5、記錄的授權主機名與實際 A 記錄的差異上圖中，雖然在 godaddy 服務器內有記錄一筆『要查詢 .vbird.org 時，請到 dns.vbird.org (NS) 去查，這個管理者的 IP 是 140.116...』，但是這筆記錄只是告訴我們要去下一個服務器找，并不是最終的 A (IP Address) 的答案，所以還得要繼續往下找 (隨時記得[圖 19.1-4](#fig19.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 就是了。 * * * ### 19.1.4 主機名交由 ISP 代管還是自己設定 DNS 服務器前面 19.1.3 小節以及第十章都談過，申請主機名或域名主要有兩種方式，就是剛剛上頭提到的 DNS 授權，或者是直接交給 ISP 來管理。交給 ISP 管理的，就可以稱作是域名代管啦！當然啦，如果你是學校單位的話，或者是企業內部的小單位，那么就得請你向上層 DNS 主機的負責人要求啰！無論如何，你只能有兩個選擇就是了，要不就是請他幫忙你設定好 hostname 對應 IP ，要嘛就是請他直接將某個 domain name 段授權給你做為 DNS 的主要管理網域。那么我怎么知道那個方式對我比較好呢？請注意，由于 DNS 架設之后，會多出一個監聽的 port ，所以理論上，是比較不安全的！而且，由于因特網現在都是透過主機名在聯機，在了解上面談到的主機名查詢流程后，你會發現，DNS 設定錯誤是很要命的！因為你的主機名再也找不到了。所以，這里的建議是： * 需要架設 DNS 的時機： * 你所負責需要連上 Internet 的主機數量龐大：例如你一個人負責整個公司十幾部的網絡 Server，而這些 Server 都是掛載你的公司網域之下的。這個時候想要不架設 DNS 也粉難啦！ * 你可能需要時常修改你 Server 的名字，或者是你的 Server 有隨時增加的可能性與變動性； * 不需要架設 DNS 的時機： * 網絡主機數量很少：例如家里或公司只有需要一部 mail server 時； * 你可以直接請上層 DNS 主機管理員幫你設定好 Hostname 的對應時； * 你對于 DNS 的認知不足時，如果架設反而容易造成網絡不通的情況； * 架設 DNS 的費用很高時！ * * * ### 19.1.5 DNS 數據庫的記錄：正解, 反解, Zone 的意義從前面的[圖 19.1-4](#fig19.1-4) 的查詢流程中，我們知道最重要的就是 .ksu.edu.tw 那部 DNS 服務器內的記錄信息了。這些記錄的咚咚我們可以稱呼為數據庫，而在數據庫里面針對每個要解析的領域 (domain)，就稱為一個區域 (zone)。那么到底有哪些要解析的領域呢？基本上，有從主機名查到 IP 的流程，也可以從 IP 反查到主機名的方式。因為最早前 DNS 的任務就是要將主機名解析為 IP，因此： * 從主機名查詢到 IP 的流程稱為：正解 * 從 IP 反解析到主機名的流程稱為：反解 * 不管是正解還是反解，每個領域的記錄就是一個區域 (zone) 舉例來說，昆山科大 DNS 服務器管理的就是 *.ksu.edu.tw 這個領域的查詢權，任何想要知道 *.ksu.edu.tw 主機名的 IP 都得向昆山科大的 DNS 服務器查詢，此時 .ksu.edu.tw 就是一個『正解的領域』。而昆山科大有申請到幾個 class C 的子域，例如 120.114.140.0/24，如果這 254 個可用 IP 都要設定主機名，那么這個 120.114.140.0/24 就是一個『反解的領域』！另外，每一部 DNS 服務器都可以管理多個領域，不管是正解還是反解。 * 正解的設定權以及 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](#fig19.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 為例的反解申請： * [http://hidomain.hinet.net/top1.html](http://hidomain.hinet.net/top1.html) * * * ### 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 必須要互相搭配才行！ ![](https://box.kancloud.cn/2016-05-13_5735736501917.gif) * 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 的數據庫同步化需求，真覺得煩吶！ * * *