跳轉至內容

智慧財產權與網際網路/域名系統

Add links
來自 Wikibooks，開放世界中的開放書籍
< 智慧財產權與網際網路
最新稽核版本於2024年6月9日檢查。有模板/檔案更改等待稽核。

域名系統（DNS）是用於計算機、服務或連線到網際網路或私有網路的任何資源的分層分散式命名系統。它將各種資訊與分配給每個參與實體的域名相關聯。最重要的是，它將對人類有意義的域名轉換為與網路裝置相關聯的數字識別符號，以便在全球範圍內定位和定址這些裝置。

一個經常使用的比喻來解釋域名系統是，它充當網際網路的電話簿，將使用者友好的計算機主機名轉換為 IP 地址。例如，域名 www.example.com 轉換為地址 192.0.32.10（IPv4）和 2620:0:2d0:200::10（IPv6）。

域名系統使得能夠以有意義的方式將域名分配給網際網路資源和使用者組，而獨立於每個實體的物理位置。因此，即使當前的網際網路路由安排發生變化或參與者使用移動裝置，全球資訊網 (WWW) 超連結和網際網路聯絡資訊也可以保持一致和恆定。網際網路域名比 IP 地址更容易記憶，例如208.77.188.166（IPv4）或2001:db8:1f70::999:de8:7648:6e8（IPv6）。使用者在引用有意義的統一資源定位符 (URL) 和電子郵件地址時會利用這一點，而無需知道計算機如何實際定位它們。

域名系統透過為每個域指定權威名稱伺服器來分配域名和將這些名稱對映到 IP 地址的責任。權威名稱伺服器被指定負責其特定域，並且反過來可以為其子域分配其他權威名稱伺服器。這種機制使 DNS 分散式且容錯，並有助於避免需要不斷查詢和更新的單箇中央登錄檔。

通常，域名系統還會儲存其他型別的資訊，例如接受給定網際網路域的電子郵件的郵件伺服器列表。透過提供全球範圍的、分散式的基於關鍵字的重定向服務，域名系統是網際網路功能的重要組成部分。

其他識別符號，如 RFID 標籤、UPC、電子郵件地址和主機名中的國際字元以及各種其他識別符號，都可能使用 DNS。[1][2]

域名系統還指定了此資料庫服務的技術功能。它將 DNS 協議（DNS 中使用的資料結構和通訊交換的詳細規範）定義為網際網路協議套件的一部分。

模板：IPstack

概述

[編輯 | 編輯原始碼]

網際網路維護兩個主要名稱空間，即域名層次結構[3]和網際網路協議 (IP) 地址空間。[4]域名系統維護域名層次結構，並在其與地址空間之間提供轉換服務。網際網路名稱伺服器和通訊協議實現域名系統。[5]DNS 名稱伺服器是儲存域名 DNS 記錄的伺服器，例如地址 (A) 記錄、名稱伺服器 (NS) 記錄和郵件交換器 (MX) 記錄（另請參見 DNS 記錄型別列表）；DNS 名稱伺服器會以答案響應針對其資料庫的查詢。

歷史

[編輯 | 編輯原始碼]

在網路上使用名稱作為主機數字地址的更簡單、更易於記憶的抽象的做法可以追溯到 ARPANET 時代。在 1982 年 DNS 發明之前，網路上的每臺計算機都從 SRI（現為 SRI International）的一臺計算機檢索名為HOSTS.TXT的檔案。[6][7]HOSTS.TXT 檔案將名稱對映到數字地址。大多數現代作業系統預設情況下仍然存在主機檔案，並且通常包含將 IP 地址 127.0.0.1 對映到“localhost”的對映。許多作業系統使用名稱解析邏輯，允許管理員配置可用名稱解析方法的選擇優先順序。

網路的快速增長使得集中維護的手工製作的 HOSTS.TXT 檔案變得不可持續；有必要實現一個更具可擴充套件性的系統，能夠自動傳播必要的資訊。

在 Jon Postel 的請求下，Paul Mockapetris 於 1983 年發明了域名系統並編寫了第一個實現。原始規範由網際網路工程任務組在RFC 882和RFC 883中釋出，在 1987 年 11 月被RFC 1034[3]和RFC 1035取代。[5]一些其他請求意見書已提出對核心 DNS 協議的各種擴充套件。

1984 年，四名伯克利學生——道格拉斯·特里、馬克·佩恩特、戴維·裡格爾和周頌年——編寫了第一個 Unix 實現，稱為伯克利網際網路名稱域 (BIND) 伺服器。[8]1985 年，DEC 的凱文·鄧拉普對 DNS 實現進行了重大重寫。從那時起，邁克·卡雷爾斯、菲爾·阿爾姆奎斯特和保羅·維克西一直維護著 BIND。BIND 在 20 世紀 90 年代初移植到 Windows NT 平臺。

BIND 被廣泛分發，尤其是在 Unix 系統上，並且是網際網路上使用最廣泛的 DNS 軟體。[9]由於其開原始碼的使用量很大以及隨之而來的審查，以及越來越複雜 的攻擊方法，BIND 中發現了許多安全漏洞[需要引用]。這促成了許多替代名稱伺服器和解析器程式的開發。BIND 版本 9 是從頭開始編寫的，現在其安全記錄與其他現代 DNS 軟體相當。[需要引用]

結構

[編輯 | 編輯原始碼]

域名空間

[編輯 | 編輯原始碼]

域名空間由域名樹組成。樹中的每個節點或葉子都有零個或多個資源記錄，這些記錄儲存與域名相關聯的資訊。樹從根區域開始細分為區域。DNS 區域可能僅包含一個域，也可能包含許多域和子域，具體取決於委託給管理器的管理許可權。

分層域名系統，組織成區域，每個區域由一個名稱伺服器服務

任何區域的管理責任可以透過建立額外的區域來劃分。對於舊空間的一部分，通常以子域的形式，被授權給另一個名稱伺服器和管理實體，稱為委託。舊區域不再對新區域具有權威性。

域名語法

[編輯 | 編輯原始碼]

域名形成規則的明確描述出現在RFC 1035、RFC 1123和RFC 2181中。域名由一個或多個部分組成，技術上稱為標籤，通常透過點連線和分隔，例如example.com.

  • 最右邊的標籤表示頂級域名；例如，域名www.example.com屬於頂級域名com.
  • 域名的層次結構從右到左下降；每個左邊的標籤指定右側域名的細分或子域。例如：標籤example指定了com域名的子域，而www是example.com的子域。此細分樹最多可以有 127 個級別。
  • 每個標籤最多可以包含 63 個字元。完整的域名在其外部點分標籤規範中不得超過 253 個字元。[10]在 DNS 的內部二進位制表示中，最大長度需要 255 個位元組的儲存空間。[3]實際上，一些域名註冊機構可能會有更短的限制。[需要引用]
  • 從技術上講，DNS 名稱可以包含任何可以用八位位元組表示的字元。但是，DNS 根區域和大多數其他子域中允許的域名格式和字元集使用首選格式和字元集。標籤中允許的字元是 ASCII 字元集的子集，包括字元a到z、A到Z、數字0到9以及連字元。此規則稱為LDH 規則（字母、數字、連字元）。域名以不區分大小寫的方式解釋。[11]標籤不能以連字元開頭或結尾。[12]
  • 主機名是至少關聯了一個 IP 地址的域名。例如，域名www.example.com和example.com也是主機名，而com域名則不是。

國際化域名

[編輯 | 編輯原始碼]

DNS 的允許字元集阻止了許多語言的名稱和單詞以其本地字母或文字進行表示。ICANN 批准了應用程式國際化域名 (IDNA) 系統，該系統使用 Punycode 將 Unicode 字串對映到有效的 DNS 字元集。2009 年，ICANN 批准安裝 IDN 國家程式碼頂級域名。此外，許多現有頂級域名 (TLD) 的註冊機構已採用 IDNA。

名稱伺服器

[編輯 | 編輯原始碼]

域名系統由一個分散式資料庫系統維護，該系統使用客戶端-伺服器模型。該資料庫的節點是名稱伺服器。每個域至少有一個權威 DNS 伺服器，用於釋出有關該域以及任何從屬於它的域的名稱伺服器的資訊。層次結構的頂部由根名稱伺服器提供服務，這些伺服器是在查詢（解析）TLD 時要查詢的伺服器。

權威名稱伺服器

[編輯 | 編輯原始碼]

權威名稱伺服器是指提供由原始源（例如，域管理員或透過動態 DNS 方法）配置的答案的名稱伺服器，與透過對另一個名稱伺服器執行常規 DNS 查詢獲得的答案形成對比。僅權威名稱伺服器僅返回對已由管理員專門配置的域名查詢的答案。

權威名稱伺服器可以是主伺服器或從伺服器。主伺服器是儲存所有區域記錄的原始（主）副本的伺服器。從伺服器使用 DNS 協議的自動更新機制與其主伺服器通訊以維護主記錄的相同副本。

每個 DNS 區域都必須分配一組權威名稱伺服器，這些伺服器安裝在父區域的 NS 記錄中。

當域名在域名註冊機構註冊時，其在頂級域名的域名註冊機構的安裝需要分配一個主名稱伺服器和至少一個輔助名稱伺服器。多個名稱伺服器的要求旨在使域即使在其中一個名稱伺服器變得不可訪問或無法執行時也能保持功能。[13]主名稱伺服器的指定完全由賦予域名註冊機構的優先順序決定。為此，通常只需要名稱伺服器的完全限定域名，除非伺服器包含在註冊域中，在這種情況下，還需要相應的 IP 地址。

主名稱伺服器通常是主名稱伺服器，而輔助名稱伺服器可以實現為從伺服器。

權威伺服器透過設定軟體標誌（協議結構位），稱為其響應中的權威答案（AA）位，來指示其提供確定性答案（被認為是權威的）的狀態。[5]此標誌通常在 DNS 管理查詢工具（如 dig）的輸出中突出顯示，以指示響應名稱伺服器是所討論域名的權威機構。[5]

遞迴和快取名稱伺服器

[編輯 | 編輯原始碼]

原則上，權威名稱伺服器足以用於網際網路的執行。但是，如果僅使用權威名稱伺服器，則每個 DNS 查詢都必須從域名系統的根區域開始進行遞迴查詢，並且每個使用者系統都必須實現能夠進行遞迴操作的解析器軟體。

為了提高效率，減少網際網路上的 DNS 流量，並提高終端使用者應用程式的效能，域名系統支援 DNS 快取伺服器，這些伺服器會將 DNS 查詢結果儲存一段時間，該時間由所討論的域名記錄的配置（生存時間）確定。通常，此類快取DNS 伺服器（也稱為DNS 快取）還實現了必要的遞迴演算法，以從 DNS 根開始到查詢域的權威名稱伺服器，解析給定的名稱。透過在名稱伺服器中實現此功能，使用者應用程式在設計和操作方面獲得了效率。

在名稱伺服器中組合 DNS 快取和遞迴功能不是強制性的；這些功能可以在伺服器中獨立實現以用於特殊目的。

網際網路服務提供商通常會為其客戶提供遞迴和快取名稱伺服器。此外，許多家庭網路路由器都實現了 DNS 快取和遞迴器以提高本地網路的效率。

DNS 解析器

[編輯 | 編輯原始碼]

DNS 的客戶端稱為 DNS 解析器。它負責啟動和排序最終導致完全解析（轉換）所需資源的查詢，例如，將域名轉換為 IP 地址。

DNS 查詢可以是非遞迴查詢或遞迴查詢

  • 非遞迴查詢是指 DNS 伺服器提供其本身具有權威性的域的記錄，或者它提供部分結果而無需查詢其他伺服器。
  • 遞迴查詢是指 DNS 伺服器將透過根據需要查詢其他名稱伺服器來完全回答查詢（或給出錯誤）。DNS 伺服器不需要支援遞迴查詢。

解析器或代表解析器遞迴執行的其他 DNS 伺服器使用查詢標頭中的位協商遞迴服務的用法。

解析通常需要遍歷多個名稱伺服器才能找到所需的資訊。但是，一些解析器透過僅與單個名稱伺服器通訊來更簡單地執行。這些簡單的解析器（稱為“存根解析器”）依賴於遞迴名稱伺服器來完成查詢資訊的工作。

操作

[編輯 | 編輯原始碼]

地址解析機制

[編輯 | 編輯原始碼]

域名解析器透過一系列從最右側（頂級）域名標籤開始的查詢，確定負責查詢域名名的相應域名伺服器。

DNS 遞迴解析器諮詢三個名稱伺服器來解析 www.wikipedia.org 的地址。

此過程包括

  1. 網路主機配置了一個初始快取（稱為提示），其中包含已知根名稱伺服器的地址。管理員會定期從可靠來源更新此類提示檔案。
  2. 向其中一個根伺服器查詢以查詢負責頂級域名的伺服器。
  3. 向獲得的 TLD 伺服器查詢二級域名的 DNS 伺服器地址。
  4. 重複上一步，依次處理每個域名標籤，直到最後一步返回所查詢主機的 IP 地址。

該圖說明了主機 www.wikipedia.org 的此過程。

這種簡單形式的機制會給根伺服器帶來巨大的操作負擔，因為每次搜尋地址都從查詢其中一個根伺服器開始。由於它們對於系統的整體功能至關重要，因此如此大量的使用會為每天數萬億次查詢建立一個無法逾越的瓶頸。在實踐中，DNS 伺服器中使用了快取來克服此問題，因此根名稱伺服器實際上只參與了很少一部分總流量。

迴圈依賴和粘合記錄

[編輯 | 編輯原始碼]

委派中的名稱伺服器透過名稱而不是 IP 地址來標識。這意味著解析名稱伺服器必須發出另一個 DNS 請求以找出已將其引用到的伺服器的 IP 地址。如果委派中給出的名稱是提供委派域名的子域名，則存在迴圈依賴關係。在這種情況下，提供委派的名稱伺服器還必須為委派中提到的權威名稱伺服器提供一個或多個 IP 地址。此資訊稱為粘合。委託名稱伺服器以 DNS 響應的附加部分中的記錄形式提供此粘合，並在響應的答案部分中提供委派。

例如，如果以下域名的權威名稱伺服器為example.org是ns1.example.org，則嘗試解析的計算機www.example.org首先解析ns1.example.org。由於ns1包含在example.org中，這需要首先解析example.org，這會產生迴圈依賴關係。為了打破依賴關係，頂級域名org的名稱伺服器將粘合與example.org的委派一起包含。粘合記錄是提供ns1.example.org的 IP 地址的地址記錄。解析器使用這些 IP 地址中的一個或多個來查詢域的權威伺服器之一，這使其能夠完成 DNS 查詢。

記錄快取

[編輯 | 編輯原始碼]

由於為公共網際網路生成的 DNS 請求量很大，因此設計人員希望提供一種機制來減少單個 DNS 伺服器的負載。為此，DNS 解析過程允許在答案一段時間後快取記錄。這包括本地記錄和隨後查閱副本，而不是發起新的上游請求。解析器快取 DNS 響應的時間由每個記錄關聯的稱為生存時間 (TTL) 的值確定。TTL 由發出權威響應的 DNS 伺服器的管理員設定。有效期可以從幾秒到幾天甚至幾周不等。

作為這種分散式和快取架構的一個值得注意的結果，DNS 記錄的更改不會立即傳播到整個網路，而是需要所有快取在 TTL 後過期並重新整理。RFC 1912 傳達了確定適當 TTL 值的基本規則。

某些解析器可能會覆蓋 TTL 值，因為協議支援最多快取 68 年或根本不快取。負快取，即快取記錄不存在的事實，由負責區域的名稱伺服器確定，該伺服器在報告請求型別的任何資料不存在時必須包含起始授權 (SOA) 記錄。SOA 記錄的MINIMUM欄位的值以及 SOA 本身的 TTL 用於建立負答案的 TTL。

反向查詢

[編輯 | 編輯原始碼]

反向查詢是在已知 IP 地址的情況下查詢 DNS 以獲取域名。多個域名可能與一個 IP 地址關聯。DNS 以特殊格式的名稱（指標（PTR）記錄）的形式儲存基礎結構頂級域名 arpa 中的 IP 地址。對於 IPv4，該域名是in-addr.arpa。對於 IPv6，反向查詢域名是ip6.arpa。IP 地址以反向排序的八位位元組表示形式表示（對於 IPv4），以及反向排序的四位位元組表示形式表示（對於 IPv6）。

執行反向查詢時，DNS 客戶端會將地址轉換為這些格式，然後查詢名稱以獲取 PTR 記錄，這與任何 DNS 查詢一樣，遵循委派鏈。例如，IPv4 地址208.80.152.2表示為 DNS 名稱為2.152.80.208.in-addr.arpa。DNS 解析器首先查詢根伺服器，這些伺服器指向 ARIN 的208.in-addr.arpa區域伺服器。從那裡分配 Wikimedia 伺服器152.80.208.in-addr.arpa，並且透過查詢 wikimedia 名稱伺服器2.152.80.208.in-addr.arpa來完成 PTR 查詢，這將產生權威響應。

客戶端查詢

[編輯 | 編輯原始碼]
DNS 解析序列

使用者通常不會直接與 DNS 解析器通訊。相反，DNS 解析會在 Web 瀏覽器、電子郵件客戶端和其他 Internet 應用程式等應用程式程式中透明地進行。當應用程式發出需要域名查詢的請求時，此類程式會將解析請求傳送到本地作業系統中的DNS 解析器，然後該解析器處理所需的通訊。

DNS 解析器幾乎總是會擁有一個快取（見上文），其中包含最近的查詢。如果快取可以提供請求的答案，則解析器會將快取中的值返回給發出請求的程式。如果快取不包含答案，則解析器會將請求傳送到一個或多個指定的 DNS 伺服器。對於大多數家庭使用者而言，機器連線到的網際網路服務提供商通常會提供此 DNS 伺服器：此類使用者要麼手動配置了該伺服器的地址，要麼允許 DHCP 設定它；但是，在系統管理員已將系統配置為使用自己的 DNS 伺服器的情況下，其 DNS 解析器將指向組織單獨維護的名稱伺服器。無論如何，因此查詢的名稱伺服器都將遵循上面概述的過程，直到它成功找到結果或找不到結果。然後，它將其結果返回給 DNS 解析器；假設它已找到結果，則解析器會適當地快取該結果以供將來使用，並將結果交還給啟動請求的軟體。

損壞的解析器

[編輯 | 編輯原始碼]

當解析器違反 DNS 協議規則時，會產生另一層複雜性。一些大型 ISP 已將其 DNS 伺服器配置為違反規則（可能是為了讓他們能夠在比完全相容的解析器更便宜的硬體上執行），例如，不遵守 TTL，或者僅僅因為其名稱伺服器之一沒有響應而指示域名不存在。[14]

作為最後一層複雜性，某些應用程式（如 Web 瀏覽器）也擁有自己的 DNS 快取，以減少對 DNS 解析器庫本身的使用。此做法在除錯 DNS 問題時可能會增加額外的難度，因為它會掩蓋資料的最新程度和/或哪些資料來自哪個快取。這些快取通常使用非常短的快取時間——大約一分鐘。[需要引用]

Internet Explorer 是一個值得注意的例外：最高版本 IE 3.x 預設情況下會快取 DNS 記錄 24 小時。Internet Explorer 4.x 及更高版本（直至 IE 8）將預設超時值減少到半小時，這可以在相應的登錄檔項中更改。[15]

其他應用程式

[編輯 | 編輯原始碼]

上面概述的系統提供了一個稍微簡化的場景。域名系統包含其他幾個功能

  • 主機名和 IP 地址不一定是一對一匹配的。多個主機名可能對應於單個 IP 地址：結合虛擬主機，這允許一臺機器服務於多個網站。或者，單個主機名可能對應於多個 IP 地址：這可以促進容錯和負載分配，並且還允許站點無縫地移動物理位置。
  • 除了將名稱轉換為 IP 地址外，DNS 還有許多用途。例如，郵件傳輸代理使用 DNS 找出要將特定地址的電子郵件傳送到哪裡。MX 記錄提供的域名到郵件交換機對映在名稱到 IP 地址對映之上提供了另一層容錯和負載分配。

  • **郵件黑名單：** DNS 系統用於高效儲存和分發被列入黑名單的郵件主機 IP 地址。常見的方法是將目標主機的 IP 地址放入更高級別域名（higher level domain name）的子域名中，並解析該名稱為不同的記錄以指示是正向還是負向。這是一個假設的黑名單示例。
    • 102.3.4.5 被列入黑名單 => 建立 5.4.3.102.blacklist.example 並解析為 127.0.0.1
    • 102.3.4.6 未被列入 => 6.4.3.102.blacklist.example 未找到，或預設為 127.0.0.2
    • 然後，郵件伺服器可以透過 DNS 機制查詢 blacklist.example，以瞭解連線到它們的特定主機是否在黑名單中。如今，許多此類黑名單，無論是免費的還是基於訂閱的，主要供電子郵件管理員和反垃圾郵件軟體使用。
  • **軟體更新：** 許多反病毒和商業軟體現在使用 DNS 系統儲存最新軟體更新的版本號，這樣客戶端計算機就不需要每次都連線到更新伺服器。對於這些型別的應用程式，DNS 記錄的快取時間通常較短。
  • 傳送者策略框架 (SPF) 和 DomainKeys 並沒有建立自己的記錄型別，而是設計為利用另一種 DNS 記錄型別：TXT 記錄。
  • 為了在計算機故障時提供彈性，通常會為每個域提供多個 DNS 伺服器以實現覆蓋，並且在頂級，存在 13 個功能強大的根伺服器，以及透過 Anycast 分佈在全球的幾個根伺服器的額外“副本”。
  • **動態 DNS（有時稱為 DDNS）** 允許客戶端在 IP 地址更改時更新其 DNS 條目，例如，在 ISP 或移動熱點之間切換時。

協議細節

[編輯 | 編輯原始碼]

DNS 主要使用使用者資料報協議 (UDP) 在 53 埠上提供服務請求。[5] DNS 查詢由客戶端發出的單個 UDP 請求以及伺服器發出的單個 UDP 回覆組成。當響應資料大小超過 512 位元組或執行區域傳送等任務時，使用傳輸控制協議 (TCP)。一些解析器實現對所有查詢都使用 TCP。

DNS 資源記錄

[編輯 | 編輯原始碼]

**資源記錄 (RR)** 是域名系統中的基本資料元素。每個記錄都有一個型別 (A、MX 等)、一個過期時間限制、一個類以及一些特定於型別的的資料。相同型別的資源記錄定義一個資源記錄集 (RRset)。解析器返回給應用程式的集合中資源記錄的順序未定義，但伺服器通常實現輪循排序以實現負載平衡。但是，DNSSEC 基於規範順序處理完整的資源記錄集。

當透過 IP 網路傳送時，所有記錄都使用 RFC 1035 中指定的通用格式。[16]

RR（資源記錄）欄位
欄位 描述 長度（八位位元組）
NAME 此記錄所涉及的節點的名稱 (可變)
TYPE RR 的型別，以數字形式表示（例如，MX RR 為 15） 2
CLASS 類程式碼 2
TTL RR 保持有效的秒數（最大值為 231-1，大約 68 年。） 4
RDLENGTH RDATA 欄位的長度 2
RDATA 其他 RR 特定資料 (可變)

NAME 是樹中節點的完全限定域名。在網路上傳輸時，可以使用標籤壓縮來縮短名稱，其中資料包中前面提到的域名末尾可以替換為當前域名末尾。

TYPE 是記錄型別。它指示資料的格式，並暗示其預期用途。例如，A 記錄用於將域名轉換為 IPv4 地址，NS 記錄列出哪些名稱伺服器可以回答 DNS 區域中的查詢，而 MX 記錄指定用於處理電子郵件地址中指定的域的郵件的郵件伺服器（另請參見 DNS 記錄型別列表）。

RDATA 是與型別相關的特定資料，例如地址記錄的 IP 地址，或 MX 記錄的優先順序和主機名。眾所周知的記錄型別可以在 RDATA 欄位中使用標籤壓縮，但“未知”記錄型別不得使用 (RFC 3597)。

記錄的CLASS 設定為IN(用於Internet)，用於涉及 Internet 主機名、伺服器或 IP 地址的常用 DNS 記錄。此外，還存在 Chaos 類（CH）和 Hesiod 類（HS）。[17]每個類都是一個獨立的名稱空間，可能具有不同的 DNS 區域委派。

除了在區域檔案中定義的資源記錄之外，域名系統還定義了幾種請求型別，這些請求型別僅用於與其他 DNS 節點（線上）通訊，例如執行區域傳送 (AXFR/IXFR) 或 EDNS (OPT) 時。

萬用字元 DNS 記錄

[編輯 | 編輯原始碼]

域名系統支援萬用字元域名，這些域名以星號標籤“*”開頭，例如：*.example.[3][18]屬於萬用字元域名的 DNS 記錄指定了在單個 DNS 區域內生成資源記錄的規則，方法是用查詢名稱（包括任何指定的子代）的匹配元件替換整個標籤。例如，在 DNS 區域x.example中，以下配置指定x.example的所有子域（包括子域的子域）都使用郵件交換器a.x.example。需要a.x.example的記錄來指定郵件交換器。由於這會導致排除此域名及其子域與萬用字元匹配，因此a.x.example的所有子域必須在單獨的萬用字元語句中定義。

RFC 4592 改進了萬用字元記錄的作用，因為 RFC 1034 中的原始定義不完整，導致實現者誤解。[18]

協議擴充套件

[編輯 | 編輯原始碼]

原始的 DNS 協議對擴充套件新功能的規定有限。1999 年，Paul Vixie 在 RFC 2671 中釋出了一種擴充套件機制，稱為 DNS 的擴充套件機制 (EDNS)，它引入了可選的協議元素，而不會在不使用時增加開銷。這是透過OPT偽資源記錄實現的，該記錄僅存在於協議的網路傳輸中，而不存在於任何區域檔案中。還建議了初始擴充套件 (EDNS0)，例如增加 UDP 資料報中 DNS 訊息的大小。

動態區域更新

[編輯 | 編輯原始碼]

動態 DNS 更新使用UPDATEDNS 操作碼以動態方式新增或刪除權威 DNS 伺服器上維護的區域資料庫中的資源記錄。RFC 2136 中描述了此功能。此功能對於在網路客戶端啟動或在網路上可用時將其註冊到 DNS 中很有用。由於啟動的客戶端每次可能從 DHCP 伺服器分配不同的 IP 地址，因此無法為這些客戶端提供靜態 DNS 分配。

安全問題

[編輯 | 編輯原始碼]

最初，安全問題不是 DNS 軟體或任何用於在早期網際網路上部署的軟體的主要設計考慮因素，因為網路尚未向公眾開放。但是，網際網路在 1990 年代擴充套件到商業領域，改變了安全措施的要求，以保護資料完整性和使用者身份驗證。

惡意使用者發現了多個漏洞問題並加以利用。其中一個問題是DNS快取投毒，攻擊者偽裝成權威源伺服器，將資料分發到快取解析器，從而用可能錯誤的資訊和較長的過期時間（生存時間）汙染資料儲存。隨後，合法的應用程式請求可能會被重定向到惡意操作的網路主機。

傳統的DNS響應沒有使用加密簽名，導致了許多攻擊的可能性；域名系統安全擴充套件（DNSSEC）修改了DNS，增加了對加密簽名響應的支援。還設計了一些擴充套件來保護區域傳輸的安全。

某些域名可能被用來實現欺騙效果。例如，paypal.com和paypa1.com是不同的名稱，但使用者可能無法在圖形使用者介面中區分它們，具體取決於使用者選擇的字型。在許多字型中，字母l和數字1看起來非常相似，甚至完全相同。在支援國際化域名（IDN）的系統中，這個問題尤其嚴重，因為ISO 10646中的許多字元程式碼在典型的計算機螢幕上可能看起來相同。此漏洞偶爾會被網路釣魚攻擊利用。[19]

諸如前向確認反向DNS之類的技術也可用於幫助驗證DNS結果。

域名註冊

[編輯 | 編輯原始碼]

域名使用權由域名註冊商授權，域名註冊商由網際網路名稱與數字地址分配機構（ICANN）認證，該機構負責監督網際網路的名稱和數字系統。除了ICANN之外，每個頂級域名（TLD）在技術上都由一個管理組織維護和服務，並運營一個註冊機構。註冊機構負責維護其管理的頂級域名中註冊的名稱資料庫。註冊機構從每個被授權在相應頂級域名中分配名稱的域名註冊商處接收註冊資訊，並使用特殊的服務（whois協議）釋出這些資訊。

ICANN 釋出了完整的頂級域名註冊機構和域名註冊商列表。與域名關聯的註冊人資訊儲存在一個可透過WHOIS服務訪問的線上資料庫中。對於超過240個國家程式碼頂級域名（ccTLD）中的大多數，域名註冊機構維護WHOIS（註冊人、名稱伺服器、過期日期等）資訊。例如，德國NIC DENIC持有DE域資料。大約從2001年開始，大多數gTLD註冊機構採用了這種所謂的“厚”註冊機構方法，即在中央註冊機構而不是註冊商資料庫中儲存WHOIS資料。

對於COM和NET域名，使用“薄”註冊機構模型：域名註冊機構（例如VeriSign）儲存基本的WHOIS（註冊商和名稱伺服器等）資料。可以在註冊商處找到詳細的WHOIS（註冊人、名稱伺服器、過期日期等）。

一些域名註冊機構，通常稱為“網路資訊中心”（NIC），也充當終端使用者的註冊商。主要的通用頂級域名註冊機構，例如COM, NET, ORG, INFO域，使用由許多域名註冊商組成的註冊機構-註冊商模型[20][21]在這種管理方法中，註冊機構僅管理域名資料庫以及與註冊商的關係。“註冊人”（域名使用者）是註冊商的客戶，在某些情況下，透過額外的經銷商層級。

網際網路標準

[編輯 | 編輯原始碼]

域名系統由網際網路工程任務組（IETF）釋出的請求意見書（RFC）文件定義（網際網路標準）。以下是定義DNS協議的RFC列表。

  • RFC 920，域名要求 – 指定了最初的頂級域名
  • RFC 1032，域名管理員指南
  • RFC 1033，域名管理員操作指南
  • RFC 1034，域名 - 概念和設施
  • RFC 1035，域名 - 實現和規範
  • RFC 1101，網路名稱和其他型別的DNS編碼
  • RFC 1123，網際網路主機要求 - 應用和支援
  • RFC 1178，為您的計算機選擇名稱（FYI 5）
  • RFC 1183，新的DNS RR定義
  • RFC 1591，域名系統結構和委託（資訊性）
  • RFC 1912，常見的DNS操作和配置錯誤
  • RFC 1995，DNS中的增量區域傳輸
  • RFC 1996，區域更改的及時通知機制（DNS NOTIFY）
  • RFC 2100，主機的命名（資訊性）
  • RFC 2136，域名系統中的動態更新（DNS UPDATE）
  • RFC 2181，DNS規範的澄清
  • RFC 2182，輔助DNS伺服器的選擇和操作
  • RFC 2308，DNS查詢的負快取（DNS NCACHE）
  • RFC 2317，無類IN-ADDR.ARPA委託（BCP 20）
  • RFC 2671，DNS的擴充套件機制（EDNS0）
  • RFC 2672，非終端DNS名稱重定向
  • RFC 2845，DNS的金鑰交易身份驗證（TSIG）
  • RFC 3225，指示解析器支援DNSSEC
  • RFC 3226，DNSSEC和IPv6 A6感知伺服器/解析器訊息大小要求
  • RFC 3597，未知DNS資源記錄（RR）型別的處理
  • RFC 3696，名稱檢查和轉換的應用程式技術（資訊性）
  • RFC 4343，域名系統（DNS）大小寫不敏感性說明
  • RFC 4592，萬用字元在域名系統中的作用
  • RFC 4635，HMAC SHA TSIG演算法識別符號
  • RFC 4892，識別名稱伺服器例項的機制要求（資訊性）
  • RFC 5001，DNS名稱伺服器識別符號（NSID）選項
  • RFC 5452，增強DNS對偽造答案的抵禦能力的措施
  • RFC 5625，DNS代理實現指南（BCP 152）
  • RFC 5890，應用程式的國際化域名（IDNA）：定義和文件框架
  • RFC 5891，應用程式中的國際化域名（IDNA）：協議
  • RFC 5892，Unicode程式碼點和應用程式的國際化域名（IDNA）
  • RFC 5893，應用程式的國際化域名（IDNA）的從右到左指令碼
  • RFC 5894，應用程式的國際化域名（IDNA）：背景、解釋和基本原理（資訊性）
  • RFC 5895，2008年應用程式的國際化域名（IDNA）字元對映（資訊性）
  • RFC 6195，域名系統（DNS）IANA注意事項（BCP 42）

安全

[編輯 | 編輯原始碼]
  • RFC 4033，DNS 安全性介紹和需求
  • RFC 4034，DNS 安全性擴充套件的資源記錄
  • RFC 4035，DNS 安全性擴充套件的協議修改
  • RFC 4509，在 DNSSEC 委派簽名者 (DS) 資源記錄中使用 SHA-256
  • RFC 4470，最小覆蓋 NSEC 記錄和 DNSSEC 線上簽名
  • RFC 5011，DNS 安全性 (DNSSEC) 信任錨點的自動更新
  • RFC 5155，DNS 安全性 (DNSSEC) 雜湊身份驗證的否定存在
  • RFC 5702，在 DNSSEC 的 DNSKEY 和 RRSIG 資源記錄中使用 RSA 的 SHA-2 演算法
  • RFC 5910，域名系統 (DNS) 安全性擴充套件的可擴充套件配置協議 (EPP) 對映
  • RFC 5933，在 DNSSEC 的 DNSKEY 和 RRSIG 資源記錄中使用 GOST 簽名演算法

參考文獻

[編輯 | 編輯原始碼]
  1. ↑ Mockapetris, Paul (2004-01-02)。"釋放 DNS"。CircleID。RFID 標籤、UPC 程式碼、電子郵件地址和主機名中的國際字元以及各種其他識別符號都可以進入 DNS [...]——它已準備好承載任意識別符號。
  2. ↑ Mockapetris, Paul (1989 年 4 月)。"RFC 1101：網路名稱和其他型別的 DNS 編碼”。第 1 頁。DNS 是可擴充套件的，可用於幾乎無限數量的資料型別、名稱空間等。 {{cite web}}： 缺少或為空 |url= (幫助)
  3. ↑ a b c d RFC 1034，域名 - 概念和設施，P. Mockapetris，網際網路協會 (1987 年 11 月) 無效的<ref>標籤；名稱“rfc1034”多次定義，但內容不同
  4. ↑ RFC 781，網際網路協議 - DARPA 網際網路程式協議規範，資訊科學研究所，J. Postel（編輯），網際網路協會 (1981 年 9 月)
  5. ↑ a b c d e RFC 1035，域名 - 實現和規範，P. Mockapetris，網際網路協會 (1987 年 11 月) 無效的<ref>標籤；名稱“rfc1035”多次定義，但內容不同
  6. ↑ RFC 3467，域名系統 (DNS) 的作用，J.C. Klensin，J. Klensin (2003 年 2 月)
  7. ↑ Cricket Liu，Paul Albitz (2006)。DNS 和 BIND (第 5 版)。O'Reilly。第 3 頁。
  8. ↑ Douglas Brian Terry、Mark Painter、David W. Riggle 和 Songnian Zhou，伯克利網際網路域名伺服器，美國計算機協會夏季會議論文集，猶他州鹽湖城，1984 年 6 月，第 23-31 頁。
  9. ↑ "DNS 伺服器調查"。
  10. ↑ RFC 2181，DNS 規範的澄清，R. Elz，R. Bush (1997 年 7 月)
  11. ↑ IETF 的網路工作組，2006 年 1 月，RFC 4343：域名系統 (DNS) 不區分大小寫澄清
  12. ↑ RFC 3696，檢查和轉換名稱的應用程式技術，J.C. Klensin，J. Klensin
  13. ↑ "techterms.com 上的名稱伺服器定義"。
  14. ↑ "提供商是否忽略 DNS TTL？"。Slashdot。2005。檢索於 2009-01-03。
  15. ↑ "Internet Explorer 如何使用快取儲存 DNS 主機條目"。微軟公司。2004。檢索於 2010-07-25。
  16. ↑ RFC 5395，域名系統 (DNS) IANA 注意事項，D. Eastlake 第 3 版 (2008 年 11 月)，第 3 節
  17. ↑ RFC 5395，域名系統 (DNS) IANA 注意事項，D. Eastlake 第 3 版 (2008 年 11 月)，第 11 頁

  18. ↑ a b RFC 4592，域名系統中萬用字元的作用，E. Lewis（2006年7月）
  19. ↑ APWG。“全球網路釣魚調查：2010年上半年域名使用情況和趨勢。” 2010年10月15日 apwg.org
  20. ↑ ICANN 授權註冊機構
  21. ↑ VeriSign COM 和 NET 註冊機構
[編輯 | 編輯原始碼]
檢索自“https://wikibook.tw/w/index.php?title=Intellectual_Property_and_the_Internet/Domain_Name_System&oldid=4414707”
華夏公益教科書