【計算機網路筆記】2.4 DNS—The Internet’s Directory Service

Hello Guys, I’m LukeTseng. 歡迎你也感謝你點入本篇文章，本系列主要讀本為《Computer Networking: A Top-Down Approach, 8th Edition》，就是計算機網路的聖經，會製作該系列也主要因為修課上會用到。若你喜歡本系列或本文，不妨動動你的手指，為這篇文章按下一顆愛心吧，或是追蹤我的個人公開頁也 Ok。

2.4.1 Services Provided by DNS（由 DNS 提供的服務）

什麼是 DNS？

DNS（Domain Name System，網域名稱系統）就像是網際網路的「電話簿」，負責將人類好記的網址翻譯成電腦能理解的 IP 位址。

當在瀏覽器輸入 google.com 這種人類好記的網址時，電腦其實看不懂。

電腦需要透過 DNS 把網址翻譯成一串數字構成的 IP 位址（例如 142.250.190.46），才能正確連接到該網站的伺服器。

DNS 也是一個建立在應用層上的協定，它主要由兩部分組成：

  1. 分散式資料庫（Distributed Database）：實作在階層式的 DNS 伺服器群上。
  2. 應用層協定（Application Protocol）：允許主機（Host）查詢該資料庫的通訊規則。

運作層級

注意：

  • DNS 協定是運作在 UDP 之上，使用 Port 53。
  • 它雖然是網際網路的核心功能，但在架構上是作為應用層（Application Layer）協定來實作的，也體現了網際網路將複雜性放在網路邊緣（Network Edge）的設計哲學。

術語解析

  • 主機名稱（Hostname）：人類可讀的網址標識，例如 www.google.com。它對人類有意義，但對路由器來說只是無意義的字串。
  • IP 位址（IP Address）：32-bit 的數值（IPv4），具有階層結構，就像現實世界的門牌地址，讓路由器知道該把封包送往哪個網路。
  • 正規主機名稱（Canonical Hostname）：一台主機真正的、正式的名字，通常比較複雜且難記（例如 relay1.west-coast.enterprise.com）。
  • 別名主機名稱（Alias Hostname）：為了方便人類記憶而取的別名（例如 www.enterprise.com），通常比規範名稱簡短好記。

DNS 的主要服務：主機名稱到 IP 位址的轉換

這是 DNS 最基本的功能。

當瀏覽器想要存取 www.someschool.edu 時，會發生以下步驟：

  1. 使用者主機執行 DNS 的客戶端程式。
  2. 瀏覽器從 URL 中提取主機名稱 www.someschool.edu 並傳給 DNS 客戶端。
  3. DNS 客戶端向 DNS 伺服器發送一個查詢訊息（Query message）。
  4. DNS 客戶端最後收到一份回覆，裡面包含該主機名稱對應的 IP 位址。
  5. 瀏覽器拿到 IP 後，才正式向該 IP 發起 TCP 連線，連線到位於該 IP 位址 Port 80 上的 HTTP 行程。

DNS 的三大進階服務

除了轉址，DNS 還利用其資料庫特性提供了以下服務：

  1. 主機別名（Host Aliasing）：
    • 說明：允許一台主機擁有多個名字。DNS 可以找出別名背後的「正規主機名稱」以及對應的 IP。
    • 範例說明：一台名為 relay1.west-coast.enterprise.com 的複雜主機，可以擁有 www.enterprise.com 這樣好記的別名。
  2. 郵件伺服器別名（Mail Server Aliasing）：
    • 說明：讓電子郵件地址也能使用簡單好記的別名，而不必使用複雜的郵件伺服器名稱。
    • 範例說明：
      • Bob 的信箱是 bob@yahoo.com，但 Yahoo 的郵件伺服器本名可能叫 relay1.west-coast.yahoo.com。
      • DNS 透過 MX 記錄 來處理這種轉換。
  3. 負載分配（Load Distribution）：
    • 說明：
      • 對於高流量的網站（如 CNN），背後其實是多台重複的伺服器在運作，它們有不同的 IP，因此 DNS 也可用在重複的伺服器上。
      • DNS 資料庫會將一個域名對應到一組 IP 位址集合。
    • 範例說明：
      • 當有人查詢 cnn.com 時，DNS 伺服器會回傳整組 IP，但會輪替（Rotate）這些 IP 的順序。
      • 因為客戶端通常只選第一個 IP 連線，流量就會被平均分配到不同伺服器上。

關於「負載分配」，這是一個非常聰明的設計。

DNS 伺服器不需要知道哪台機器現在比較忙，只需要在每次回覆時洗掉 IP 列表的順序，就能達到基本的流量分流效果。

2.4.2 Overview of How DNS Works（綜觀 DNS 如何運作）

該節展示了電腦科學中一個核心的設計哲學：如何透過「階層化」與「分散式」設計來解決規模擴展（Scalability）的問題。

為什麼不能只有一台 DNS 伺服器？

若設計一個單一的、集中式的（Centralized）DNS 伺服器來服務全網際網路，會發生什麼事？

書中列舉四項可能導致的災難（這也是為什麼我們需要分散式系統的原因）：

  1. 單點失效（Single point of failure）：這台伺服器掛了，全求網路就癱瘓了。
  2. 流量過載（Traffic volume）：一台機器無法處理全球數十億的查詢請求。
  3. 遠距離集中式資料庫（Distant centralized database）：如果伺服器在紐約，澳洲的用戶查詢就要跨越半個地球，延遲（Delay）會非常高。
  4. 維護困難（Maintenance）：要將全球所有的新增主機都記錄在同一個資料庫中，更新會極度頻繁且困難。

結論：DNS 必須設計成分散式（Distributed）且階層式（Hierarchical）的資料庫系統。

DNS 的階層結構（The DNS Hierarchy）

為了不讓單一伺服器崩潰，DNS 將全球的伺服器分成了三個主要的層級。

把它想像成是一棵倒過來的樹：

  1. 根 DNS 伺服器（Root DNS Servers）
    • 地位：最高等級的伺服器。
    • 數量：全球有 13 個邏輯上的根 IP 位址（由 12 個不同的組織管理），但在物理上這 13 個 IP 對應著分佈在全球的 1000 多台伺服器實體。
    • 功能：它不直接知道使用者要找的網站 IP（例如 google.com），但它知道誰負責管理 .com、.edu 這些高階網域，會指引使用者去問下一層。
  2. 高階網域伺服器（Top-Level Domain, TLD Servers）
    • 地位：負責高階網域（如 .com, .org, .net, .edu, .gov）以及國家代碼（如 .tw, .jp, .uk）。
    • 功能：
      • 如果使用者要找 google.com，根伺服器會叫使用者去找負責 .com 的 TLD 伺服器。
      • TLD 伺服器知道負責 google.com 這個域名的官方伺服器在哪裡。
  3. 官方 DNS 伺服器（Authoritative DNS Servers）
    • 地位：最終知道答案（知道該網域（例如 google.com）的 IP 位址）的伺服器。
    • 功能：每個擁有公開主機（如 Web 伺服器或 Mail 伺服器）的組織（例如大學、Amazon、Google），都必須提供官方 DNS 伺服器。這裡儲存了該組織內部主機名稱與 IP 的實際對應記錄。
  4. 特殊角色：本地 DNS 伺服器（Local DNS Server）
    • 地位：嚴格來說它不屬於上述的層級結構，但它是我們一般使用者的代理人（Proxy）。
    • 功能：通常由 ISP（如中華電信或學校）提供。當電腦發出 DNS 查詢時，其實是先發給本地 DNS 伺服器，由它代替你去上述的層級結構中跑腿、問路。

DNS 查詢流程

情境：假設你是一個在紐約大學（NYU）的學生，你的電腦（cse.nyu.edu）想要訪問麻薩諸塞大學（UMass）的伺服器（gaia.cs.umass.edu）。

這是一個 8 個步驟的過程（假設沒有快取的情況下）：

  1. 使用者（Requesting host） -> 本地 DNS：使用者的電腦向 NYU 的本地 DNS 伺服器（dns.nyu.edu）詢問：「gaia.cs.umass.edu 的 IP 是什麼？」
  2. 本地 DNS -> 根伺服器：本地 DNS 不知道答案，於是它去問根 DNS 伺服器。
  3. 根伺服器 -> 本地 DNS：
    • 根伺服器注意到 .edu 尾碼並說：「我不知道具體 IP，但這裡有負責 .edu 的 TLD 伺服器的 IP 列表，你去問它。」
    • （根伺服器回傳 TLD 伺服器的 IP 列表給本地 DNS）
  4. 本地 DNS -> TLD 伺服器：本地 DNS 轉頭去問負責 .edu 的 TLD 伺服器。
  5. TLD 伺服器 -> 本地 DNS：
    • TLD 伺服器注意到 umass.edu 的尾碼並說：「我不知道 gaia 主機的 IP，但我知道 umass.edu 這個網域是由官方 DNS 伺服器 dns.umass.edu 管理的，這是它的 IP，你去問它。」
    • （TLD 伺服器回傳 dns.umass.edu 的 IP 位址給本地 DNS，讓它去找官方 DNS 伺服器）
  6. 本地 DNS -> 官方 DNS 伺服器：本地 DNS 最後跑去問 dns.umass.edu。
  7. 官方 DNS 伺服器 -> 本地 DNS：官方 DNS 伺服器查了一下自己的資料庫，回答：「有的，gaia.cs.umass.edu 的 IP 是 128.119.40.111。」
  8. 本地 DNS -> 使用者：本地 DNS 拿到 IP 後，回傳給使用者的電腦。

整體的運作流程如下圖所示：

image

Image Source：Computer Networking: A Top-Down Approach (8th ed., p. 159, Figure 2.19)

遞迴式查詢 vs. 迭代式查詢

在 DNS 查詢過程，主要有兩種查詢模式：

  • 遞迴式查詢（Recursive Query）：
    • 就像 Figure 2.19 的步驟 1。
    • 會讓本地 DNS 伺服器承擔所有搜尋工作，它會代替用戶端去詢問各級 DNS 伺服器，直到拿到 IP 位址。
  • 迭代式查詢（Iterative Query）：
    • 就像步驟 2~7。
    • 當 DNS 伺服器（如根伺服器、TLD 伺服器）收到請求但沒有該域名的資料時，它不會主動去查，而會回傳一個參考（Referral），告訴本地 DNS 誰可能有 IP 位址。
    • 根伺服器和 TLD 伺服器通常只支援迭代式查詢，以減輕自身負載。

兩者比較表：

比較項目遞迴式查詢（Recursive Query）迭代式查詢（Iterative Query）
查詢對象通常是電腦對本地 DNS 伺服器（ISP）通常是 DNS 伺服器之間互查
回應內容最終 IP 位址或錯誤訊息目前能提供的最佳資訊（如指引）
查詢者負擔小（只需問一次）大（需重複詢問不同伺服器）

DNS 快取（DNS Caching）

如果每次上網都要跑完上面 8 個步驟，網路會慢到無法忍受，且根伺服器會被塞爆，因此需要 DNS 快取。

  • 運作方式：當本地 DNS 伺服器在查詢過程中得到任何資訊（例如 .edu TLD 的地址，或是 google.com 的 IP），它會把這些資訊存在記憶體中。
  • 效果：如果這時另一個人也要去 umass.edu，本地 DNS 已經記得 TLD 的位置（甚至記得 UMass 官方伺服器的 IP），就可以跳過根伺服器，直接去問目標，大幅減少延遲。

2.4.3 DNS Records and Messages（DNS 紀錄與訊息）

DNS 的基本資料單元：資源紀錄（Resource Record, RR）

DNS 是一個分散式資料庫，資料庫中儲存的最基本條目，稱為資源紀錄（Resource Records），簡稱 RR。

RR 的結構

不管是什麼類型的紀錄，一個 RR 都包含四個欄位：(Name, Value, Type, TTL)

  • TTL（Time to Live）：RR 的存活時間，決定了這筆紀錄可以在快取（Cache）中存活多久。雖然它很重要，但在接下來的例子，為簡化會忽略它。
  • Type：最重要的欄位，因為它決定了 Name 和 Value 代表什麼意義。

四種紀錄類型（Type）

類型（Type）Name（名字）的意義Value（值）的意義功能解釋範例（Name, Value, Type）
A主機名稱（Hostname）IP 位址最標準的查詢，把網址（Name）轉成 IP（Value）。(relay1.bar.foo.com, 145.37.93.126, A)
NS（Name Server）網域（Domain）官方 DNS 伺服器的主機名告訴你如果要查這個網域的細節，該去問哪台伺服器，用於繞送（route）DNS 查詢鏈。(foo.com, dns.foo.com, NS)
CNAME（Canonical Name）別名（Alias Hostname）正規主機名（Canonical Name）用來做別名對應，Value 是該主機真正的名字。(foo.com, relay1.bar.foo.com, CNAME)
MX（Mail Exchanger）郵件網域郵件伺服器的主機名專門用於電子郵件，允許郵件伺服器和 Web 伺服器使用相同的公司別名。(foo.com, mail.bar.foo.com, MX)

伺服器如何儲存這些記錄？

如果一台 DNS 伺服器是某個主機的官方 DNS 伺服器，則該台 DNS 伺服器會有一條該主機的 Type A 記錄，會直接告訴你該主機的 IP。

如果一台 DNS 伺服器「不是」官方 DNS 伺服器（例如 TLD 伺服器）：它會包含兩條記錄來做指引：

  1. 一條 Type NS 記錄：告訴該台 DNS 伺服器去問那台官方 DNS 伺服器。
  2. 一條 Type A 記錄：提供那台官方 DNS 伺服器的 IP 位址（否則只知道名字，還是找不到它）。

DNS 訊息格式

了解了資料庫存什麼，接下來看電腦之間如何溝通。

DNS 只有兩種訊息：

  1. 查詢（Query）
  2. 回覆（Reply）

它們的格式是完全一樣的。

一個 DNS 訊息由五個部分組成（如下圖 Figure 2.21），可分成兩大部分，而在第二部分資料區段中又可細分成四個部分：

  • 標頭區段（Header Section）- 12 Bytes：這是訊息的控制中心，包含以下欄位：
    • 識別碼（Identification）：
      • 16-bit 的數字，用於識別查詢訊息。
      • 當發出查詢時會隨機生成一個 ID，回覆時會帶上同一個 ID。
      • 這樣電腦才能知道該回覆是對應剛才發出的那個查詢。
    • 旗標（Flags）：
      • 查詢／回覆旗標（Query/Reply flag）：0 代表查詢，1 代表回覆。
      • 官方旗標（Authoritative flag）：如果是回覆，這個 bit 告訴 DNS 伺服器發送者是否為官方 DNS 伺服器。
      • 遞迴需求旗標（Recursion-desired flag）：客戶端（主機或 DNS 伺服器）要求 DNS 伺服器進行「遞迴查詢」（幫我問到底的意思）。
      • 遞迴可用旗標（Recursion-available flag）：DNS 伺服器告訴你它是否支援遞迴查詢。
    • 數量欄位（Number fields）：有四個欄位，分別指出在標頭之後四種資料區段各有多少條記錄。
  • 資料區段（Data Sections）：接在 Header 後面有四個區段：
    1. 詢問區段（Question Section）：
      • 放的是目前正在進行查詢的相關資訊。
      • 包含兩個欄位：
        1. 名稱欄位（Name field）：存放正在查詢的名稱。
        2. 類型欄位（Type field）：例如針對該名稱詢問的問題類型，是想查 A 還是 MX。
    2. 答覆區段（Answer Section）：
      • 放的是一開始查詢名稱時的資源記錄（RRs）。
      • 注意，一個查詢可能會回傳多條 RR（例如一個網站有多個 IP 用於負載平衡）。
    3. 官方區段（Authority Section）：包含其他官方 DNS 伺服器的記錄。如果現在這台 DNS 伺服器不知道答案，它會在這裡放上要去問哪台伺服器的 NS 記錄。
    4. 附加區段（Additional Section）：
      • 包含其他有用的紀錄。
      • 例如，若答覆區段（Answer Section）回傳了一個 CNAME 或 MX 記錄（給的是另一個名字），這裡可能會順便附上那個名字對應的 Type A 記錄（IP 位址），省得 DNS 伺服器再查一次。

image

Image Source：Computer Networking: A Top-Down Approach (8th ed., p. 163, Figure 2.21)

註：在此可以嘗試使用 nslookup 指令工具發送 DNS 查詢，它會顯示接收到的 RR 內容。

如何將記錄插入 DNS 資料庫？

如果你開了一家公司叫做 “Network Utopia”，要怎麼讓全世界都能解析 networkutopia.com？

這需要跟註冊商（Registrar）打交道：

  1. 註冊網域：付費給註冊商（如 GoDaddy, Namecheap 等）來取得網域名稱。
  2. 提供官方 DNS 伺服器資訊：必須提供主要的和次要的官方 DNS 伺服器的名字和 IP。
    • 例如：dns1.networkutopia.com（IP：212.2.212.1）
  3. 註冊商的動作：註冊商會將兩條關鍵記錄插入到 .com 的 TLD 伺服器中：
    • 一條 NS 記錄：(networkutopia.com, dns1.networkutopia.com, NS)
    • 一條 A 記錄：(dns1.networkutopia.com, 212.2.212.1, A)
    • 這就是為什麼前面說非官方 DNS 伺服器通常會同時存 NS 和 A 記錄，因為這樣查詢鏈才不會斷掉。
  4. 設定你的官方 DNS 伺服器：最後只要在自己的官方 DNS 伺服器裡，設定好網站（www）的 Type A 記錄，以及郵件伺服器的 Type MX 記錄。

DNS 的弱點（DNS Vulnerabilities）

DNS 設計之初（1980 年代），網際網路是一個相對封閉、互信的環境。

當時的設計重點是：

  1. 可用性（Availability）
  2. 擴展性（Scalability）

而非安全性（Security）。因此導致 DNS 天生較為脆弱，容易成為攻擊目標。

如果 DNS 倒了，瀏覽器再也找不到 google.com 或 facebook.com。

對使用者來說跟網路斷了沒兩樣，因此攻擊 DNS 是癱瘓網際網路最有效的方法之一。

術語解析

  • DDoS 頻寬滿載攻擊（DDoS Bandwidth-flooding Attack）：利用大量的殭屍網路（Botnet）向目標發送海量垃圾封包，塞爆目標的頻寬或處理能力，讓正常使用者無法存取服務。
  • ICMP Ping 滿載攻擊（ICMP Ping Flood）：一種 DDoS 手法，發送大量的 ICMP Echo Request（Ping）封包給伺服器，消耗其資源。
  • DNS 汙染攻擊（DNS Poisoning Attack）：駭客發送偽造的 DNS 回覆給 DNS 伺服器，誘騙它把錯誤的 IP 位址（例如釣魚網站的 IP）存入快取中。
  • DNS 安全擴充（DNS Security Extensions，DNSSEC）：DNS 的安全擴充協定，透過密碼學簽章來確保 DNS 紀錄的真實性與完整性，用於防止上述可能的攻擊。

針對根伺服器的攻擊

此為最直觀的攻擊思路，將根伺服器砍掉，網路就全體癱瘓了。

歷史案例：2002 年 10 月 21 日，駭客發動了一次大規模 DDoS 攻擊，利用殭屍網路向全球 13 個根伺服器 IP 發送海量的 ICMP Ping 訊息。

結果：攻擊失敗，對一般使用者的上網體驗幾乎沒有影響。

為什麼失敗？（防禦機制）：

  1. 封包過濾（Packet Filtering）：許多根伺服器配置了防火牆，直接阻擋或過濾掉 ICMP Ping 封包，保護了伺服器本身。
  2. 快取（Caching）：本地 DNS 伺服器（Local DNS Servers）會快取高階網域（TLD）的 IP 位址，大多數的查詢根本不需要去問根伺服器，直接問 TLD 伺服器就好了。

針對高階網域（TLD）伺服器的攻擊

既然打根伺服器沒用，駭客就將目標轉向下一層：TLD 伺服器（如負責 .com 的伺服器）。

為什麼這裡比較脆弱？

  • 不像根伺服器那麼容易被快取繞過（如果要查一個新的 .com 網域，最終還是得問 TLD）。
  • 封包過濾比較困難，因為查詢流量看起來很像合法的 DNS 請求。

歷史案例：2016 年 10 月 21 日，針對 DNS 服務商 Dyn 的攻擊。

攻擊手法：利用感染了 Mirai 惡意軟體的物聯網裝置（IoT devices）（如印表機、網路攝影機、嬰兒監視器）組成龐大殭屍網路，發送海量 DNS 查詢。

結果：攻擊成功，Twitter, Netflix, Amazon, Spotify 等依賴 Dyn 解析的大型服務在當天受到嚴重影響。

欺騙式攻擊

除了癱瘓伺服器（讓大家都連不上），更陰險的是讓使用者連到錯的地方。

攻擊類型運作原理後果
中間人攻擊（Man-in-the-middle attack，MITM）攻擊者攔截使用者的 DNS 查詢，並回傳偽造的 IP。使用者以為連上了銀行網站，其實是連到了駭客的伺服器。
DNS 汙染（DNS Poisoning）攻擊者發送偽造的回覆給 DNS 伺服器，讓伺服器「誤信」並將錯誤紀錄存入快取。所有使用這台 DNS 伺服器的使用者，在快取過期前都會被導向錯誤網站。

防禦解方：DNSSEC。

  • DNSSEC 透過數位簽章（Digital Signatures）來驗證來源。
  • 能確保使用者收到的 DNS 回覆真的是由官方 DNS 伺服器發出的，而且途中沒有被竄改，目前 DNSSEC 正在逐漸普及中。

總整理

DNS 的定位與基本功能

DNS（Domain Name System），網際網路中的域名解析系統，負責將人類可讀的主機名稱（Hostname）轉換為 IP 位址（IP Address）。

例如輸入 google.com，必須先透過 DNS 取得對應 IP，瀏覽器才能發起 TCP 連線與 HTTP 通訊。

架構特性：

  • 屬於應用層協定。
  • 建立於 UDP Port 53。
  • 由兩部分組成：
    1. 分散式階層資料庫
    2. 查詢通訊協定

體現網際網路將複雜性放在邊緣的設計哲學。

DNS 提供的服務

除了「將名稱解析成 IP」轉換，DNS 還提供三項重要進階功能：

  1. 主機別名（Host Aliasing）：使用 CNAME 紀錄，讓複雜正式名稱可對應簡短別名。
  2. 郵件伺服器別名（Mail Server Aliasing）：透過 MX 紀錄，讓電子郵件地址可對應實際郵件伺服器。
  3. 負載分配（Load Distribution）：同一網域可對應多個 IP，DNS 透過「輪替回傳順序」實現基礎流量分散。

為什麼 DNS 必須是分散式？

若採集中式架構，會產生四大問題：

  1. 單點失效
  2. 無法承受全球流量
  3. 高延遲
  4. 維護困難

因此 DNS 採用「分散式 + 階層式」架構。

DNS 階層架構

DNS 採倒樹狀結構，共三層核心節點 + 一個代理角色：

  1. 根 DNS 伺服器（Root DNS Servers）
    • 全球 13 個邏輯根 IP。
    • 指引使用者、DNS 伺服器到正確的 TLD。
    • 不直接知道最終 IP。
  2. 高階網域伺服器（TLD Servers）
    • 負責 .com、.edu、.tw 等網域。
    • 知道各網域的官方 DNS 位置。
  3. 官方 DNS 伺服器（Authoritative DNS Servers）
    • 儲存最終主機名稱與 IP 的對應。
    • 由各組織自行管理。
  4. 本地 DNS（Local DNS）
    • 由 ISP 提供。
    • 扮演使用者代理人。
    • 負責查詢與快取。

註：本地 DNS 嚴格上來說不算 DNS 階層架構的一部分。

DNS 查詢模式

DNS 查詢分兩種：

模式說明
遞迴式（Recursive）本地 DNS 負責查到底。
迭代式（Iterative）每層只回傳一個參考（Referral），告訴本地 DNS 誰可能有 IP 位址。

實際上的運作流程是這樣的：

  1. 使用者與本地 DNS 之間是遞迴式查詢。
  2. 本地 DNS 伺服器與其他三台伺服器之間是迭代式查詢。

DNS 快取（Caching）

為避免每次查詢都從根伺服器開始：

  • 本地 DNS 會暫存結果。
  • 設定 TTL 控制有效時間。
  • 可大幅降低延遲與根伺服器負載。

快取是 DNS 能全球運作的關鍵。

DNS 資料單元：Resource Record（RR）

DNS 的基本資料格式為：(Name, Value, Type, TTL)

四種重要的紀錄類型（Type）：

類型（Type）Name（名字）的意義Value（值）的意義功能解釋範例（Name, Value, Type）
A主機名稱（Hostname）IP 位址最標準的查詢，把網址（Name）轉成 IP（Value）。(relay1.bar.foo.com, 145.37.93.126, A)
NS（Name Server）網域（Domain）官方 DNS 伺服器的主機名告訴你如果要查這個網域的細節，該去問哪台伺服器，用於繞送（route）DNS 查詢鏈。(foo.com, dns.foo.com, NS)
CNAME（Canonical Name）別名（Alias Hostname）正規主機名（Canonical Name）用來做別名對應，Value 是該主機真正的名字。(foo.com, relay1.bar.foo.com, CNAME)
MX（Mail Exchanger）郵件網域郵件伺服器的主機名專門用於電子郵件，允許郵件伺服器和 Web 伺服器使用相同的公司別名。(foo.com, mail.bar.foo.com, MX)

伺服器如何儲存這些記錄？

如果一台 DNS 伺服器是某個主機的官方 DNS 伺服器，則該台 DNS 伺服器會有一條該主機的 Type A 記錄，會直接告訴你該主機的 IP。

如果一台 DNS 伺服器「不是」官方 DNS 伺服器（例如 TLD 伺服器）：它會包含兩條記錄來做指引：

  1. 一條 Type NS 記錄：告訴該台 DNS 伺服器去問那台官方 DNS 伺服器。
  2. 一條 Type A 記錄：提供那台官方 DNS 伺服器的 IP 位址（否則只知道名字，還是找不到它）。

DNS 訊息結構

DNS 訊息包含：

  • 標頭區段（12 Bytes）
    • 識別碼（Identification）：
      • 16-bit 的數字，用於識別查詢訊息。
    • 旗標（Flags）：
      • 查詢／回覆旗標（Query/Reply flag）
      • 官方旗標（Authoritative flag）
      • 遞迴需求旗標（Recursion-desired flag）
      • 遞迴可用旗標（Recursion-available flag）
    • 數量欄位（Number fields）：有四個欄位，分別指出在標頭之後四種資料區段各有多少條記錄。
  • 四個資料區段
    1. 詢問區段（Question Section）：
      • 放的是目前正在進行查詢的相關資訊。
      • 包含兩個欄位：
        1. 名稱欄位（Name field）
        2. 類型欄位（Type field）
    2. 答覆區段（Answer Section）：
      • 放的是一開始查詢名稱時的資源記錄（RRs）。
      • 一個查詢可能會回傳多條 RR。
    3. 官方區段（Authority Section）：包含其他官方 DNS 伺服器的記錄。如果現在這台 DNS 伺服器不知道答案，它會在這裡放上要去問哪台伺服器的 NS 記錄。
    4. 附加區段（Additional Section）：
      • 包含其他有用的紀錄。

網域註冊流程

若要讓新網域生效：

  1. 向註冊商購買網域。
  2. 提供官方 DNS 伺服器資訊。
  3. 註冊商將 NS + A 記錄加入 TLD。
  4. 在官方 DNS 設定 A / MX 紀錄。

這樣 DNS 查詢鏈才能完整運作。

DNS 的安全弱點

DNS 設計初期重視：

  • 可用性（Availability）
  • 擴展性（Scalability）

而非安全性，因此存在漏洞。

主要攻擊類型：

  1. DDoS 攻擊（Distributed Denial-of-Service Attack）

    • 利用殭屍網路發送大量封包塞爆 DNS。
    • 案例：
      • 2002 年攻擊根伺服器（失敗）。
      • 2016 年攻擊 Dyn（成功）。

  2. DNS 汙染（DNS Poisoning）

    • 偽造回覆污染快取。

  3. 中間人攻擊（Man-in-the-Middle，MITM）

    • 攔截查詢並回傳假 IP。

防禦機制：DNSSEC

DNSSEC（DNS Security Extensions）透過數位簽章驗證：

  • 確保資料未被竄改。
  • 驗證回覆來源為官方伺服器。