|
|
|
5-3 網域名稱系統分析
5-3-1 DNS系統簡介 『網域名稱系統』（Domain Name System, DNS）是目前網路上最不可或缺的應用系統，不論使用者瀏覽網頁、傳遞電子郵件、或使用各種應用系統等都必須仰賴 DNS 系統，來將網域名稱轉譯成 IP 位址，才能連結到資源所在的網站。目前網路上絕大部份的資源都以網域名稱來命名，譬如，網頁名稱（www.nsysu.edu.tw）、FTP 資源（ftp.nsysu.edu.tw）、Telnet 伺服器（bbs.nsysu.edu.tw）或電子郵遞信箱（tsnien@pchome.com.tw）。又當您在瀏覽網頁時，可以發現絕大部份時間都在作超連結動作，這些超連結也都是以網域名稱來表示。因此，任何一部電腦雖然網路狀況良好，如果沒有指定某一部 DNS Server，來負責解譯 IP 位址的工作，也無法連結到網路上 然而，全世界至少有上億的網域名稱需要解譯，以得到它的 IP 位址，如此龐大的紀錄資料如何來登錄和解譯呢？這的確是個非常繁重的工作，但事實上並沒有那麼複雜。DNS 是一套分散式系統，解譯與登錄工作是由全球的 DNS 系統共同來達成，每一部 DNS 伺服器只負責該管轄地區的網域名稱，如果客戶查詢的名稱不在自己管轄範圍，便將其轉送到其它 DNS 伺服器上。DNS 系統的運作模式有點類似路徑選擇協定一樣，都是由 Internet 網路上所有端點共同來達成，也就是說，它的組織管理是鬆散的，並沒有一套嚴謹的專屬系統來負責，如此便增加了 Internet 的成長速度。 DNS 系統最基本功能是將網域名稱解譯成 IP 位址。當客戶端使用網域名稱連結時，首先會到 DNS 伺服器上查詢該名稱的 IP 位址，再以查詢出來的 IP 位址連結到資源所在的地方。如圖 5-10 所示，在電腦 A 上執行 telnet linux-1.cu.edu.tw，電腦 A 首先會到所指定的 DNS 伺服器上，查詢 linux-1.cu.edu.tw 的相對 IP 位址（163.15.2.62），再依此位址連結到目的地（動作順序如圖中編號次序）。但此動作如要能順利進行，DNS 伺服器必需事先登錄有關 linux-1 的資料。
圖 5-10 DNS 正向解譯功能 5-3-2 DNS 命名方式 整個 DNS 系統裡包含三種網域名稱系列： (1) 反向網域：作為登錄由 IP 位址解譯到網域名稱使用。 (2) 通用網域：大多以三個英文字母表示某一組織單位的網域名稱，此網域名稱都以美國本土單位為主，如 adsl.support.cisco.com。 (3) 國家網域：大多以兩個字母來表示某一國家的網域名稱（ISO 3166 規範），或者表示某一地理區域的網域，如 cis.cu.edu.tw。
圖 5-11 DNS 網域名稱階層 (A) 網域區域 網域名稱是以樹狀階層式方式建構，最上層的根網域『.』包含三種系列網域名稱：反向網域、通用網域和國家網域。在根網域之下的網域稱之為『頂層網域』（Top Level Domain），譬如，com、edu、tw、jp 等。每一頂層網域管轄它所屬的第二層網域，也就是說，它必須負責登錄與管理第二層網域名稱的解譯，如要查詢頂層網域底下的哪一次網域，便可直接詢問該頂層網域。然而，第二層網域也必須負責登錄及管理它所管轄的第三層網域。當然，每一網域（不論哪一層次）都必須有專屬名稱伺服器（Name Server）來負責登錄及管理，簡單的說，上層名稱伺服器必須登錄下層名稱伺服器的位址，當客戶端查詢某一網域時（如 edu.tw），則上層名稱伺服器（tw），必須回應該網域（edu.tw）所管轄的名稱伺服器位址，同理，edu.tw 網域的伺服器必須登錄 cu.edu.tw 名稱伺服器位址，然而 cu.edu.tw 的名稱伺服器，再登錄 linux.cu.edu.tw 的主機位址（IP 位址）。 因此，所謂『網域區域』（Domain Zone）表示某一網域所管轄的範圍，如圖 5-4 中，橢圓形都表示一個網域區域。任一網域至少要有一部名稱伺服器負責該網域下的子網域和主機登錄。譬如，圖中 edu.tw. 網域不但要管理該網域下的次網域（如 cu 等），可能該網域也有主機名稱（如 linux.cu.tw.），而必須登錄以備查詢。然而，如果網域區域（如 com.）過大時，也許會由許多名稱伺服器來服務查詢工作，而另一方面，網域區域較小時（一般企業網域），一部名稱伺服器也可以管理若干個區域。 (B) 完整網域名稱 所謂『完整網域名稱』（Full Qualified Domain Name, FQDN），就是能完整表現出某一主機的名稱。然而，網域名稱是以樹狀的反向排列方式，上下層之間都以一個『.』來區分，因此，FQDN 的表示必須由『主機名稱』 + 『網域名稱』 + 『.』。譬如，圖 5-4 中 linux 主機的 FQDN 為『linux.cu.edu.tw.』，其中『linux』為主機名稱、『cu.edu.tw』為網域名稱、又『.』為根網域。但一般習慣性並未將根網域填入，而一般電腦系統也都會自動將『.』填入。這是因為 DNS 系統的查詢，都以 FQDN 名稱來查詢，正是我們設定 DNS 伺服器時（登錄時）必須注意的事項。 5-3-3 DNS 協定運作 當 DNS 伺服器收到某一筆查詢要求卻無法提供服務時，或者客戶端向伺服器查詢卻得不到正確回應時，應該如何向其它伺服器查詢呢？這就是 DNS 系統的協定運作。DNS 是一種分散處理系統，所有 DNS 系統上的資料是由全球的 DNS 伺服器共同所構成，每一網域區域（Domain Zone）（如 cu.edu.tw）都有一部專屬伺服器（如 linux-2.cu.edu.tw），來負責紀錄該區域內的名稱資料（反向或正向查詢資料），同時負責被查詢的工作（但也可能一部專屬伺服器負責多個網域區域）。由此可見，除非查詢到該資料所登錄的伺服器，否則將會得不到正確的答案（這也不一定）。因此，DNS 系統的查詢動作就顯得非常困難與複雜，但首先我們來看兩個基本的查詢動作，再來看伺服器之間如何運作。 (A) 遞迴查詢與反覆查詢 『遞迴查詢』（Recursive Query）是當某一 DNS 伺服器收到查詢訊息後，而該筆資料並未登錄在伺服器上，這表示該伺服器必須向其它伺服器查詢。DNS 伺服器經由其它伺服器得知另一查詢地方，該伺服器再向另一部伺服器查詢，如此反覆而得到查詢資料的動作，稱之為遞迴查詢。另一方面，被此伺服器查詢到，而回應它到另一伺服器查詢的動作，稱之為『反覆查詢』（Iterative Query）。簡單的說，反覆查詢的動作就是伺服器回應：『資料不在我這裡，請到另一地方查詢吧！』，如果經過多個伺服器都是同樣的回應，就如同一來一往的反覆動作一樣。 (B) 搜尋順序 瞭解遞迴查詢和反覆查詢動作之後，我們用圖 5-12 來探討當一伺服器接收到客戶端 Resolver 的查詢要求時，它如何來搜尋出應該到哪一個伺服器上查詢（資料所登錄位置）的動作。譬如 DNS 客戶端要求查詢 FQDN 名稱為 www.cu.edu.tw. 的 IP 位址，而將該查詢要求傳送到特定的 DNS 伺服器上（DNS_A），所搜尋的次序如圖中的編號順序。首先，DNS_A 搜尋本身紀錄是否有該筆資料（包含 Cache Server），如果沒有便直接向根（『.』）伺服器查詢，根伺服器回應網域為 tw. 的伺服器位址（IP 位址）給 DNS_A，然後 DNS_A 再向 tw. 網域伺服器查詢，而得到網域為 edu.tw. 的伺服器位址。如此以下類推，DNS_A 得到 cu.edu.tw. 網域的專屬伺服器位址，便向它查詢而得到 www.cu.edu.tw 網域名稱的 IP 位址，再回應給 DNS 客戶端。
圖 5-12 查詢順序 由這個搜尋次序我們可以看出，所指定的 DNS 伺服器（DNS_A）每發送一個查詢後，得到下一個網域的伺服器位址，再往下一個網域伺服器查詢，直到得到答案為止，因此，DNS_A 正扮演著『遞迴查詢』的動作。另外，其它伺服器只回應：『資料不在我這裡，請到另一地方查詢吧！』，而是共同扮演著『反覆查詢』的動作。 5-3-4 DNS 伺服器種類 當 DNS Server 收到一筆並非自己管轄的網域名稱時，如果都要透過由根網域開始，經過遞迴查詢與反覆查詢，才能查出其 IP 位址的話，那麼 DNS 服務的效率實在太低了。其實，我們透過許多措施來提升查詢效率，簡單的原理是：『查詢過的資料就將它保存下來，如果有重複查詢的話，就直接回覆就好，不用再重新查詢』。儲存查詢過的資料就是『快取』(Cache)，任何一部主機或 DNS 伺服器都具有快取的功能。另外，DNS 伺服器也有許多種類，說明如下： (A) 本地快取資料庫 一般客戶端主機裡都備有『本地快取檔』（Local Cache），來登錄已查詢過的資料。任何向 DNS 伺服器查詢過的資料，都會登錄在快取擋內，因此稱之為『本地快取資料庫』（Local Cache Database），當下一次查詢同一網域名稱（FQDN）時，便可直接由快取檔回覆即可，而不用到 DNS 伺服器上查詢，這可以節省許多查詢的時間。 (B) 主機檔案 這是早期 Unix 系統上的 DNS 查詢方法，它將一些常用的主機名稱登錄在 主機檔案（/etc/hosts）內，當有查詢動作時，再到這個檔案內搜尋相對應的 IP 位址。目前這種搜尋法已漸漸不符所需，也很少人會再維護 /etc/hosts 檔案，但一般電腦系統還是會去搜尋它。 (C) 主要伺服器 表示負責某一網域區域（Domain Zone）的 DNS 伺服器，又稱為『主要伺服器』（Master Server）。有關本區域內的次網域名稱或主機名稱（FQDN），都必須向主伺服器登錄。而在主要伺服器上登錄的動作，稱之為『授權』（Authority），也就是說，除非向主要伺服器（或次要伺服器）查詢到它所管轄的資料，稱之為『授權答案』（Authoritative Answer）；否則皆稱為『非授權答案』（Non-authoritative Answer）。 (D) 次要伺服器 一部主伺服器維護一個網域區域，如果負荷很重時，無法由一部伺服器承擔負荷，此時便需另外建構一部以上的『次要伺服器』（Slave Server）來分擔負荷。基本上，次要伺服器並不負責登錄網域名稱的工作，它的資料是週期性的（一般都是 30 分鐘），由主伺服器轉移過來，這種由主伺服器轉送到次要伺服器的動作稱之為『區域轉送』（Zone Transfer）。次要伺服器除了負責客戶端的查詢動作外，另一重要的目的是作為主要伺服器資料的備份，萬一壞損時，可由次要伺服器上索取所有完整的資料。目前在 Internet 網路上有許多名稱伺服器，都有許多次要伺服器分散各地區以供查詢。 (E) 快取伺服器 『快取伺服器』（Cache Server）是紀錄 DNS 伺服器所查詢過的資料，並不同於『本地快取資料庫』，後者是在客戶端主機上；而前者是在 DNS 伺服器上。當 DNS 伺服器的查詢資料量很大時，與其相對應的快取伺服器的資料也會成長很快，因此，一般較小的系統環境可將 DNS 伺服器和快取伺服器，由同一部主機來負責，然而針對較大的系統環境，快取伺服器可與 DNS 伺服器分開安裝，由不同的主機來分別處理。也就是說，快取伺服器可以是獨立的系統，但它的資料來源仍是由該區域的 DNS 伺服器供應。快取伺服器所登錄的資料非常具有時效性，管理人員必須設定更新時間，如果某一筆資料儲存太久，其正確性就值得懷疑，必須刪除。 客戶端查詢某一筆資料時，有可能由上述伺服器中的任何一部來服務，它們之間的優先順序為如圖 5-13 所示。
圖 5-13 DNS 伺服器種類與查詢順序 5-3-5 DNS 資源紀錄 『資源紀錄』（Resource Record, RR）表示存放在 DNS 伺服器上，提供一般客戶端查詢的資料。我們在前面談過，DNS 系統是整個 Internet 網路的核心，它不僅提供網域名稱和主機位址（IP）之間的轉換查詢，還提供許多有關 Internet 網路上許多資訊，這些資訊便是 DNS 系統上所紀錄的資源紀錄。當然，一個 DNS 系統所能提供的資源紀錄愈完整，對它所能提供的服務也愈完善，在 RFC 1035 上有許多資源紀錄的規範，但並不是所有 DNS 伺服器都提供這些服務，這需要管理人員耐心設定才可達成。以下介紹較常用的資源紀錄（RR）。
5-3-6 DNS 封包格式 圖 5-13-1 (a) 為 DNS 訊息封包格式，它如同一般協定一樣，都是以 IP 封包傳送，並且採用 UDP 傳輸方式，連接在著名埠口 53（53/udp）。不論 DNS 客戶端和伺服器之間，或伺服器和伺服器之間都採用此封包格式，它可區分為四大部份，以下分別介紹之。
圖 5-13-1 DNS 訊息封包格式 (A) DNS Header 圖 5-13-1 (b) 為 DNS 訊息標頭格式，由此標頭可以分辨查詢或回覆型態，各欄位功能如下： ● 識別碼（Identifier, ID）：此 16 位元識別碼的內容是由客戶端所設定，標示所詢問訊息的號碼，伺服端也按照這識別碼回應所詢問的訊息，客戶端再依照這個號碼比對是否為自己所發出的詢問訊息。 ● 旗標（Flag）：這 16 位元旗標示用來描述此 DNS 訊息封包的功能，各欄位功能如下： QR（Question/Response）、OP-code（Operating Code）、AA（Authoritative Answer）、TC（Truncated）、RD（Recursive Desired）、RA（Recursive Available）、R-code（Response Code）。 ● 問題計數（Question Count）：表示後面緊接著問題區段的數量，圖 13-7 (c) 表示本查詢問題為一筆。 ● 答案 RR 計數（Answer RR Count）：表示後面緊接著答案區段中資源紀錄（Resource Record, RR）的數量，如圖 13-7 (d) 為一筆答案的格式。 ● 權威計數（Authority Count）：權威區段的紀錄數量。 ● 增加紀錄計數（Addition Records Count）：此欄位為增加權威區段中紀錄的數量。 (B) Question Section 『問題區段』（Question Section）是客戶端（或伺服器）向名稱伺服器查詢時，所攜帶 FQDN 名稱所儲存的位置。一般來講，客戶端每次向名稱伺服器查詢一個 FQDN 名稱（Question Count = 1），其問題區段格式如圖 5-13-1 (c)所示。然而客戶端並非每次都只查詢一筆資料，如需要詢問多筆資料時，則會在問題計數欄位中指明後面緊接著有幾個問題區段。各問題區段的功能如下： ● 問題名稱（Question Name）：此欄位存放所欲查詢的 FQDN 名稱，每一名稱長度不定，因此，此欄位的長度也不定。 ● 問題型態（Question Type）：長度為 16 位元，表示要查詢該名稱的資源紀錄（Resource Record, RR）型態，常用之紀錄型態如下：
● 問題類別（Question Class）：通常都為 1（IN），表示 Internet 通訊協定的位址，如果不是 1，則表示其他網路型態（非 IP 位址格式）。 (C) Answer Section 『答案區段』（Answer Section）裡所存放的是被查詢之名稱伺服器所回應資料，一般查詢都只是一筆資料（Answer RR Count = 1），其格式如圖 5-13-1 (d) 所示，如有多筆資料回應，則會在答案計數欄位中指明有幾筆資源紀錄（RR）。答案區段中各欄位功能如下 ▲ 資源名稱（Resource Name） ▲ 資源型態（Resource Type） ▲ 資源類別（Resource Class）。 ▲ 存活時間（Time-To-Live, TTL） ▲ 資源資料長度（Resource Data Length）。 ▲ 資源資料（Resource Data）。 5-3-7 DNS 系統規劃與建置 (A) 網路規劃與建置 我們利用 Cisco Packet Tracer 規劃與建置 DNS 系統，來觀察它的運作模式。雖然如此建立的系統是模擬真實情況，但幾乎能與真實網路完全相符。吾人需選擇下列元件來建置： (1) Server-PT：模擬伺服器主機。於該主機上可選擇開啟多種服務，譬如： HTTP、DHCP、DNS、FTP 等伺服器功能，本範例選擇開啟 DNS 服務。 (2) PC-PT：模擬客戶端主機。該主機上提供多種客戶端套件，譬如：Terminal、Command Prompt、Web Browser、Email 等等。本範例選擇使用 Command Prompt 介面。 (3) 2960-24TT。模擬 24 埠口 Layer 2 交換器。作為連結 Server-PT 與 PC-PT 的設備。 另外，吾人選擇 192.168.0.0/24 私有網路區段，並指定 192.168.0.254 為 Default Gateway 與 DNS = 168.95.1.1，雖然本範例沒有用到此功能，但還是依照標準作業程序完成它。主機的 IP 位址設定與連接埠口位置，如下表所示：(請自行輸入主機的網路參數) (C) 規劃網路架構
依照上述參數建構網路型態如下：[請下載：DNS Server 系統.pkt] 圖 5-14 DNS 網路系統 (B) 伺服器設定與連線 (1) 步驟 1：由 DNS_Server 上開啟 DNS 服務，並輸入下列資源紀錄。說明如下：
(2) 步驟 2：於 PC0 上開啟 Desktop => Command Prompt，並輸入：
(3) 步驟 3：於 Http_Server 上開啟 Desktop => Command Prompt，並輸入：
5-3-8 DNS 協定分析 一般主機透過 DNS 伺服器詢問網域名稱的相對應 IP 位址之後，會將結果儲存 DNS Cache 內，下次遇到相同的網域名稱，就不需要發動 DNS 詢問程序，直接取用即可。在 Windows 系統下可執行 ipconfig 命令將 DNS Cache 清除，如此才可以強迫主機發動詢問程序，如下：
但 Packet Tracer 模擬系統並沒有 DNS Cache 功能，因此，擷取 DNS 封包之前，不需要清除它。 (A) Packet Tracer 擷取封包 (1) 設定 Packet Tracer 為 Simulation Mode，並擷取 DNS 與 ICMP 封包。 (2) 由 PC0 上開啟 Desktop => Command Prompt，並輸入：> ping www.tsnien.idv.tw 擷取到封包如下圖：
(B) DNS Query封包 此封包是 PC0 向 DNS Server (192.168.0.252) 詢問 URL = www.tsnien.idv.tw 的 IP 位址如何？
得到下列結果：
(C) DNS Answer封包 此封包是 DNS Server 回應 PC0 詢問的封包。
得到下列結果：
(D) ICMP/ping 封包 當 PC0 得到 www.tsnien.idv.tw 網址相對應的 IP 位址後，則利用此 IP 位址發送 ICMP，擷取封包內容如下：
得到下列結果：
|
翻轉工作室：粘添壽
網路規劃與管理技術：
翻轉電子書系列：
|
||||||||||||||||||||||||||||||||||||||||||||||
