共用方式為

Windows Server 中的 DNS 架構

DNS 是階層式分散式資料庫，以及一組相關聯的通訊協定，可定義：

  • 查詢和更新資料庫的機制

  • 在伺服器之間復寫資料庫中信息的機制

  • 資料庫的架構

DNS 主機名位於可以分散到多個伺服器的資料庫中，減少任何一個伺服器的負載，並且能夠在每個分區基礎上管理這個命名系統。 DNS 支援階層式名稱，而且除了主機檔案中使用的主機名-to-IP 位址對應之外，還允許註冊各種數據類型。 DNS 資料庫是分布式的，這允許它既可以縱向擴展又可以橫向擴展，這表示在新增更多伺服器時，效能不會降低。

原始 DNS 是以 徵求評論 (RFC) 1035（網域名稱–實現與規範）為基礎。 其他 RFC 會說明 DNS 安全性、實作和系統管理問題，之後會增強原始的設計規格。

Windows Server 操作系統中使用的 RFC 如下：

  • 網域名稱 - 概念和設施 RFC 1034
  • 網域名稱 - 實現和規格 RFC 1035
  • 支援 IP 第6版的 DNS 擴充功能 RFC 1886
  • 區域變更提示通知的機制 （DNS NOTIFY） RFC 1996
  • DNS RFC 1995 中的累加區域傳輸
  • 域名系統中的動態更新（DNS UPDATE）RFC 2136
  • DNS 查詢的負面快取 （DNS NCACHE） RFC 2308
  • DNS 安全性延伸模組 RFC 4034 的資源記錄
  • DNS 安全性延伸模組 RFC 4035 的通訊協定修改
  • 指定服務位置的 DNS RR （DNS SRV） RFC 2052

DNS 網域名稱

DNS 會實作為階層式和分散式資料庫，其中包含各種類型的數據，包括主機名和域名。 DNS 資料庫中的名稱會形成稱為網域命名空間的階層式樹狀結構。 網域名稱由以點分隔的個別標籤組成，例如：mydomain.contoso.com。

完整功能變數名稱 （FQDN） 可唯一識別主機在 DNS 階層式樹狀結構中的位置。 FQDN 會指定路徑中以點分隔的名稱清單，從參考的主機到根目錄。 下圖顯示 DNS 樹狀結構範例，其中具有 mydomain 網域內名為 contoso.com 的主機。 主機的 FQDN 是 mydomain.contoso.com。

此圖顯示 DNS 架構的階層式結構，以及 DNS 區域如何由不同授權單位管理。

瞭解 DNS 網域命名空間

如上圖所示，DNS 網域命名空間是以具名網域樹狀結構的概念為基礎。 樹狀結構的每個層級都可以代表分支或分葉。 分支是一個層級，其中會使用多個名稱來識別具名資源的集合。 樹葉節點代表在該層級中一次使用的唯一名稱，用來標示特定資源。

DNS 網域名稱階層

DNS 用戶端和伺服器會使用查詢作為將樹狀結構中名稱解析為特定資源資訊類型的方法。 這項資訊是由 DNS 伺服器在查詢回應中提供給 DNS 用戶端，然後擷取資訊，並將其傳遞至要求程式，以解析查詢的名稱。 在解析名稱的過程中，DNS 伺服器通常會作為 DNS 用戶端運作，查詢其他伺服器以完全解析查詢的名稱。

例如，Contoso 被網際網路根伺服器授權管理其在網際網路上的 DNS 網域命名空間樹的一部分，也就是 contoso.com。 解析 contoso.com 命名空間外部的名稱需要 Contoso DNS 伺服器來查詢其他 DNS 伺服器，例如根伺服器。

如何組織 DNS 網域命名空間

樹狀結構中使用的任何 DNS 網域名稱在技術上都是網域。 不過，大部分的 DNS 討論會根據層級和常用名稱的方式，以五種方式之一來識別名稱。 例如，註冊給 Contoso 的 DNS 網域名稱（contoso.com）稱為次級網域。 名稱有兩個部分（稱為標籤），表示它位於樹的根或樹頂下的兩個層級。 大部分的 DNS 功能變數名稱都有兩個以上的標籤，每個標籤都表示樹狀結構中的新層級。 在名稱中使用句號來分隔標籤。

下表說明命名空間中 DNS 功能變數名稱的五個類別，以及每個名稱類型的範例。

名稱類型 描述 例
根域 樹狀結構的頂端，代表未命名的層級;它有時會顯示為兩個空引號 （“），表示 Null 值。 在 DNS 網域名稱中使用時，會以結尾的句號（.）表示名稱位於網域階層的根階層或最高層級。 在此實例中，DNS 領域名稱被視為完整，並指向名稱樹的精確位置。 以這種方式陳述的名稱為完整網域名稱（FQDN）。 單一的句號（.）或用於名稱結尾的句號，例如 example.contoso.com. 單一的句號（.）或用於名稱結尾的句號，例如 example.contoso.com.
最上層網域 （TLD） 用來指出國家或地區或使用名稱的組織類型的名稱。 .com，表示註冊給企業以在因特網上使用商業用途的名稱。
第二層網域 註冊給個人或組織以在因特網上使用的可變長度名稱。 這些名稱一律以適當的最上層網域為基礎，視使用名稱的組織類型或地理位置而定。 contoso.com. 是因特網 DNS 功能變數名稱註冊機構向 Contoso 註冊的第二層功能變數名稱。
子域 組織可以建立的其他名稱，這些名稱衍生自已註冊的第二層域名。 子域包含為了擴展組織的 DNS 樹狀結構而新增的名稱，並將其劃分為部門或地理位置。 example.contoso.com. 是由 Contoso 指派的子域，用於檔範例名稱。
主機或資源名稱 特定的名稱代表 DNS 樹狀結構中的節點，並識別特定資源。 一般而言，DNS 功能變數名稱最左邊的標籤會識別網路上的特定電腦。 例如，如果此層級的名稱用於主機 （A） 資源記錄中，則會用來根據其主機名查閱計算機的IP位址。 host-a.example.contoso.com. 第一個標籤 （host-a） 是網路上特定電腦的 DNS 主機名。

DNS 和因特網網域

因特網註冊授權單位管理域名系統。 註冊授權單位負責維護由組織和國家/地區指派的最上層網域。 這些網域名稱遵循國際標準國碼（ISO 3166）。 有數百個最上層域名可供公用使用。 下表顯示幾個常見的 TLD，以及用於國家和地區的兩個字母縮寫範例。

DNS 網域名稱 組織類型
.com 商業組織
.edu 教育機構
。組織 非營利性組織
。網 網路（互聯網骨幹）
.政府網站 非軍事政府組織
。密耳 軍事政府組織
.arpa 功能變數名稱 反向 DNS
.xx 雙字母國家/地區代碼（例如，.us、.au、.ca.、.fr）

DNS 資源記錄

DNS 資源記錄包含區域所包含之資源 （例如主機） 的相關信息。 一般資源記錄包含：

  • 資源記錄的名稱（主機）。
  • 有關資源記錄可保留在快取中多久的資訊。
  • 資源記錄類型，例如主機 （A） 資源記錄。
  • 記錄類型特有的數據，例如主機 IPv4 位址。

您可以直接新增資源記錄，或在啟用 Windows 的動態主機設定通訊協定 （DHCP） 啟用的用戶端使用動態更新加入網路時自動新增這些記錄。

資源記錄的類型

常見的資源記錄包括：

資源記錄類型 描述
主機（A，AAAA）記錄 將主機名對應至IP位址。
別名（CNAME）記錄 將別名網域名稱或子域轉送至另一個主要或規範名稱。 別名 （CNAME） 資源記錄也稱為標準名稱資源記錄。 透過這些記錄，您可以使用多個 DNS 名稱來指向單一主機。
郵件交換器 （MX） 記錄 指定交換或轉寄郵件的計算機名稱。 電子郵件應用程式會使用郵件交換器 （MX） 資源記錄，根據郵件之電子郵件收件者目的地位址中的 DNS 功能變數名稱來尋找郵件伺服器。 如果有多個郵件交換器 （MX） 資源記錄存在，DNS 用戶端服務會嘗試以從最低值（最高優先順序）到最高值（最低優先順序）的順序連絡郵件伺服器。
指针（PTR）記錄 用於反向 DNS 查找以將 IP 位址映射到網域。 指標 PTR 資源記錄支援反向查找過程，根據在 in-addr.arpa 網域中建立並設置根的區域。 您必須在 DNS 伺服器上具有適當的反向對應區域，才能建立將 IP 位址對應至特定主機名的 PTR 記錄。
服務位置 （SRV） 記錄 指定服務的主機、埠和通訊協定。 當用戶端使用 DNS 來尋找 Active Directory 域控制器等位置服務時，需要服務位置 （SRV） 資源記錄。
名稱伺服器 （NS） 記錄 指定網域的權威名稱伺服器。
文字（TXT）記錄 啟用在 DNS 記錄中發布文字的功能。 文字記錄可讓您新增查詢 DNS 所傳回的文字資訊。 TXT 記錄通常用來驗證 DNS 區域的擁有權。
委派名稱 （DNAME） 記錄 提供網域的別名，例如 CNAME 記錄，但包含所有子域。
起始授權（SOA）記錄 提供 DNS 區域的權威資訊。 SOA 記錄包含主要名稱伺服器、DNS 區域管理員聯繫人、重新整理資訊和其他資訊。

資源記錄的存留時間

資源記錄中的存留時間 （TTL） 值表示其他 DNS 伺服器用來判斷在到期前快取記錄資訊的時間長度，並將其捨棄。 例如，由 DNS 伺服器服務建立的大多數資源記錄會從授權單位（SOA）資源記錄繼承一小時的最小（預設）TTL，以防止其他 DNS 伺服器延長快取。

DNS 用戶端解析程式會快取解析 DNS 查詢時所收到的回應。 然後，這些快取的回應可用來回答後續相同信息的查詢。 不過，快取的數據在回應數據傳回的TTL參數中指定了有限的存留期。 TTL 可確保 DNS 伺服器不會保留資訊太久，使其過期。 快取的 TTL 可以在 DNS 資料庫上設定（針對每個個別資源記錄，透過 SOA 記錄的最小 TTL 字段指定每個區域的 TTL 字段），並在 DNS 用戶端解析程式端指定解析程式允許快取資源記錄的最大 TTL。

設定 TTL 時，需要考慮兩個競爭因素。 第一個是快取資訊的正確性，第二個是 DNS 伺服器和網路流量的使用率。 如果 TTL 很短，則有舊資訊的可能性會大幅降低，但會增加 DNS 伺服器和網路流量的使用率，因為 DNS 用戶端必須在下次要求 DNS 伺服器時查詢過期的數據。 如果 TTL 很長，快取的回應可能會過時，這表示解析程式可能會為查詢提供錯誤的解答。 同時，長時間的 TTL 會減少 DNS 伺服器的使用率，並減少網路流量，因為 DNS 用戶端會使用快取的數據來回答查詢。

如果查詢是以快取中的項目回應，則該項目的TTL也會隨著回應一起傳遞。 如此一來，接收回應的解析器就會知道條目的有效期。 解析程式接受來自回應伺服器的TTL;它們不會根據自己的TTL重設它。 因此，當專案從 DNS 伺服器移至具有更新 TTL 的 DNS 伺服器時，專案會真正過期，而不是永久運作。

注意

一般而言，絕對不要將TTL設定為零。 當設置為 0 或 60 時，對記錄準確性的影響很小，但當 TTL 設置為 0 時，會對 DNS 伺服器的性能產生顯著影響，因為 DNS 伺服器會不停地查詢已過期的數據。

區域和委派

DNS 資料庫可以分割成多個區域。 區域是 DNS 資料庫的一部分，其中包含屬於 DNS 命名空間連續部分擁有者名稱的資源記錄。 區域檔案會在 DNS 伺服器上維護。 單個 DNS 伺服器可以設定為承載零、一或多個區域。

每個區域都錨定在特定網域名稱上，稱為區域的根域名。 區域包含以區域根域名結尾之所有名稱的相關信息。 如果 DNS 伺服器載入包含該名稱的區域，則會將其視為授權名稱。 任何區域檔案中的第一條記錄是起始授權 (SOA) 資源記錄。 SOA 資源記錄會將區域的主要 DNS 名稱伺服器識別為該區域內數據的最佳資訊來源。 SOA 也會做為處理區域更新的實體。

區域內的名稱也可以委派給託管在不同 DNS 伺服器上的另一個區域。 委派是將 DNS 命名空間的一部分責任指派給由不同實體擁有的 DNS 伺服器的過程。 此個別實體可以是公司內的另一個組織、部門或工作組。 這類委派是由 NS 資源記錄來表示，該記錄會指定該區域的委派區域和伺服器授權的 DNS 名稱。 跨多個區域委派是 DNS 原始設計目標的一部分。

若要深入瞭解 DNS 區域的類型和複寫，請參閱 DNS 區域。

委派 DNS 命名空間的原因包括：

  • 需要將 DNS 網域的管理委派給組織內的許多組織或部門。

  • 需要將維護一個大型 DNS 資料庫的負載分散到多個 DNS 伺服器，以改善名稱解析效能，並建立 DNS 容錯環境。

  • 需要在適當的網域中納入主機以反映其組織關聯性。 名稱伺服器 （NS） 資源記錄可識別每個區域的 DNS 伺服器，而 NS 資源記錄會出現在所有區域中，以協助委派。 每當 DNS 伺服器需要跨委派才能解析名稱時，它會參考目標區域中 DNS 伺服器的 NS 資源記錄。

下圖顯示了如何在 contoso.com 和 contoso.com這兩個區域中分配 mydomain.contoso.com 網域的管理。

此圖說明 DNS 區域委派的階層式結構，進一步委派至 contoso.com 和 mydomain.contoso.com。

注意

如果委派區域有多個 NS 記錄存在，識別可用於查詢的多個 DNS 伺服器，Windows Server DNS 伺服器服務將能夠根據每個 DNS 伺服器的往返間隔來選取最接近的 DNS 伺服器。

DNS 服務架構

下圖說明 Windows 用戶端和 Windows Server 中 DNS 用戶端服務架構的名稱解析和更新作業。 使用用戶端應用程式示範名稱解析架構，而更新是由 DHCP 用戶端表示。

圖表說明 Windows 用戶端和 Windows Server 中 DNS 用戶端服務架構的名稱解析和更新作業。

下圖說明 DNS 伺服器服務架構及其管理工具和 Windows Server 中的 Windows Management Instrumentation （WMI） 介面。

說明 Windows Server 中 DNS 伺服器服務架構的圖表。

下列各節說明 DNS 查詢程式，以及如何處理 DNS 更新。

DNS 查詢

DNS 查詢可以從 DNS 用戶端（解析程式）傳送至 DNS 伺服器，或在兩部 DNS 伺服器之間傳送。

DNS 查詢只是要求具有指定 DNS 名稱之指定資源記錄類型的 DNS 資源記錄。 例如，DNS 查詢可以請求獲取具有指定 DNS 名稱的所有 A 類型資源記錄。

有兩種類型的 DNS 查詢可以傳送至 DNS 伺服器：

  • 遞歸：遞歸查詢會強制 DNS 伺服器回應失敗或成功回應的要求。 DNS 用戶端（解析程式）通常會進行遞歸查詢。 使用遞歸查詢，DNS 伺服器必須連絡任何其他 DNS 伺服器，才能解析要求。 當它從其他 DNS 伺服器（或伺服器）收到成功的回應時，它會傳送回應給 DNS 用戶端。 遞歸查詢是解析器在查詢 DNS 伺服器，以及 DNS 伺服器在查詢其轉發器時所使用的一般查詢類型，這個轉發器是另一部 DNS 伺服器，被設定用來處理轉發給它的請求。

    當 DNS 伺服器處理遞迴查詢時，若查詢無法從本機資料（如本機區域檔案或先前查詢的快取）中獲得解析，則遞迴查詢必須轉交至根 DNS 伺服器。 DNS 的每個基於標準的實作都包含一個快取檔案（或根伺服器提示檔案），其中包含互聯網域名根 DNS 伺服器的記錄條目。 （如果 DNS 伺服器設定為轉寄站，則會在使用根伺服器之前使用轉寄站。

  • 反覆：反覆查詢是 DNS 伺服器預期會根據 DNS 伺服器從本機區域檔案或快取所知道的內容，回應它擁有的最佳本機資訊。 如果 DNS 伺服器沒有名稱的權威性，則此回應也稱為轉介。 如果 DNS 伺服器沒有任何可回應查詢的本機資訊，則只會傳送負面回應。 DNS 伺服器會在嘗試在其本機網域（或網域）以外尋找名稱時，進行這種類型的查詢（未設定轉寄站時）。 它可能必須查詢 DNS 伺服器外部，以嘗試解析名稱。

下圖顯示這兩種查詢類型的範例。

此圖顯示如何使用多個查詢來判斷 www.contoso.com的IP位址。

此圖顯示如何使用多個查詢來判斷 www.contoso.com的IP位址。 查詢順序描述如下：

  1. www.contoso.com 的遞迴查詢（A 資源紀錄）。

  2. www.contoso.com 的迭代查詢（資源記錄 A）。

  3. 轉介至 .com 名稱伺服器 （NS 資源記錄，適用於 .com）：為了簡單起見，DNS 伺服器的反覆 A 查詢，以解析其他 DNS 伺服器所傳回之名稱伺服器的主機名 IP 位址已被省略。

  4. www.contoso.com 的迭代查詢（資源記錄 A）。

  5. 轉介至 contoso.com 名稱伺服器 （NS 資源記錄，適用於 contoso.com）。

  6. www.contoso.com 的迭代查詢（資源記錄 A）。

  7. 回答來自 contoso.com 伺服器的迭代查詢（www.contoso.com IP 位址）。

  8. 從本機 DNS 伺服器發出的遞歸查詢至解析器的原始回應（www.contoso.com IP 位址）。

更新 DNS

資源記錄通常會隨著計算機、伺服器和裝置新增至網路或從網路中移除而變更。 Windows Server 中的 DNS 實作同時支援 DNS 資料庫的靜態和動態更新。

您可以使用 Add-DNSServerResourceRecord PowerShell 命令，將資源記錄新增至現有的區域。 某些常見的資源記錄類型有其他 PowerShell 命令，而您不需要指定資源記錄類型。 您也可以使用 DNS 管理員主控台來新增資源記錄。 如需使用資源記錄的指引，請參閱 管理 DNS 資源記錄 ，包括建立和修改所有類型的現有資源記錄。

Unicode 字元支援

當 DNS 引進為 RFC 1035 的一部分時，名稱僅限於使用大寫和小寫字母（A-Z、a-z）、數位（0-9）和連字元（-）。 此外，DNS 名稱的第一個字元可以是數位，而且名稱必須使用以US-ASCII為基礎的字元進行編碼和表示。 在國際化設置中使用 DNS 時，這項需求會在使用擴展字元集進行在地命名標準時造成重大限制。 Windows Server DNS 服務除了 RFC 1035 規格之外，還針對 UTF-8 字元提供增強的支援。

什麼是UTF-8？

UTF-8 是針對超越 ASCII 使用而演進的通訊協定所建議的字元集。 UTF-8 通訊協定提供對擴充 ASCII 字元的支援，以及 UCS-2 的轉譯，這是一個 16 位 Unicode 字元集，其中包含世界上大部分的書寫系統。 UTF-8 能夠使得可以表示的名稱範圍比使用 ASCII 或擴充 ASCII 編碼的字元數據更為廣泛。

執行 Windows Server 2008 的電腦具有 UTF-8 感知功能。 這表示當伺服器接收或使用UTF-8編碼的字元做為數據時，伺服器就可以在其區域中載入和儲存此資料。 雖然 Windows 型 DNS 伺服器具有 UTF-8 感知功能，但它們仍與其他使用傳統 US-ASCII 數據編碼和目前 DNS 標準的 DNS 伺服器相容。

DNS 服務如何實作UTF-8

為了與其他 DNS 實作提供標準相容性和互作性，DNS 服務會使用任何接收字元數據的統一縮小功能。 在此程式中，DNS 服務會基於下列原因，將標準 US-ASCII 數據中使用的所有大寫字元轉換成小寫對等數據：

  • 維護與目前和現有 DNS 標準的相容性。
  • 提供無法辨識或支援UTF-8編碼的 DNS 伺服器實作互作性。

若要瞭解為何選擇統一降級，必須先從目前修訂的 DNS 因特網標準考慮幾個相關點。 標準中的數個關鍵點與 DNS 伺服器與其他伺服器和客戶端之間的字元數據處理方式有關。 重點包括：

  • 任何二進位字串都可以用於 DNS 名稱。 （RFC 2181）
  • DNS 伺服器必須能夠以不區分大小寫的方式比較名稱。 （RFC 1035）
  • 應盡可能保留字元數據的原始大小寫，當數據被輸入系統時。 （RFC 1035）

因為不區分大小寫是核心 DNS 標準的必要部分，而案例保留是選擇性的建議，因此已選擇統一降級以提供符合有效標準的解決方案。 藉由在傳輸之前將UTF-8編碼名稱轉為小寫，其他不支援UTF-8的DNS伺服器能夠接收資料並成功地進行二進位比較，從而取得所需的結果。

與UTF-8互作性的考慮

DNS 伺服器服務可以設定為允許或封鎖針對每部伺服器使用 UTF-8 字元。 某些不支援UTF-8的 DNS 伺服器可能會接受UTF-8名稱的區域，但無法儲存或重載這些名稱。 將具有UTF-8名稱的區域傳輸至不支援UTF-8的伺服器時，請小心。

某些通訊協定會限制名稱中允許的字元。 此外，要全域可見的名稱（RFC 1958）應包含僅限 ASCII 的字元，如 RFC 1123 中建議。

使用 UTF-8 來轉換 Unicode 字元對使用者來說是不可見的。 不過，如果您使用網路監視器或類似工具來分析 DNS 流量，則可以看到 UTF-8 編碼字元。

除了UTF-8編碼格式的 DNS 伺服器支援之外，用戶端解析程序預設為使用UTF-8字元編碼格式。

以UTF-8格式編碼的名稱不得超過 RFC 2181 中釐清的大小限制，每個標籤最多 63 個八位，每個名稱最多 255 個八位。 字元數不足以判斷大小，因為某些 UTF-8 字元的長度超過一個位元組。

UTF-8 編碼協定可以適用於預期 US-ASCII 字元的現有 DNS 協定實作，因為在 UTF-8 中，US-ASCII 字元的表示法在每個位元組上都與 US-ASCII 的表示法完全相同。 無法辨識 UTF-8 字元的 DNS 用戶端或伺服器實作一律會以 US-ASCII 格式編碼名稱。 DNS 伺服器服務能夠正確地解譯這些名稱。

DNS 服務可以設定名稱檢查，以允許或限制在 DNS 數據中使用 UTF-8 字元。

根據預設，多位元組 UTF-8 名稱格式檢查將被使用，允許在 DNS 服務處理字元時提供最大的容錯能力。 多位元組UTF-8名稱檢查是大多數未為因特網主機提供名稱服務的私用 DNS 伺服器慣用的名稱檢查方法。