域名系統

出自Local Chinese Wikipedia
（重新導向自Dns）
跳至導覽 跳至搜尋

Template:NoteTA 腳本錯誤：沒有「redirect hatnote」這個模塊。

File:Crystal 128 yast dns.png

腳本錯誤：沒有「sidebar」這個模塊。 Template:Internet

網域名稱系統（Template:Langx，縮寫：DNS）是互聯網的一項服務。它作為將域名和IP位址相互映射的一個分佈式數據庫，能夠使人更方便地訪問互聯網。DNS使用TCP和UDP端口53[1]。當前，對於每一級域名長度的限制是63個字符，域名總長度則不能超過253個字符。

開始時，域名的字符僅限於ASCII字符的一個子集。2008年，ICANN通過一項決議，允許使用其它語言作為互聯網頂級域名的字符。使用基於Punycode碼的IDNA系統，可以將Unicode字符串映射為有效的DNS字符集。因此，諸如「XXX.中國」、「XXX.台灣」的域名可以在地址欄直接輸入並訪問，而不需要安裝插件。但是，由於英語的廣泛使用，使用其他語言字符作為域名會產生多種問題，例如難以輸入、難以在國際推廣等。

歷史[編輯]

DNS最早於1983年由保羅·莫卡派喬斯（Paul Mockapetris）發明；原始的技術規範在882號互聯網標準草案（RFC 882）中發佈。1987年發佈的第1034和1035號草案修正了DNS技術規範，並廢除了之前的第882和883號草案。在此之後對互聯網標準草案的修改基本上沒有涉及到DNS技術規範部分的改動。

早期的域名必須以英文句號脚本错误：没有“Lang”这个模块。結尾。例如，當用戶訪問維基百科的HTTP服務時必須在地址欄中輸入：http://www.wikipedia.org.，這樣DNS才能夠進行域名解析。如今DNS伺服器已經可以自動補上結尾的句號。

記錄類型[編輯]

腳本錯誤：沒有「main」這個模塊。 DNS系統中，常見的資源記錄（腳本錯誤：沒有「Lang」這個模塊。）類型有：

  • 主機記錄（A記錄）：RFC 1035定義，A記錄是用於名稱解析的重要記錄，它將特定的主機名映射到對應主機的IP位址上。
  • 別名記錄（CNAME記錄）: RFC 1035定義，CNAME記錄用於將某個別名指向到某個A記錄上，這樣就不需要再為某個新名字另外創建一條新的A記錄。
  • IPv6主機記錄（AAAA記錄）: RFC 3596定義，與A記錄對應，用於將特定的主機名映射到一個主機的IPv6地址。
  • 服務位置記錄（SRV記錄）: RFC 2782定義，用於定義提供特定服務的伺服器的位置，如主機（hostname），端口（port number）等。
  • 域名伺服器記錄（NS記錄） ：用來指定該域名由哪個DNS伺服器來進行解析。 您註冊域名時，總有默認的DNS伺服器，每個註冊的域名都是由一個DNS域名伺服器來進行解析的，DNS伺服器NS記錄地址一般以以下的形式出現： ns1.domain.com、ns2.domain.com等。 簡單的說，NS記錄是指定由哪個DNS伺服器解析你的域名。
  • NAPTR記錄：RFC 3403定義，它提供了正則表達式方式去映射一個域名。NAPTR記錄非常著名的一個應用是用於ENUM查詢。

傳輸協議[編輯]

DNS over UDP/TCP/53 （Do53）[編輯]

從 1983 年起源到最近，DNS 主要回答 UDP 端口 53 上的查詢。此類查詢包括從客戶端以單個 UDP 數據包發送的明文請求，響應為 從伺服器以單個 UDP 數據包發送的明文回復。 當應答的長度超過 512 字節並且客戶端和伺服器都支持 DNS 擴展機制 (EDNS) 時，可能會使用更大的 UDP 數據包。 DNS-over-UDP 的使用受到限制，其中包括缺乏傳輸層加密、身份驗證、可靠傳遞和消息長度。 1989 年，RFC 1123 為 DNS 查詢、回復，特別是區域傳輸指定了可選的 TCP 傳輸。 通過長響應的分段，TCP 允許更長的響應、可靠的傳遞和重用客戶端和伺服器之間的長期連接。

DNS over TLS （DoT）[編輯]

腳本錯誤：沒有「main」這個模塊。 加密 DNS 的 IETF 標準於 2016 年出現，利用傳輸層安全（TLS）來保護整個連接，而不僅僅是 DNS 有效負載。DoT 伺服器偵聽 TCP 端口 853。Template:IETF RFC 指定可以支持機會加密和認證加密，但沒有強制伺服器或客戶端認證。

DNS over QUIC （DoQ）[編輯]

互聯網工程任務組的 RFC 9250 描述了 DNS over QUIC。

DNS over HTTPS （DoH）[編輯]

腳本錯誤：沒有「main」這個模塊。 2018 年引入了 DNS 查詢傳輸的競爭標準，通過 HTTPS 隧道傳輸 DNS 查詢數據（進而通過 TLS 傳輸 HTTP）。DoH 被推廣為對網絡更友好的 DNS 替代方案，因為與 DNSCrypt 一樣，它在 TCP 端口 443 上傳輸，因此看起來類似於網絡流量[2]，儘管它們在實踐中很容易區分。 DoH 因相對於 DoT 降低用戶匿名性而受到廣泛批評[3]。

Oblivious DNS 和 Oblivious DoH[編輯]

Oblivious DNS （ODNS）[4]是由普林斯頓大學和芝加哥大學的研究人員發明和實施的，作為未加密 DNS 的擴展，在 DoH 本身被標準化和廣泛部署之前。Apple 和 Cloudflare 隨後將該技術部署在 DoH 環境中，稱為 Oblivious DoH （ODoH）[5]。ODoH 將入口/出口分離（在 ODNS 中發明）與 DoH 的 HTTPS 隧道和 TLS 傳輸層加密結合在一個協議中。[6]

DNS over Tor[編輯]

與其他 Internet 協議一樣，DNS 可以通過 VPN 和隧道運行。 DNS-over-Tor 自 2019 年以來已經變得足夠普遍以保證其自己經常使用的首字母縮略詞的一種用途。Oblivious DNS 的私隱效果可以通過使用預先存在的入口和出口節點的 Tor 網絡以及 TLS 提供的傳輸層加密來獲得。[7]

DNSCrypt[編輯]

腳本錯誤：沒有「main」這個模塊。 DNSCrypt協議於 2011 年在 IETF 標準框架之外開發，在遞歸解析器的下游側引入了 DNS 加密，其中客戶端使用伺服器的公鑰加密查詢有效負載，這些公鑰在 DNS 中發佈（而不是依賴於第三方方證書頒發機構），進而可能受到 DNSSEC 簽名的保護。[8]DNSCrypt 使用 TCP 或 UDP 端口 443，與 HTTPS 加密的網絡流量相同的端口。這不僅引入了關於查詢內容的私隱，而且還引入了防火牆穿越能力的重要衡量標準。在 2019 年，DNSCrypt 進一步擴展以支持「匿名」模式，類似於提議的「Oblivious DNS」，其中入口節點接收已使用不同伺服器的公鑰加密的查詢，並將其轉發給該伺服器伺服器充當出口節點，執行遞歸解析。[9]創建用戶/查詢對的私隱，因為入口節點不知道查詢的內容，而出口節點不知道客戶端的身份。 DNSCrypt 於 2011 年 12 月由 OpenDNS 首次在生產環境中實現。有幾個免費和開源軟件實現額外集成了 ODoH[10]。它適用於各種作業系統，包括 Unix、Apple iOS、Linux、Android 和 MS Windows。

技術實現[編輯]

概述[編輯]

DNS通過允許一個名稱伺服器把它的一部分名稱服務（眾所周知的zone）「委託」給子伺服器而實現了一種層次結構的名稱空間。此外，DNS還提供了一些額外的信息，例如系統別名、聯繫信息以及哪一個主機正在充當系統組或域的郵件樞紐。

任何一個使用IP的計算機網絡可以使用DNS來實現它自己的私有名稱系統。儘管如此，當提到在公共的Internet DNS系統上實現的域名時，術語「域名」是最常使用的。

這是基於984個全球範圍的「根域名伺服器」（分成13組，分別編號為A至M）[11]。從這984個根伺服器開始，餘下的Internet DNS命名空間被委託給其他的DNS伺服器，這些伺服器提供DNS名稱空間中的特定部分。

軟件[編輯]

DNS系統是由各式各樣的DNS軟件所驅動的，例如：

  • BIND（Berkeley Internet Name Domain），使用最廣的DNS軟件
  • 腳本錯誤：沒有「ilh」這個模塊。（Dan J Bernstein's DNS implementation）
  • 腳本錯誤：沒有「ilh」這個模塊。
  • 腳本錯誤：沒有「ilh」這個模塊。（Name Server Daemon）
  • PowerDNS
  • Dnsmasq

國際化域名[編輯]

腳本錯誤：沒有「main」這個模塊。 Punycode是一個根據RFC 3492標準而製定的編碼系統，主要用於把域名從地方語言所採用的Unicode編碼轉換成為可用於DNS系統的編碼。而該編碼是根據域名相異字表 （頁面存檔備份，存於互聯網檔案館）（由IANA制定），Punycode可以防止所謂的IDN欺騙。

域名解析[編輯]

舉一個例子，zh.wikipedia.org 作為一個域名就和IP位址198.35.26.96 相對應。DNS就像是一個自動的電話號碼簿，我們可以直接撥打198.35.26.96 的名字zh.wikipedia.org 來代替電話號碼（IP位址）。DNS在我們直接呼叫網站的名字以後就會將像zh.wikipedia.org 一樣便於人類使用的名字轉化成像198.35.26.96 一樣便於機器識別的IP位址。

DNS查詢有兩種方式：遞歸和迭代。DNS客戶端設置使用的DNS伺服器一般都是遞歸伺服器，它負責全權處理客戶端的DNS查詢請求，直到返回最終結果。而DNS伺服器之間一般採用迭代查詢方式。

以查詢 zh.wikipedia.org 為例：

  • 客戶端發送查詢報文"query zh.wikipedia.org"至DNS伺服器，DNS伺服器首先檢查自身緩存，如果存在記錄則直接返回結果。
  • 如果記錄老化或不存在，則：
    1. DNS伺服器向根域名伺服器發送查詢報文"query zh.wikipedia.org"，根域名伺服器返回頂級域 .org 的頂級域名伺服器地址。
    2. DNS伺服器向 .org 域的頂級域名伺服器發送查詢報文"query zh.wikipedia.org"，得到二級域 .wikipedia.org 的權威域名伺服器地址。
    3. DNS伺服器向 .wikipedia.org 域的權威域名伺服器發送查詢報文"query zh.wikipedia.org"，得到主機 zh 的A記錄，存入自身緩存並返回給客戶端。

WHOIS（域名數據庫查詢）[編輯]

一個域名的所有者可以通過查詢WHOIS數據庫[12]而被找到；對於大多數根域名伺服器，基本的WHOIS由ICANN維護，而WHOIS的細節則由控制那個域的域註冊機構維護。

對於240多個國家代碼頂級域名（ccTLDs），通常由該域名權威註冊機構負責維護WHOIS。例如中國互聯網絡信息中心（China Internet Network Information Center）負責.CN域名的WHOIS維護，香港互聯網註冊管理有限公司（Hong Kong Internet Registration Corporation Limited）負責.HK域名的WHOIS維護，台灣網絡資訊中心（Taiwan Network Information Center）負責.TW域名的WHOIS維護。

其他[編輯]

此外，一些黑客通過偽造DNS伺服器將用戶引向錯誤網站，以達到竊取用戶私隱信息的目的。[13]。

相關條目[編輯]

腳本錯誤：沒有「Portal」這個模塊。

頁面Template:Div col/styles.css沒有內容。

參考文獻[編輯]

  1. ↑ （英文）Template:Cite web
  2. ↑ Template:Cite web
  3. ↑ Template:Cite web
  4. ↑ Template:Cite journal
  5. ↑ Template:Cite web
  6. ↑ Template:Cite web
  7. ↑ Template:Cite web
  8. ↑ Template:Cite web
  9. ↑ Template:Cite web
  10. ↑ Template:Cite web
  11. ↑ （英文）Template:Cite web
  12. ↑ Template:Cite web
  13. ↑ Template:Cite news
  • RFC 882
  • RFC 883
  • RFC 1034
  • RFC 1035
  • RFC 1180 - TCP/IP tutorial

外部連結[編輯]

腳本錯誤：沒有「Authority control」這個模塊。腳本錯誤：沒有「Check for unknown parameters」這個模塊。

取自 "https://arolstar52-zhtest.hf.space/index.php?title=域名系统&oldid=4641"