分類: 教學

DNS 系列文章 2，來談談 DNS 的架構。

DNS 系列文章目錄

DNS 除錯教學系列文章(1) – DNS 入門
DNS 除錯教學系列文章(2) – DNS 架構
DNS 除錯教學系列文章(3) – DNS 紀錄
DNS 除錯教學系列文章(4) – dig 指令
DNS 除錯教學系列文章(5) – 常見 DNS 問題與 dig 除錯方法

DNS 的架構

在你了解 系列文章 1 的入門之後，現在我們來看看 DNS 的架構，DNS 是透過階層、分散資料的方式來完成查詢。在你輸入網址的時候：

https://haway.30cm.gg

系統會知道你是要在 rsync.tw 這個網域裡面查找 blog 這台主機(為什麼? 請看系列文章1)，系統會先檢查你的 hosts 檔的設定，如果沒有，就會查看 resolv.conf (Linux 系統) 的設定，將網域變更為 FQDN，然後從根網域開始尋找網域名稱。

“.” 我們又叫做 “Root” 或是 “根網域”，是所有 DNS 查詢的起始點，接者就會看你要查詢的網域是那一個，根網域向下”授權” 了很多子網域，像是 “tw”、”hk”、”cn”、”com”、”net” 等等的子網域，然後這些網域的域名管理局(Registry)，又會依照使用者所註冊的網域名稱來向下授權，譬如 rsync.tw 就會去查找 .tw 底下的 rsync 網域，所以就會透過 .tw 的 DNS 主機，如果是 rsync.jp，那就會去查找 .jp 的主機，在網域名稱就是透過 “.” 來區分每一層的 DNS 授權，blog.rsync.tw 就表示有兩層域名，主機是 blog。

關於 DNS 架構的其他參考文章：

• Study-area.org
• 鳥哥的私房菜

DNS 快取伺服器 – /etc/resolv.conf

在每個人的電腦裡面，一定會紀錄 DNS 快取伺服器的位址，快取伺服器的作用是協助電腦 (用戶端) 來查詢 DNS 的解析。

遞迴查詢與非遞迴查詢

在整個 DNS 的解析過程中，包含了遞迴查詢與非遞迴查詢兩種查詢模式。因為 DNS 架構是階層、分散式的，所以在每一個層裡面都只擁有自己所管理的一層資料，譬如 .tw 的主機內就只擁有 *.tw 的所有子網域 (但只有下一層)，所以 .tw DNS 主機內有 rsync.tw 的資料，但卻沒有 blog.rsync.tw 的紀錄。

因為每一層都只有自己的資料，所以當使用者要查詢 blog.rsync.tw 的時候，必須透過多次的查詢才能獲得最終的資料。

使用者的電腦在發起 DNS 查詢的時候，會對 DNS 快取伺服器發起”遞迴查詢“，然後快取伺服器就會針對查詢一層一層的幫使用者查詢到最終的答案，並將解答回傳給使用者。在使用者與快取伺服之間，使用者電腦只需要透過一次查詢，(例如送出 https://www.gandi.net)，快取伺服器就會透過根伺服器、.net 伺服器、gandi 伺服器依序查詢到最終主機(權威伺服器)，快取伺服器的這個過程我們稱為”非遞迴查詢” (因為要多次詢問)。

resolv.conf

前面有提到在使用者電腦發起 DNS 查詢的時候，他怎麼知道要去哪裡找快取伺服器呢？答案就是 /etc/resolv.conf (Linux 系統) 這個檔案，在這個檔案中，我們可以設定快取伺服器，你的電腦就會將 DNS 遞迴查詢送到這些伺服器做查詢。Linux 系統可以使用指令來查看你電腦的名稱伺服器：

{14:44}:@~/]$ cat /etc/resolv.conf 
domain rsync.tw
nameserver 168.95.1.1
nameserver 8.8.8.8
search hdns.com.tw example.com

這個檔案內的 nameserver 指的是 DNS 快取伺服器 (Cache Server)，並不是管理網域的名稱伺服器。

如果你有注意到，你會看到有 domain 與 search 這兩個設定，要講解他們的用途之前，你應該先了解什麼是 FQDN，在沒有 “.” 結尾的主機名稱，都會被系統自動附加網域名稱，而此設定就是告訴系統可以附加什麼網域名稱。

如果你只輸入 blog，系統會自動改為 blog.rsync.tw 並嘗試送到 168.95.1.1 進行 DNS 解析，如果不成功，會換成 blog.hdns.com.tw 再次嘗試解析，又失敗的話會改為 blog.example.com，所以你知道為什麼要先了解主機名稱、子網域與網域名稱的區別了嗎？

如果 168.95.1.1 的 DNS 服務無法連上，系統就會自動跳到第二筆 8.8.8.8 快取伺服器。

DNS 權威伺服器 (名稱伺服器)

DNS 權威伺服器就是管理 DNS 紀錄的主機，實際上是由系統管理員設定 DNS 服務，並將網域名稱加入到主機中，當主機接收到 DNS 查詢的時候，就會回應該網域名稱的資料。那你會覺得說 DNS 快取伺服器也會接收 DNS 查詢並且回應。跟權威主機有什麼不一樣呢？

快取伺服器是幫你去詢問其他主機的 DNS 資料，而權威主機是從自己的資料庫中取出資料並且回應。

因為現在多數人都會使用 DNS 代管服務。會在購買網域名稱的時候就使用域名註冊商所提供的 DNS 代管或是用其他第三方 DNS 代管，代管主機就是你的網域名稱的權威伺服器。

向下授權

前面有提到 DNS 架構的階層概念、主機名稱、網域名稱與權威主機。而串起所有 DNS 流程的功能，最重要的就是向下授權這個動作。我們再看一次這張圖：

圖中的 .(root) 指向了 tw 就是一個向下授權，代表根伺服器將 tw 網域向下授權給其他主機，而 .tw 又將 rsync(.tw) 與 com(.tw) 向下授權給不同的主機。

就像一個主管把技術授權給工程師小明，把行銷工作授權給阿美，把會計工作授權給大寶。如果有人跑來問主管說系統的問題要找誰，主管就會請他去找小明，而行銷與會計的工作，就分別去找阿美跟大寶，由主管來分配，而在 DNS 中，目前是由 ICANN 根據當初申請的狀況將各網域名稱分配給不同的機構，如 tw 是分配給TWNIC 進行管理，而 TWNIC 就要負責架設 tw 的權威伺服器來管理此網域與之下的所有子網域。

你將認識的第一個紀錄 – NS

ICANN 可以知道實際管理的機構，但電腦不知道，電腦只認識伺服器與 IP 位址，根伺服器會記錄每一個子網域 (.tw 對根伺服器來說是一個子網域) 的授權主機位置，就是透過 NS (NameServer) 紀錄，例如說根網域(.)的主機中會紀錄 .tw 主機的位置，所有查詢 .tw 的 DNS 就都會轉去 .tw 的授權主機進行下一步的查詢。

第一個除錯技巧-正確的授權主機是誰？

所以，第一個你將學習到的除錯技巧是你的 DNS 主機目前到底是正式授權到哪些主機上面，因為所有你網域名稱的 DNS 查都會從授權主機中查出答案，正式授權主機是什麼產生的呢？就是你在購買網域名稱的時候所填寫的名稱主機 (NameServer) ，網域註冊商 (Registrar) 會依照你所註冊的域名，把你的名稱伺服器送給域名管理局 (Registry)，管理局確認後就會把你的主機資料放入他們的紀錄中，就會產生一組 NS 資料。以本網站來說，筆者跟 .tw 註冊了 rsync.tw 的網域名稱，並且在網域註冊商的名稱伺服器中填寫了：

我們就可以從 dig 指令查詢到 rsync.tw 的 NS 紀錄，雖然我們還沒教你怎麼使用 dig ，但聰明的你一定可以小試伸手把域名改成你自己的，然後看看你的名稱伺服器是什麼：

{11:23}:@~]$ dig rsync.tw ns
 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> rsync.tw ns
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1881
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 7
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;rsync.tw.            IN  NS
 ;; ANSWER SECTION:
 rsync.tw.        2085    IN  NS  ns2.gandi.net.
 rsync.tw.        2085    IN  NS  ns1.gandi.net.
 rsync.tw.        2085    IN  NS  ns3.gandi.net.

查詢網域的名稱伺服器非常重要，因為當你在做 DNS 除錯的時候，一定要先確認目前的名稱伺服器是不是你所填寫的資料，如果不是，表示網域註冊商沒有更新，或是你填錯了，請立刻修正。

其實 ns 的查詢不是像本範例中那麼簡單，因為這樣查詢到的資料有可能是 TTL 的資料 (TTL 是什麼？)，後續會教你如何正確的查詢 NS(NameServer) 紀錄。

接者我們將在下一章結先看一下一些常見的 DNS 紀錄，然後在繼續學習 dig 的使用。

DNS 系列文章目錄

DNS 除錯教學系列文章(1) – DNS 入門
DNS 除錯教學系列文章(2) – DNS 架構
DNS 除錯教學系列文章(3) – DNS 紀錄
DNS 除錯教學系列文章(4) – dig 指令
DNS 除錯教學系列文章(5) – 常見 DNS 問題與 dig 除錯方法