域名系統

網域名稱系統（英語：Domain Name System，縮寫：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技術規範部分的改動。

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

記錄類型[編輯]

DNS系統中，常見的資源記錄類型有：

主機記錄（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）[編輯]

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

DNS over QUIC （DoQ）[編輯]

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

DNS over HTTPS （DoH）[編輯]

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[編輯]

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軟件
DJBDNS（英語：djbdns）（Dan J Bernstein's DNS implementation）
MaraDNS（英語：MaraDNS）
Name Server Daemon（英語：NSD）（Name Server Daemon）
PowerDNS
Dnsmasq

國際化域名[編輯]

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]。

參考文獻[編輯]

^ （英文）P. Mockapetris. RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION: Page 32. 1987-11 [2018-04-24]. （原始內容存檔於2011-02-12）. The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal).
^ Csikor, Levente; Divakaran, Dinil Mon. Privacy of DNS-over-HTTPS: Requiem for a Dream? (PDF). National University of Singapore. February 2021 [2022-10-14]. （原始內容存檔 (PDF)於2023-03-15）. We investigate whether DoH traffic is distinguishable from encrypted Web traffic. To this end, we train a machine learning model to classify HTTPS traffic as either Web or DoH. With our DoH identification model in place, we show that an authoritarian ISP can identify ~97.4% of the DoH packets correctly while only misclassifying 1 in 10,000 Web packets.
^ Posch, Maya. DNS-over-HTTPS is the Wrong Partial Solution. Hackaday. 21 October 2019 [2022-10-14]. （原始內容存檔於2023-03-14）. DoH removes options for network operators (private and corporate) to secure their own network, as one of the architects behind DNS, Paul Vixie, pointed out on Twitter last year. DoH is essentially DNS-over-HTTP-over-TLS, resulting in its own mime Media Type of application/dns-message and significant added complexity. By mixing DoH in with existing protocols, it means that every DNS request and response goes through an HTTPS stack. For embedded applications this is a nightmare scenario, but it is also incompatible with nearly every piece of existing security hardware. When rogue apps like Firefox circumvent the system's DoT-based DNS and use its own DNS resolver over DoH instead, this makes for a highly opaque security situation. That DNS resolving would move into individual applications, as we see happening now, seems like a massive step backwards.
^ Schmitt, Paul; Edmundson, Anne; Feamster, Nick. Oblivious DNS: Practical Privacy for DNS Queries (PDF). Privacy Enhancing Technologies. 2019, 2019 (2): 228–244 [2022-10-14]. S2CID 44126163. doi:10.2478/popets-2019-0028. （原始內容存檔 (PDF)於2023-03-15）.
^ Oblivious DNS Deployed by Cloudflare and Apple. [27 July 2022]. （原始內容存檔於2023-03-06）.
^ Pauly, Tommy. Oblivious DNS Over HTTPS. IETF. 2 September 2021 [2022-10-14]. （原始內容存檔於2022-05-24）.
^ Muffett, Alec. "No Port 53, Who Dis?" A Year of DNS over HTTPS over Tor (PDF). Network and Distributed System Security Symposium. February 2021 [2022-10-14]. （原始內容存檔 (PDF)於2023-03-06）. DNS-over-HTTPS (DoH) obviates many but not all of the risks, and its transport protocol (i.e. HTTPS) raises concerns of privacy due to (e.g.) 'cookies.' The Tor Network exists to provide TCP circuits with some freedom from tracking, surveillance, and blocking. Thus: In combination with Tor, DoH, and the principle of "Don't Do That, Then" (DDTT) to mitigate request fingerprinting, I describe DNS over HTTPS over Tor (DoHoT).
^ Ulevitch, David. DNSCrypt – Critical, fundamental, and about time.. Cisco Umbrella. 6 December 2011. （原始內容存檔於1 July 2020）（美國英語）.
^ Anonymized DNSCrypt specification. GitHub. DNSCrypt. （原始內容存檔於25 October 2019）.
^ Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki. GitHub. DNSCrypt project. [28 July 2022]. （原始內容存檔於2023-03-06）（英語）.
^ （英文）Root Server Technical Operations Assn. [2014年1月28日]. （原始內容存檔於2017年8月24日）.
^ Whois.net. [2018-08-05]. （原始內容存檔於2021-01-20）.
^ JORDAN ROBERTSON. Use of Rogue DNS Servers on Rise. The Associated Press. [2008-02-18]. （原始內容存檔於2008-02-17）.

RFC 882
RFC 883
RFC 1034
RFC 1035
RFC 1180 - TCP/IP tutorial

外部連結[編輯]

DNS協議詳細資料（頁面存檔備份，存於網際網路檔案館）
DNS & BIND Resources（頁面存檔備份，存於網際網路檔案館）
DNS Security Extensions (DNSS)（頁面存檔備份，存於網際網路檔案館）
Root Server (EC) （頁面存檔備份，存於網際網路檔案館）

[1] （英文）P. Mockapetris. RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION: Page 32. 1987-11 [2018-04-24]. （原始內容存檔於2011-02-12）. The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal).

[2] Csikor, Levente; Divakaran, Dinil Mon. Privacy of DNS-over-HTTPS: Requiem for a Dream? (PDF). National University of Singapore. February 2021 [2022-10-14]. （原始內容存檔 (PDF)於2023-03-15）. We investigate whether DoH traffic is distinguishable from encrypted Web traffic. To this end, we train a machine learning model to classify HTTPS traffic as either Web or DoH. With our DoH identification model in place, we show that an authoritarian ISP can identify ~97.4% of the DoH packets correctly while only misclassifying 1 in 10,000 Web packets.

[3] Posch, Maya. DNS-over-HTTPS is the Wrong Partial Solution. Hackaday. 21 October 2019 [2022-10-14]. （原始內容存檔於2023-03-14）. DoH removes options for network operators (private and corporate) to secure their own network, as one of the architects behind DNS, Paul Vixie, pointed out on Twitter last year. DoH is essentially DNS-over-HTTP-over-TLS, resulting in its own mime Media Type of application/dns-message and significant added complexity. By mixing DoH in with existing protocols, it means that every DNS request and response goes through an HTTPS stack. For embedded applications this is a nightmare scenario, but it is also incompatible with nearly every piece of existing security hardware. When rogue apps like Firefox circumvent the system's DoT-based DNS and use its own DNS resolver over DoH instead, this makes for a highly opaque security situation. That DNS resolving would move into individual applications, as we see happening now, seems like a massive step backwards.

[4] Schmitt, Paul; Edmundson, Anne; Feamster, Nick. Oblivious DNS: Practical Privacy for DNS Queries (PDF). Privacy Enhancing Technologies. 2019, 2019 (2): 228–244 [2022-10-14]. S2CID 44126163. doi:10.2478/popets-2019-0028. （原始內容存檔 (PDF)於2023-03-15）.

[5] Oblivious DNS Deployed by Cloudflare and Apple. [27 July 2022]. （原始內容存檔於2023-03-06）.

[6] Pauly, Tommy. Oblivious DNS Over HTTPS. IETF. 2 September 2021 [2022-10-14]. （原始內容存檔於2022-05-24）.

[7] Muffett, Alec. "No Port 53, Who Dis?" A Year of DNS over HTTPS over Tor (PDF). Network and Distributed System Security Symposium. February 2021 [2022-10-14]. （原始內容存檔 (PDF)於2023-03-06）. DNS-over-HTTPS (DoH) obviates many but not all of the risks, and its transport protocol (i.e. HTTPS) raises concerns of privacy due to (e.g.) 'cookies.' The Tor Network exists to provide TCP circuits with some freedom from tracking, surveillance, and blocking. Thus: In combination with Tor, DoH, and the principle of "Don't Do That, Then" (DDTT) to mitigate request fingerprinting, I describe DNS over HTTPS over Tor (DoHoT).

[8] Ulevitch, David. DNSCrypt – Critical, fundamental, and about time.. Cisco Umbrella. 6 December 2011. （原始內容存檔於1 July 2020）（美國英語）.

[Anonymized_DNSCrypt_specification-9] Anonymized DNSCrypt specification. GitHub. DNSCrypt. （原始內容存檔於25 October 2019）.

[ODoH_(2022)-10] Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki. GitHub. DNSCrypt project. [28 July 2022]. （原始內容存檔於2023-03-06）（英語）.

[11] （英文）Root Server Technical Operations Assn. [2014年1月28日]. （原始內容存檔於2017年8月24日）.

[12] Whois.net. [2018-08-05]. （原始內容存檔於2021-01-20）.

[13] JORDAN ROBERTSON. Use of Rogue DNS Servers on Rise. The Associated Press. [2008-02-18]. （原始內容存檔於2008-02-17）.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]