DNS 術語、組件與概念概述

DNS（網域名稱系統）是驅動網際網路的關鍵組件之一。正確理解 DNS 的運作方式有助於診斷網站設定的問題，並拓寬您對幕後運作情況的理解。

在本指南中，我們將探討 DNS 的一些基本概念，以便在您進行 DNS 設定時為您奠定堅實的基礎。本指南也將協助您設定自己的網域名稱或 DNS 伺服器。

讓我們開始吧！

網域術語

首先，我們需要對即將使用的術語建立共識。您可能已經在其他情境中熟悉了其中的一些術語。然而，在談論網域名稱和 DNS 時，有許多特定術語在其他電腦領域中並不常被討論。

• 網域名稱系統

網域名稱系統（簡稱 DNS）是一種現行的網路系統，用於將易於人類理解的網域名稱轉換為唯一的 IP 位址。

• 網域名稱

網域名稱是指用於與網際網路資源關聯的、易於人類理解的名稱。例如，“cloudsigma.com” 就是一個網域名稱。有些人可能會認為只有 “cloudsigma” 部分才是網域名稱，但通常它是指整體。

URL “cloudsigma.com” 與 CloudSigma 擁有的伺服器相關聯。在網頁瀏覽器中輸入該 URL 時，它會與 DNS 進行通訊以連接到目標伺服器的 IP 位址。

• IP 位址

IP 位址充當連接到網路的裝置的網路位址。每個 IP 位址在網路中必須是唯一的。在網站的情境中，大多數時候網路指的是整個網際網路。

IP 位址有兩種類型：

• • IPv4：這是最常見的 IP 位址形式。它被寫成一組四個數字，每組最多有 3 位數。每組之間用點隔開。IPv4 的範圍是從 0.0.0.0 到 255.255.255.255.

  • IPv6：這是一個更現代的標準，旨在解決 IPv4 位址枯竭 的問題。IPv4 支援多達 232 個唯一位址，而 IPv6 則支援多達 2128 個位址。任何 IPv6 位址都以十六進位數字寫成。它最多可包含 32 位數，分為 8 個部分（每個部分 4 位數）。每個部分用冒號 (:) 隔開。

頂級網域

頂級網域（簡稱 TLD）是網域中最通用的部分。它指的是最右側的部分（以點隔開）。一些常見的頂級網域包括：

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

就網域名稱而言，這些網域處於階層結構的頂端。ICANN（網際網路名稱與數字地址分配機構）可以向特定方發放控制頂級網域的許可。獲得許可後，這些方可以分發該 TLD 下的網域名稱（通常透過網域註冊商）。

• 主機

在網域中，擁有者可以指定個別主機，這指的是透過網域可存取的獨立機器/服務。例如，通常的做法是讓網頁伺服器可以透過裸網域（ example.com）和 “主機” 定義 “www  ( www.example.com).

在一般網域下也可以有其他主機，例如，透過 “api” 主機進行 API 存取（ api.example.com），透過 “ftp” 或 “files” 主機進行 FTP 存取（ ftp.example.com 或 files.example.com).

請注意，只要網域名稱在該網域內是唯一的，就可以是任意的。

• 子網域

子網域是與主機相關的主題。DNS 以階層結構運作。一個 TLD 下可以有多個網域。例如，“ example.com”, “ cloudsigma.com”等都屬於 “com” TLD。就此而言，子網域是指屬於目標網域一部分的任何網域。因此，我們可以說 “example.com” 是 “com” 的子網域。通常，“example” 部分被稱為 SLD（二級網域）。

同樣地，一個網域可以控制其下的所有“子網域”。這通常是“子網域”一詞所指的意思。例如，“ history.example.com” 為以下網域的子網域：“ example.com”.

主機名稱與子網域之間的主要區別在於，主機定義了電腦/資源，而子網域則是延伸了父網域。每當我們談論子網域或主機時，您可以透過查看網域最左側的部分來確認，因為它是最具體的。這就是 DNS 的運作方式：從最具體（最左側）到最不具體（最右側）。

• 完整網域名稱

完整網域名稱（簡稱 FQDN）是指絕對網域名稱。在 DNS 系統中，網域可以相對地給出。這可能會導致一些歧義。然而，FQDN 是一個絕對名稱，指向網域名稱系統的絕對根。

這意味著 FQDN 指定了包括 TLD 在內的每個父網域。一個合適的例子是 “ mail.google.com”。在特定情況下，FQDN 可能不以點結尾，但它必須有一個結尾點（這是 ICANN 標準所要求的）。

• 名稱伺服器

名稱伺服器是專門用於將網域名稱轉換為 IP 位址的電腦。名稱伺服器承擔了 DNS 系統中的大部分負載。由於網域轉換請求的總數太高，單一伺服器無法處理，因此請求通常會被重定向到其他名稱伺服器以分擔壓力。

名稱伺服器可以是“授權的”，這意味著它只回答對其控制下網域的查詢。此類伺服器可以將請求轉發給其他名稱伺服器，或者提供其他名稱伺服器資料的快取複本。

• 區域檔

區域檔是一個文字檔案，其中包含網域名稱與 IP 位址之間的對應關係。它作為 DNS 系統的資料庫。這是 DNS 在完成使用者對特定網域名稱的請求時，用來尋找要聯絡哪個 IP 位址的目錄。

通常，名稱伺服器會託管區域檔，並定義單一網域下可用的資源。它還可以包含有關去哪裡獲取該資訊的資訊。

• 記錄

區域檔由許多記錄組成。在這裡，記錄被定義為資源與名稱之間的單一對應關係。記錄可以是網域名稱對應到 IP 位址、特定網域下可用的資源，或者是獲取該資訊之處的引用。

DNS 實際運作

到目前為止，我們已經熟悉了與 DNS 相關的一些常見術語。然而，該系統實際上是如何運作的？從高層次來看，該系統可能顯得非常簡單。儘管如此，深入了解細節將揭示其真正的複雜性。總體而言，DNS 系統對於網際網路的廣泛普及至關重要。

• 根伺服器

DNS 的核心是以階層結構運作。在系統的最頂端是“根伺服器”。這些伺服器由多個不同的組織控制。這些伺服器的權限是由 ICANN（網際網路名稱與數字地址分配機構）所授權。

截至目前，大約有 13 台根伺服器在運作。然而，由於負載原因，這些伺服器中的每一台都有鏡像。需要注意的是，所有鏡像伺服器都與根伺服器共享相同的 IP 位址。每當向根伺服器發出任何請求時，該請求都會被重定向到該伺服器最近的鏡像。

根伺服器的職責是什麼？它們提供有關頂級網域的資訊。每當低階名稱伺服器無法解析請求時，請求就會被重定向到該網域的根伺服器。

然而，根伺服器實際上並不知道該網域的位置。它只會重定向將處理特定請求的頂級網域的請求。例如，如果提出針對“ blog.cloudsigma.com”的請求，根伺服器的記錄中不會有該資料。它會搜尋其區域檔案，但不會有任何相關記錄。相反地，它會識別出“com”頂級網域（TLD），並將請求端重定向到處理“com”位址的名稱伺服器。

• TLD 伺服器

延續先前的範例，請求端現在會將請求傳送到該 IP 位址（由根伺服器提供）。以“ blog.cloudsigma.com”為例，“com”名稱伺服器將在其區域檔案中搜尋其記錄。

其中不會有與該請求相對應的記錄。然而，它會找到一筆記錄，列出負責“ cloudsigma.com”.

• 網域級名稱伺服器

現在，請求端已取得實際託管“ blog.cloudsigma.com”資訊的名稱伺服器 IP 位址。它現在會向該伺服器傳送一個新請求，要求解析“www.cloudsigma.com”。

與之前相同，名稱伺服器會檢查其區域檔案，並找到與“ cloudsigma.com”相關聯的檔案。在此檔案中會存在一個“www”主機的項目。此記錄描述了該主機的位置。接著，最終答案會被轉發給請求端。

• 解析名稱伺服器

在範例中，我們提到了請求端。它是什麼？在大多數情況下，請求者會是“解析名稱伺服器”。這是一台被設定為向其他伺服器提問的伺服器。它充當使用者的中介伺服器。它會快取結果以提高速度。

任何使用者通常都會在他們的系統上設定幾個解析名稱伺服器。一般來說，解析名稱伺服器是由 ISP 或其他組織提供的。例如，Google 提供了公共解析 DNS 伺服器供查詢。您可以手動將其設定到您的系統中。

在網頁瀏覽器中輸入 URL 時，它會尋找資源的位置。首先，會在本地進行搜尋。這包括“hosts”檔案（以及其他一些位置）。如果找不到，請求就會被傳送到解析名稱伺服器。收到請求後，解析名稱伺服器會在快取中搜尋答案。如果找不到，它就會執行前面提到的步驟。

解析名稱伺服器簡化了終端使用者的請求過程。用戶端只需向解析名稱伺服器詢問資源的位置。名稱伺服器會進行調查並返回最終答案。

• 區域檔案

我們已經討論過“區域檔案”和“記錄”的概念。那麼，它們是如何運作的呢？

區域檔案充當名稱伺服器的資料庫，儲存它們所知道的網域資訊。名稱伺服器所知道的所有網域都會儲存在其區域檔案中。然而，傳送到名稱伺服器的大多數請求並不是由區域檔案解析的。如果伺服器設定為處理遞迴查詢（例如解析名稱伺服器），它就會返回答案。否則，它會將請求方重定向到另一個地方進行下一步尋找。

名稱伺服器託管的區域檔案越多，其答案就越具權威性。區域檔案描述了一個 DNS“區域”（整個 DNS 命名系統的子集）。一般來說，區域檔案僅包含單一網域的設定資料。它可以有多個記錄，定義所討論網域資源的位置。

區域的 $ORIGIN 參數等於該區域的最高權威級別。例如，“ cloudsigma.com” 的區域檔案將會把其 $ORIGIN 設為 “ cloudsigma.com”。該參數的值可以儲存在區域檔案的開頭或 DNS 伺服器的設定中。無論哪種方式，該參數都描述了該檔案對哪個區域具有權威性。

該 $TTL 參數設定了其提供之結果的 “存活時間” 資訊。它可以被描述為一個計時器，快取伺服器可以用它來追蹤快取解答的有效性。如果 TTL 值耗盡，該解答將不再有效並會被捨棄。

• 記錄類型

區域檔案由許多記錄組成。現在，有不同類型的記錄。接下來，我們將介紹一些最常見（且強制性）的記錄類型：

SOA 記錄

授權起點（簡稱 SOA）記錄在所有區域檔案中都是強制性的。它必須是檔案中的第一個實際記錄。然而，像 $ORIGIN 或 $TTL 這類的項目允許在之前出現。

SOA 記錄是較為複雜的記錄類型之一。其結構看起來像這樣：

讓我們逐一拆解：

• • example.com：此部分定義了區域的根。在此範例中，區域檔案是針對網域 “ example.com”。有時，該值可能會被替換為 @（一個用於替換 值的預留位置$ORIGIN).

  • IN SOA：“IN” 一詞代表 “網際網路”。您會在許多記錄中看到它。“SOA” 一詞則表示這是一條 SOA 記錄。

  • ns1.example.com：此值保存了網域 “ 的主要名稱伺服器example.com”。名稱伺服器可以是主要或次要的。如果設定了動態 DNS，則需要有一台 “主要” 伺服器。如果未設定動態 DNS，則它將是主要名稱伺服器之一。

  • admin.example.com：此處填寫區域管理員的電子郵件地址。請注意， @ 在此處被替換為 .。如果原始電子郵件地址中包含點，則會被替換為 \。例如，“ my.domain@example.com” 將會變成 “ my\domain.example.com”.

  • 12083：這是區域檔案的序號。每次編輯區域檔案時，都必須更新該號碼，以便檔案能夠正確傳播。次要伺服器使用此序號來追蹤其自身的區域檔案是否為最新狀態。

  • 3h：代表區域的重新整理間隔。次要伺服器在檢查區域檔案更新之前會等待這段時間。

  • 30m：此值代表區域的重試間隔。如果次要伺服器在重新整理週期結束後無法連接到主要伺服器，它將在再次輪詢主要伺服器之前等待這段時間。

  • 3w：此值代表到期時間。如果次要伺服器在此時間段內無法連接到主要伺服器，它將停止傳回 “具權威性” 的判定結果。

  • 1h：此值代表如果在其區域檔案中找不到名稱，名稱伺服器快取名稱錯誤（name error）的時間。

A 與 AAAA 記錄

這些記錄建立了主機與 IP 地址之間的對應關係。在此，“A” 記錄表示對應到主機的 IPv4 地址，而 AAAA 則表示 IPv6 對應。

這是 A 和 AAAA 記錄的基本結構：

在 SOA 記錄範例中，我們將名稱伺服器稱為 “ ns1.exampel.com”。名稱伺服器屬於網域 “ example.com”。以下是其 A 記錄的外觀：

請注意，我們不需要提供完整名稱。僅憑主機名稱（不含 FQDN），DNS 伺服器就可以使用來自 的值填補其餘部分$ORIGIN。然而，我們仍然可以使用 FQDN：

以下是如何將網頁伺服器定義為 “www”：

我們還應該包含到基礎網域的對應。該項目看起來會像這樣：

或者，我們可以使用 @ 符號來表示基礎網域（而不是其完整名稱）：

包含萬用字元項目是一個好習慣，這樣可以解析此網域下未明確定義的任何內容：

相同的結構也適用於 AAAA 記錄。唯一的區別是 IPv6 位址。

CNAME 記錄

CNAME 記錄充當伺服器標準名稱（由 A 或 AAAA 記錄定義）的別名。請看以下範例：

在這裡，我們使用 “server1” 作為定義 “www” 名稱的別名。請注意，此類捷徑會帶來效能成本，因為伺服器必須執行額外的查詢才能獲得最終答案。根據別名層數的不同，這很容易造成巨大的效能成本。然而，有一種特定情況可以從 CNAME 別名中受益，例如，提供目前區域之外的資源。

MX 記錄

MX 記錄定義了該網域的郵件交換。它有助於電子郵件正確到達伺服器。與其他記錄不同，MX 記錄不會將主機對應到某個對象，因為它們適用於整個區域。這就是為什麼 MX 記錄看起來像這樣：

請注意，該項目的開頭沒有主機名稱。您還會注意到該行中有一個額外的值。這是偏好設定號碼，有助於決定將郵件傳送到哪部伺服器（如果定義了多部郵件伺服器）。數字越小，優先權越高。

MX 記錄應該指向由 A 或 AAAA 記錄（而不是 CNAME）定義的主機。記住這一點，如果配置了兩部郵件伺服器，那麼記錄看起來會像這樣：

在此範例中，從偏好設定號碼來看，“mail1” 是比 “mail2” 更理想的伺服器。我們可以透過省略完整網域名稱來進一步縮短程式碼：

NS 記錄

這些記錄定義了特定區域的名稱伺服器。現在，顯而易見的問題是，如果區域檔案存在於名稱伺服器中，為什麼它需要對自身的引用？該問題的一個答案是 DNS 系統的多重快取機制。區域檔案實際上可能是其他伺服器上的快取複本。

與 MX 記錄類似，NS 記錄適用於整個區域。因此，預設情況下它們沒有任何特定主機。NS 記錄項目看起來會像這樣：

建議定義兩個名稱伺服器，以防其中一個伺服器無法正常運作。此外，如果區域檔案僅包含單個名稱伺服器，大多數 DNS 伺服器將會拒絕該檔案。

您還應該包含主機與 A 或 AAAA 記錄的對應：

PTR 記錄

PTR 記錄是傳統 A 或 AAAA 記錄的反向。這些記錄用於定義與 IP 地址關聯的名稱。這些記錄具有獨特的屬性，因為它們始於 .arpa 根並代表 IP 地址的所有者。是由 RIR（區域網際網路註冊機構）將 IP 地址分配給組織和服務提供商。這些 RIR 包括 APNIC、AFRINIC、LACNIC、RIPE NCC 和 ARIN。

例如，一個用於 111.222.333.444 看起來會像這樣：

在下一個 PTR 記錄範例中，來看看 Google 的 IPv6 DNS 伺服器 2001:4860:4860::8888:

我們可以使用帶有旗標的 dig 工具 -x 來查詢 IP 地址的反向 DNS 名稱。例如，查看 的反向 DNS IP 地址8.8.4.4:

網路伺服器使用 PTR 記錄來追蹤記錄條目中的網域名稱、做出明智的垃圾郵件處理決策，並顯示關於其他裝置易於閱讀的資訊。

常用的電子郵件伺服器會查詢發送電子郵件的 IP 地址的 PTR 記錄。如果 PTR 記錄為空，則該電子郵件極有可能是垃圾郵件（因此會被拒絕）。請注意，FQDN 與 PTR 記錄的網域名稱是否匹配並非重點。重要的因素在於是否有一個有效的 PTR 記錄與匹配且對應的正向 A 記錄相關聯。

通常，網際網路上的網路路由器具有與其物理位置對應的 PTR 記錄。例如，“NYC” 或 “CHI” 是位於紐約和芝加哥的路由器的有效參考。當執行 traceroute 或 MTR 並審查封包所經路徑時，此技術非常有用。

CAA 記錄

這些記錄指定了可以為您的網域核發 SSL/TLS 憑證的 CA（憑證授權單位）。自 2017 年 9 月 8 日起，所有 CA 在核發憑證之前都必須檢查 CAA 記錄。如果不存在 CAA 記錄，則任何 CA 都可以核發憑證。否則，僅允許特定的 CA 核發憑證。CAA 記錄既可以套用於單個主機，也可以套用於整個網域。

以下是 CAA 記錄的範例：

該條目中特定於 CAA 的部分是 0 issue "letsencrypt.org"。此部分包含三個部分：

• 旗標：這是一個整數值，指示 CA 應如何處理其不理解的標籤。如果旗標值設置為 0，則該記錄將被忽略。如果值為 1，則 CA 必須拒絕核發憑證。
• 標籤：這些是表示 CAA 記錄用途的字串。截至目前，有效值包括 issue（授權 CA 為特定網域核發憑證）， issuewild（授權萬用字元憑證），以及 iodef （定義 CA 回報違反政策行為的 URL）。
• 值：這些是與記錄標籤相關聯的字串。如果標籤為 issue 或 issuewild，該值通常會是您授予權限的 CA 的網域。如果標籤為 iodef，它將是聯絡表單的 URL 或 mailto: 連結以進行電子郵件回饋。

我們可以使用 dig 工具來獲取 CAA 記錄：

如需關於 CAA 記錄的更多深入資訊，請參閱 RFC 6844.

結語

本指南介紹了各種與 DNS 相關的術語。它還說明了所有組件是如何協同運作的。有了這個全面的概述，您應該能很好地掌握 DNS 系統的功能。雖然基本概念簡單易懂，但其中的細節很快就會變得非常複雜。對於缺乏經驗的管理員來說，要應用這些概念和策略可能會很困難。

您是 CloudSigma 的客戶嗎？那麼請查看 為您的 CloudSigma 基礎架構管理和更新反向 DNS/PTR 記錄.

祝您運算愉快！