第 13 章 DNS 著作權所有 © 旗標出版股份有限公司

本章提要 DNS 基礎 DNS 的架構 DNS 名稱查詢流程 DNS 資源紀錄 DNS 封包格式 擷取 DNS 封包

DNS 我們能利用易懂易記的名稱來和對方溝通, 是因為有 DNS (Domain Name System, 網域名稱系統) 的存在！ 透過 DNS, 我們可以由一部主機的完整網域名稱 (FQDN, Fully Qualified Domain Name) 查到其 IP 位址, 也可以由其 IP 位址反查到主機的完整網域名稱。

完整網域名稱 所謂完整網域名稱 (FQDN, Fully Qualified Domain Name) 是由主機名稱+ 網域名稱+. 所組成, 以『www.flag.com.tw.』為例： www：就是這台 Web 伺服器的主機名稱。 flag.com.tw.：就是這台 Web 伺服器所在的網域名稱。

完整網域名稱 請注意, 光是『www.flag.com.tw』還不算是 FQDN, 真正標準的 FQDN 應該是『www.flag.com.tw.』！就是多了最後的那一點, 就成為標準的 FQDN 了！ 最後這一個『.』代表在 DNS 架構中的根網域 (Root Domain)。 還有, 整個 FQDN 的長度不得超過 255 個字元 (包含『.』), 而不管是主機名稱或是網域名稱, 都不得超過 63 個字元。

DNS 名稱解析 在 DNS 還沒出現前, 其實就已經有電腦名稱和 IP 位址的查詢機制, 也就是利用 Host file (主機檔案) 來做轉換的動作。 Host file 的格式如下： Host file 的格式很簡單, 就是 IP 位址和FQDN 的對照而已。

DNS 名稱解析 因為 Host file 屬於單機使用, 無法分享給其他電腦, 所以若要讓每台電腦都能利用相同的 FQDN 連結到相同的主機, 就必須為每一台電腦建立一份 Host file, 而若是某一台主機的 FQDN 變更, 就得到每一台電腦去更正。 網際網路盛行, 網路上的主機數量數都數不清, 要想使用 Host file 做 FQDN 的轉換, 已不可行, 為此便發明了 DNS 系統。

DNS 名稱解析 DNS 系統是由 DNS 伺服器 (DNS Server) 和 DNS 用戶端 (DNS Client)所組成。 當使用者輸入一個 FQDN 後, DNS 用戶端會向 DNS 伺服器要求查詢此 FQDN 的 IP 位址, 而伺服器則會去對照其資料庫內的資料, 並將 IP位址回覆給用戶端。

DNS 名稱解析 用戶端要求伺服器由 FQDN 查出 IP 位址的動作稱之為正向名稱查詢 (Forward Name Query), 一般就直接說名稱查詢, 而伺服器查出 IP 位址並回傳給用戶端的動作就叫做正向名稱解析 (Forward Name Resolution), 一般又簡稱為名稱解析。

DNS 的架構

DNS 的架構 整個 DNS 系統是由許多的網域 (Domain) 所組成, 每個網域下又細分更多的網域, 這些細分的網域又可以再切割成更多的網域, 不斷的循環下去。 每個網域最少都由一台 DNS 伺服器管轄, 該伺服器就只需儲存其管轄網域內的資料, 同時向上層網域的 DNS 伺服器註冊, 例如：管轄『.flag.com.tw.』的 DNS 伺服器就要向管轄『.com.tw.』的伺服器註冊, 層層向上註冊, 直到位於樹狀階層最高點的 DNS 伺服器為止。

DNS 的架構 除了查詢效率的考量外, 為方便管理及確保網路上每一台主機的 FQDN 絕對不會重覆, 因此整個 DNS 架構就設計成 4 層： 根網域 (Root Domain) 頂層網域 (Top Level Domain) 第二層網域 (Second Level Domain) 主機 (Host)

根網域 這是 DNS 架構的最上層, 當下層的任何一台 DNS 伺服器無法解析某個 DNS 名稱時, 便可以向根網域的 DNS 伺服器尋求協助。 理論上, 只要所尋找的主機有按規定註冊, 那麼無論它位於何處, 從根網域的 DNS 伺服器往下層尋找, 一定可以解析出它的 IP 位址。

頂層網域 在美國以外的國家, 大多以 ISO 3116 所制定的國碼 (Country Code) 來區分, 例如：tw 為台灣、jp 為日本、ca 為加拿大...等：

頂層網域 在美國, 雖然也有 us 這個國碼可用, 可是卻較少用來當成頂層網域。反而是以組織性質來區分, 例如：com 代表一般營利機構；org 代表非營利機構；edu 代表教育機構等等。

頂層網域

頂層網域 在其它文件看到的說明, 或許和本節的敘述有差異, 這倒是很正常的。因為此層的命名方式持續在演變, 所以在不同時間、文獻的記載都有差異。 其實不必拘泥於 ccTLD 或 gTLD 這些名稱, 重點在於建立 DNS 架構的階層觀念即可。

第二層網域 在台灣我們採用的是 ccTLD 的命名方式, 因此這一層即為 .com、.net...等等以組織性質區分的網域, 而再細分下去的網域也全都隸屬於這一層中。 例如：『.com.tw.』是屬於這一層的網域, 而再細分下去的網域『.flag.com.tw.』、『.testguy.com.tw.』也同屬於這一層。

第二層網域 第二層網域可說是整個 DNS 系統中最重要的部分。 雖然世界各國所制定的組織性質名稱不一定相同 (例如：我國採用 .com 表示營利機構, 但日本採用 .co 表示), 但在這些類別網域之下都開放給所有人申請, 名稱則由申請者自訂, 例如：旗標出版公司就是『.flag.com.tw.』。

第二層網域 每個網域名稱在這一層必須是唯一不可重覆的。例如：旗標出版公司申請了『.flag.com.tw.』, 則其他公司可以申請『.flag.org.tw.』但絕對不能再申請『.flag.com.tw.』這個名稱。 當我們在申請網域名稱時, 若是已經註冊有案的名稱, 負責審核網域名稱的機構是不會核准的, 例如：『.flag.com.tw.』、『.yahoo.com.』等都是已經註冊有案的網域名稱, 就不能再申請。

主機 最後一層是主機, 也就是隸屬於第二層網域的主機, 這一層是由各個網域的管理員自行建立, 不需要透過管理網域名稱的機構。 例如：我們可以在『.flag.com.tw.』這個網域下再建立『www.flag.com.tw.』、『ftp.flag.com.tw.』及『username.flag.com.tw.』等主機。

DNS 區域 雖然說每個網域都至少要有一部 DNS 伺服器負責管理, 但是我們在指派 DNS 伺服器的管轄範圍時, 並非以網域為單位, 而是以區域 (Zone) 為單位。 換言之, 區域是 DNS 伺服器的實際管轄範圍。舉例而言, 倘若 flag 網域的下層沒有子網域, 那麼 flag 區域的管轄範圍就等於 flag 網域的管轄範圍。

DNS 區域

DNS 區域 但是, 若 flag 網域的下層有子網域, 假設為 sales 和 product, 則我們可以將 sales 網域單獨指派給 X 伺服器管轄；其餘的部份則交給 Y 伺服器管轄。 也就是說, 在 X 伺服器建立了『sales 區域』, 這個 sales 區域就等於 sales 網域；在 Y 伺服器建立了『flag 區域』, 而 flag 區域的管轄範圍是『除了sales 網域以外的 flag 網域』。

DNS 區域

DNS 區域

DNS 區域 從上圖可知, 當獨立成區域的子網路愈多, flag 區域和 flag 網域所管轄範圍的差異就愈大。簡言之, 區域可能等於或小於網域, 當然絕不可能大於網域。 此外, 能被併入同一個區域的網域, 必定是有上下層緊鄰的隸屬關係。不能將沒有隸屬關係的網域, 或是雖有上下層關係、但未緊鄰的網域, 劃分為同一個區域。

DNS 區域

DNS 伺服器類型 每個區域都會有一部 DNS 伺服器負責管理, 但是假設這台伺服器當掉, 則該區域的用戶端將無法執行名稱解析與名稱查詢工作！ 為了避免這種情形, 我們可以把一個區域的資料交給多部 DNS 伺服器負責。

DNS 伺服器類型 當我們將一個區域交給多台伺服器管理時, 就會有主要名稱伺服器 (Primary Name Server) 和次要名稱伺服器(Secondary Name Server) 的分別。另外, 還有快取伺服器 (Cache Only Server)。

主要名稱伺服器 主要名稱伺服器 (Primary Name Server) 儲存區域內各台電腦資料的正本, 而且以後這個區域內的資料有所變更時, 也是直接寫到這台伺服器的資料庫, 這個資料庫通稱為區域檔案 (Zone File)。 一個區域必定要有一部, 而且只能有一部主要名稱伺服器。

次要名稱伺服器 次要名稱伺服器 (Secondary Name Server) 會定期向另一部名稱伺服器拷貝區域檔案, 這個拷貝動作稱為區域傳送 (Zone Transfer), 區域傳送成功後會將區域檔案設為唯讀 (Read Only) 屬性。 換言之, 要修改區域檔案時, 不能直接在次要名稱伺服器修改。

次要名稱伺服器 一個區域可以沒有次要名稱伺服器, 或擁有多部次要名稱伺服器。 通常是為了容錯 (Fault Tolerance) 考量, 才會設立次要名稱伺服器。 然而, 在用戶端也必須設定多部 DNS 伺服器, 才可以在主要名稱伺服器無法服務時, 自動轉接次要名稱伺服器。

快取伺服器 快取伺服器 (Cache Only Server) 是很特殊的 DNS 伺服器類型, 它本身並沒有管理任何區域, 但是 DNS 用戶端仍然可以向它要求查詢。 快取伺服器會向指定的 DNS 伺服器查詢, 並將查到的資料存放在自己的快取內, 同時也回覆給 DNS 用戶端。當下一次 DNS 用戶端再查詢相同的 FQDN 時, 就可以從快取查出答案, 不必再請指定的 DNS 伺服器查詢, 節省了查詢時間。

快取伺服器 舉例來說：假設總公司和分公司隸屬於相同區域, 彼此之間以 64 Kbps 專線連接,而且兩邊都擁有 DNS 伺服器。 若採用主要名稱伺服器+次要名稱伺服器架構, 當這兩部伺服器在區域傳送時, 便可能佔用大量的專線頻寬, 降低網路效率。 此時, 就適合改用主要名稱伺服器+快取伺服器架構, 由於沒有區域傳送的問題, 因此不會佔用大量的專線頻寬。

快取伺服器 一旦重新啟動快取伺服器時, 會完全清除快取中的資料。而它本身又沒有區域檔案, 所以每次的查詢都得求助於指定的 DNS 伺服器, 因此初期的查詢效率會較差。必須等到快取中累積大量的資料後, 查詢效率才會提升。

DNS 名稱查詢流程 當我們使用瀏覽器閱讀網頁時, 在網址列輸入網站的 FQDN 後, 作業系統會呼叫解析程式 (Resolver, 亦即用戶端負責 DNS 查詢的 TCP/IP軟體), 開始解析此 FQDN 所對應的 IP 位址。

DNS 名稱查詢流程

DNS 名稱查詢流程 首先解析程式會去檢查本機的快取記錄, 如果我們從快取內即可得知 FQDN 所對應的 IP 位址, 就將此 IP 位址傳給應用程式 (在本例為瀏覽器), 如果在快取中找不到的話, 則會進行下一步驟。 若在本機快取中找不到答案, 接著解析程式會去檢查 Host File, 看是否能找到相對應的資料。

DNS 名稱查詢流程 若還是無法找到對應之 IP 位址, 則向本機指定的 DNS 伺服器要求查詢。DNS 伺服器在收到要求後, 會先去檢查此FQDN 是否為管轄區域內的網域名稱。若然, 則會檢查區域檔案 (Zone File), 看是否有相符的資料, 反之則進行下一步驟。 區域檔案中若找不到對應的 IP 位址, 則DNS 伺服器會去檢查本身所存放的快取, 看是否能找到相符合的資料。

DNS 名稱查詢流程 如果很不幸的還是無法找到相對應的資料, 那就必需借助其它的 DNS 伺服器了！這時候就會開始進行伺服器對伺服器之間的查詢動作。 由上述的 5 個步驟, 我們應該能很清楚的了解 DNS 的運作過程, 而事實上, 這 5 個步驟可以分為兩種查詢模式, 即用戶端對伺服器的查詢 (第 3、4 步驟) 及伺服器和伺服器之間的查詢 (第 5 步驟)。

遞迴查詢 DNS 用戶端要求 DNS 伺服器解析 DNS 名稱時, 採用的多是遞迴查詢 (Recursive Query)。 1. 若 DNS 伺服器本身具有的資訊足以解析該項查詢, 則直接回應用戶端其查詢之名稱所對應的 IP 位址。

遞迴查詢 2. 若 DNS 伺服器本身無法解析該項查詢時, 會嘗試向其他 DNS 伺服器查詢。 3. 若其他 DNS 伺服器無法解析該項查詢時, 則告知用戶端找不到資料。 從上述過程可得知, 當 DNS 伺服器收到遞迴查詢時, 必然會回應用戶端其查詢之名稱所對應的 IP 位址, 或者是通知用戶端找不到資料, 而絕不會是告知用戶端去查詢另一部 DNS 伺服器。

反覆查詢 反覆查詢 (Iterative Query) 一般多用在伺服器對伺服器之間的查詢動作。這個查詢方式就像是對話一樣, 整個作業會在伺服器間一來一往, 反覆的查詢而完成。 舉例來說：假設用戶端向指定的 DNS 伺服器要求解析『www.flag.com.tw.』位址, 當伺服器中並未有此筆記錄時, 反覆查詢的流程：

反覆查詢的流程

轉送程式 當 DNS 用戶端向指定的 DNS 伺服器要求名稱查詢時, 若伺服器無法解析, 雖然可以轉向根網域的 DNS 伺服器詢問, 不過為了節省頻寬及安全上的考量, 或許我們不希望直接問到根網域 DNS 伺服器去, 所以我們可以設定轉送程式 (Forwarder)。

轉送程式 轉送程式的功能就是將用戶端的要求導向特定的 DNS 伺服器, 例如：當用戶端向 X DNS 伺服器查詢『www.nctu.edu.tw』的 IP 位址時, 若在 X DNS 伺服器找不到記錄, 則透過轉送程式的設定, 將要求引導到 Y DNS 伺服器 (如下圖的第 1 步驟)。 如果在指定的時間內沒有收到回應, 則 X 伺服器可以再轉向根網域 DNS 伺服器詢問 (如下圖的第 2 步驟), 或是直接告訴用戶端找不到其所要求的資料。

轉送程式

完整的查詢流程 將遞迴查詢和反覆查詢合而為一：

DNS 資源紀錄 當我們建立好區域之後, 就必須在區域檔案內新增資料, 而這些資料就是所謂的資源紀錄 (Resource Record)。 SOA (Start of Authority, 起始授權) 用來記錄此區域的授權資訊, 包含主要名稱伺服器與管理此區域的負責人之電子郵件帳號、修改的版次、每筆紀錄在快取中存放的時間等等。

DNS 資源紀錄 NS (Name Server, 名稱伺服器) A (Address, 位址) 用來記錄管轄此區域的名稱伺服器, 它包含了主要名稱伺服器和次要名稱伺服器。 A (Address, 位址) 此紀錄表示 FQDN 所對應的 IP 位址, 也就是當我們在做正向名稱解析時會對照的資料。

DNS 資源紀錄 CNAME (Canonical Name, 別名) 記錄某台主機的別名。我們可以為一台主機設定多個別名, 例如當 Web 伺服器和 FTP 伺服器皆為同一部主機時, 就可以使用 CNAME 讓不同的 FQDN 連結同一部主機。

DNS 資源紀錄 MX (Mail Exchanger, 郵件交換器) 用來設定此一網域所使用的郵件伺服器。每一個網域並不限定只能有一部郵件伺服器, 不過當我們指定多部郵件伺服器時, 就必須為它們設定一個代表優先順序的數字, 數字愈小者, 優先順序愈高, 也就是說 0 為最高優先順序。

DNS 資源紀錄 PTR (Pointer, 反向查詢指標) HINFO (Host Information, 主機資訊) 當我們在做反向查詢 (由 IP 位址查出 FQDN) 時, 便會利用此種紀錄類型。 HINFO (Host Information, 主機資訊) 用來儲存某一主機的軟硬體資料, 例如 CPU 的類型、作業系統的類型等。當有人查詢時, DNS 會將我們定義的資料回應給查詢者。

DNS 封包格式 在傳輸層 (Transport Layer) 傳送 DNS 封包時, 採用的是 UDP 協定, 所使用的 UDP Port 編號為 53。

DNS 封包格式 表頭 (Header) 的部分長度固定為 12 Bytes, 而其餘長度則不固定；另外, 除了Question Section, 其它 3 個 Section 未必在每個 DNS 封包中都出現, 而是視需要使用。 例如：用戶端要求查詢 FQDN 時, 就不需要其它 3 個 Section, 但是 DNS 伺服器回覆時, 就會使用到『Answer Section』。

DNS 封包表頭

DNS 封包表頭欄位的意義 Query Identifier (Query ID, 查詢編號) DNS 的封包編號, 長度為 16 Bits。當發送端送出查詢封包時會自動產生此編號, 而收到回覆的封包時, 也會檢查此編號, 辨識此回覆封包是回應那一個查詢封包。 Request/Response (QR, 要求/回覆) 長度為 1 Bit, 當欄位值為 0 時, 表示是 Request (要求查詢) 封包, 為 1 則表示 Response (回覆) 封包。 Operation Code (OP Code, 操作代碼) 長度為 4 Bit, 用來識別這個 DNS 封包的類型。

DNS 封包類型

DNS 封包表頭 Flags 長度為 4 Bits： 每個 Bit 代表的意義如下表：

DNS 封包表頭 Return Code (R Code, 回覆代碼) 長度為 4 Bit, 表示在 DNS 查詢時所發生的錯誤訊息：

DNS 封包表頭 Reserved Question count Answer RR Count Authority RR Count 保留未使用, 長度為 3 Bit, 欄位值全為 0。 Question count 存放 Question Section 欄位的資料筆數。 Answer RR Count 存放 Answer Section 欄位的資料筆數。 Authority RR Count 存放 Authority Section 欄位的資料筆數。 Additional RR Count 存放 Additional Section 欄位的資料筆數。

Question Section (查詢部分) Question Name 此欄位存放的是所要解析的 FQDN, 因此長度不固定。

Question Section (查詢部分) Question Type 長度為 2 Bytes, 表示要查詢的資源記錄類型。

Question Section (查詢部分) Question Class 這個欄位表示要在那一類的網路上做 DNS 查詢, 目前僅有使用 IN(Internet) 而已, 欄位值固定為 1。

Answer Section (回應部分)

Answer Section (回應部分) Resource Name (資源名稱) Resource Type (資源記錄類型) 存放查詢的 FQDN, 欄位長度視 FQDN 長度而定。 Resource Type (資源記錄類型) 存放此次查詢的資源記錄類型, 相當於前述Question Section 中的 Question Type 欄位, 長度為 16 Bits。

Answer Section (回應部分) Resource Class (資源類型) TTL (存活時間) 表示查詢的 FQDN 所屬的網路類型, 目前都是屬於 Internet 網路, 所以欄位值固定為 1。 TTL (存活時間) 長度為 32 Bits, 表示此筆資料保留在 DNS 伺服器快取中的時間, 以秒為計量單位, 若為　0, 表示不存放在快取中。

Answer Section (回應部分) Resource Data Length Resource Data 長度為 16 Bits, 存放 Resource Data 欄位的長度, 以 Byte 為單位。 Resource Data 存放查詢的結果, 通常是存放 IP 位址或FQDN。欄位長度不一定, 視資料格式不同而改變。

Authority Section (授權部分) 此部分表示在查詢 FQDN 時, 所找到可供查詢的 DNS 伺服器資訊, 其格式如同Answer Section, 亦包括 6 個欄位, 除了最後一個欄位 Resource Data 存放的不是 IP 位址, 而是 DNS 伺服器的 FQDN 之外, 其餘欄位的意義都相同。

Additional Records Section (額外記錄部分) 當 Authority Section 有存放資料時, Additional Records Section 就會有相對應的資料, 也就是說在 Authority Section 有 3 筆資料, 在這個部分也就會存放 3 筆資料。

Additional Records Section (額外記錄部分) Additional Records Section 也包含了 6 個欄位, 意義同前, 不過要注意的是 Resource Name 和 Resource Data 這兩個欄位並不是存放查詢的 FQDN 資料, 而是存放 Authority Section 中所記錄的 DNS 伺服器名稱及其 IP 位址。

擷取 DNS 封包 以 Windows XP 為 DNS 用戶端, IP 位址為 61.218.38.45；以 Linux RedHat 8.1 為用戶端預設的 DNS 伺服器 (後文簡稱為 Local 伺服器), IP 位址為 61.218.38.44 。 在 DNS 用戶端向 Local 伺服器查詢『www.openfind.com.tw』的 IP 位址時, 總計擷取到 15 個封包, 經分析過濾後得知哪些封包為配對的查詢 / 回覆封包：

擷取 DNS 封包

用戶端向 Local 伺服器查詢

用戶端向 Local 伺服器查詢 此封包為查詢封包 (在 NetAnalyzer 係以 Query、而不以 Request 代表查詢封包)。 此封包為標準查詢封包。 此封包為完整封包。 使用遞迴 (Recursive) 查詢, 這是用戶端對 DNS 伺服器最常採用的方式。 所要查詢的 FQDN 。 要查詢該 FQDN 對應的 IP 位址。 此查詢是在 Internet 進行。

Local 伺服器詢問其它 DNS 伺服器 Local DNS Server 首先詢問 Root DNS Server－192.58.128.30。 Root DNS Server 告知管轄 .tw 網域的各 DNS Server 的 IP 位址, 請 Local DNS Server 改問管轄 .tw 網域的其中一部 DNS Server：

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器 Transaction ID 相同, 表示兩者為配對的查詢 / 回覆封包。 此封包為查詢封包。 此封包為回覆封包。 不使用遞迴 (Recursive) 查詢, 意即使用反覆 (Iterative) 查詢。這是 DNS 伺服器彼此之間最常採用的方式。 要查詢『www.openfind.com.tw』這個FQDN 對應的 IP 位址。

Local 伺服器詢問其它 DNS 伺服器 Root DNS 伺服器告知 Local DNS 伺服器, 應該向這些 DNS 伺服器其中之一查詢。這些 DNS 伺服器的 FQDN 在 Authoritative nameservers 和 Additional records 都會出現, 但 IP 位址只出現在 Additional records。

Local 伺服器詢問其它 DNS 伺服器 Local DNS Server 詢問管轄 .tw 網域的DNS Server－A.DNS.TW, 但是A.DNS.TW 告知管轄 .com.tw 網域的各DNS Server 的 IP 位址, 請 Local DNS Server 改問管轄 .com.tw 網域的其中一部DNS Serve：

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器 Local DNS 伺服器向 A.DNS.TW 這部伺服器查詢 (根據圖13-22 可知 203.73.24.8 為 A.DNS.TW 的 IP 位址）。 Transaction ID 相同, 表示兩者為配對的查詢/回覆封包。 此封包為查詢封包。 此封包為回覆封包。 不使用遞迴 (Recursive) 查詢, 意即使用反覆 (Iterative) 查詢。

Local 伺服器詢問其它 DNS 伺服器 要查詢『www.openfind.com.tw』這部主機的 IP 位址。 A.DNS.TW 伺服器告知 Local DNS 伺服器, 應該向這些 DNS 伺服器其中之一查詢。 這是 IPv6 表示 IP 位址的方式。

IPv6 表示 IP 位址的方式

Local 伺服器詢問其它 DNS 伺服器 Local DNS Server 詢問管轄 .com.tw 網域的 DNS Server－B.TWNIC.NET.TW, 但是B.TWNIC.NET.TW 告知管轄openfind.com.tw 網域的兩部 DNS Server 的 IP 位址, 請 Local DNS Server 改問這兩部 DNS Serve 的其中一部：

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器 Local DNS 伺服器向 B.TWNIC.NET.TW 這部伺服器查詢。 Transaction ID 相同, 表示兩者為配對的查詢/回覆封包。 此封包為查詢封包。 此封包為回覆封包。

Local 伺服器詢問其它 DNS 伺服器 不使用遞迴 (Recursive) 查詢, 意即使用反覆 (Iterative) 查詢。 B.TWNIC.NET.TW 伺服器告知 Local DNS 伺服器, 應該向這兩部 DNS伺服器其中之一查詢。

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器

Local 伺服器詢問其它 DNS 伺服器 Local DNS 伺服器向 OPENFIND.COM. TW 這部伺服器查詢。 Transaction ID 相同, 表示兩者為配對的查詢/回覆封包。 此封包為查詢封包。 此封包為回覆封包。 不使用遞迴 (Recursive) 查詢, 意即使用反覆 (Iterative) 查詢。 此欄位值為 1, 代表在 Answer Section 有 1 筆查到的資料。 所查到的 IP 位址與相關資料。

Local 伺服器回覆 DNS 用戶端

Local 伺服器回覆 DNS 用戶端 此 Transaction ID 與圖 12-20 的查詢號封包相同, 代表此封包是回覆用戶端向 Local 伺服器的查詢。 在 Answer Section 有 1 筆查到的資料。 查到的是主機的 IP 位址。 這筆紀錄在 DNS 伺服器快取中的存活時間。 查到的 IP 位址長度為 4 Bytes。 這就是用戶端所要查詢的 IP 位址。