DNS加密說明,dns加密

DNS加密說明

域名系統（DNS）是互聯網的地址簿。當您訪問cloudflare.com或任何其他站點時，您的瀏覽器將向DNS解析器詢問可以找到站點的IP地址。不幸的是，這些DNS查詢和回應通常是不受保護的。加密DNS將改善用戶隱私和安全性。在本文中，我們將研究兩種用于加密DNS的機制，稱為DNS over TLS（DoT）以及DNS over HTTPS（DoH），并解釋它們的工作原理。

希望將域名解析為IP地址的應用程序通常都會用到DNS。通常，編寫應用程序的程序員不會明確地做到這一點。取而代之的是，程序員編寫如fetch(https://example.com/news)的代碼，并期望軟件庫能夠處理“example.com”到IP地址的轉換。

在后臺，軟件庫負責發現并連接到外部遞歸DNS解析器，使用DNS協議(見下圖)解析應用程序請求的名稱。外部DNS解析器的選擇以及是否提供任何隱私性和安全性都不在應用程序的控制范圍內。它取決于所使用的軟件庫，以及運行該軟件的設備的操作系統所提供的策略。

外部DNS解析器

操作系統通常使用動態主機配置協議(DHCP)從本地網絡學習解析器地址。在家庭和移動網絡中，它通常使用來自互聯網服務提供商（ISP）的解析器。在公司網絡中，所選的解析器通常由網絡管理員控制。如有所需，可控制自己設備的用戶可以使用特定地址來覆蓋解析器，例如Google的8.8.8.8或Cloudflare的1.1.1.1之類的公共解析器的地址，但大多數用戶在連接咖啡店或機場的公共WiFi熱點時，可能不會費心去更換它。

外部解析器的選擇直接影響最終用戶的體驗。大多數用戶不會更改其解析器設置，并且很可能最終會使用其網絡提供商提供的DNS解析器。最明顯的可觀察屬性是名稱解析的速度和準確性。改善隱私性或安全性的功能可能不會立即見效，但將有助于防止其他人分析或干擾您的瀏覽活動。這在公共WiFi網絡上尤其重要，在公共WiFi網絡上，任何物理上接近的人都可以捕獲和解密無線網絡流量。

未加密的DNS

自從1987年DNS誕生以來，它就一直處于未加密狀態。您的設備與解析器之間的每個人都可以監聽甚至修改您的DNS查詢和響應。這包括您本地WiFi網絡中的任何人，您的互聯網服務提供商（ISP）和傳輸提供商。這可能會披露您訪問的域名從而威脅您的隱私。

他們能看到什么？那么，來看一下從連接到家庭網絡的筆記本上截取的網絡數據包吧：

我們可以觀察到以下幾點：

UDP源端口是53，這是未加密DNS的標準端口號。因此，UDP有效負載很可能是一個DNS響應。

這表明源IP地址192.168.2.254是DNS解析器，而目標IP 192.168.2.14是DNS客戶端。

UDP有效負載確實可以解析為DNS響應，并顯示用戶正試圖訪問twitter.com。

如果將來有連接到104.244.42.129或104.244.42.1的連接，那么很可能是指向“twitter.com”的流量。

如果此IP上有進一步加密的HTTPS流量，接下來會有更多DNS查詢，這可能表明web瀏覽器從該頁面加載了額外的資源。這可能會泄露用戶訪問twitter.com時正在查看的頁面。

由于DNS消息不受保護，因此可能會發生其他攻擊：

查詢可以定向到執行DNS劫持的解析器。例如，在英國，Virgin Media和BT對不存在的域返回假響應，從而將用戶重定向到搜索頁面。這種重定向是可能的，因為計算機/電話盲目地信任由ISP提供的網關路由器使用DHCP通告的DNS解析器。

防火墻可以很容易地攔截、阻止或修改任何基于端口號的未加密DNS流量。值得注意的是，明文檢查并不是訪問可見性目標的靈丹妙藥，因為DNS解析器是可以被繞過的。

加密DNS

對DNS進行加密會使網絡窺探者更難以查看您的DNS信息，或在傳輸過程中破壞它們。就像網絡從未加密的HTTP遷移到加密的HTTPS一樣，現在也有對DNS本身加密的DNS協議的升級。加密網絡使私人和安全的通信與商業得以蓬勃發展。加密DNS將進一步增強用戶隱私性。

存在兩種標準化的機制來保護您和解析器之間的DNS傳輸，即DNS over TLS(2016)和DNS Queries over HTTPS(2018)。兩者都基于傳輸層安全性（TLS），TLS也用于保護您與使用HTTPS的網站之間的通信。在TLS中，服務器（無論是web服務器還是DNS解析器）使用證書向客戶端（您的設備）進行身份驗證。

通過DNS over TLS（DoT），原始的DNS消息被直接嵌入到安全的TLS通道中。從外面看，他人既無法了解正在查詢的名稱，也無法對其進行修改。預期中的客戶端應用程序將能夠解密TLS，如下所示：

在對未加密DNS包的跟蹤中，很明顯，客戶端可以直接發快遞一個DNS請求，然后解析器給出一個DNS響應。然而，在加密的DoT情況下，在發快遞加密DNS消息之前客戶端與服務器會交換一些TLS握手消息：

客戶端發快遞一個Client Hello，通告其支持TLS功能。

服務器以服務器Hello響應，并同意將用于保護連接的TLS參數。證書消息包含服務器的身份，而證書驗證消息將包含數字簽名，客戶端可以使用服務器證書對其進行驗證。客戶端通常會根據其本地受信任的證書頒發機構列表來檢查此證書，但是DoT規范提到了其他信任機制，例如公鑰固定。

客戶端和服務器都完成TLS握手后，它們終于可以開始交換加密的消息。

雖然上面的圖片僅包含一個DNS查詢和響應，但在實踐中，安全TLS連接將保持開放，并將被重新用于以后的DNS查詢。

此前已實現通過新端口上非常快的TLS來保護未加密協議：

網絡流量：HTTP(tcp/80)gt;HTTPS(tcp/443)

發快遞電子郵件：SMTP(tcp/25)gt;SMTPS(tcp/465)

接收電子郵件：IMAP(tcp/143)gt;IMAPS(tcp/993)

現在：DNS(tcp/53 or udp/53)gt;DoT(tcp/853)

引入新端口的一個問題是現有的防火墻可能會阻止它。因為它們采用了必須明確啟用新服務的白名單方法，或者因為采用了網絡管理員明確禁止服務的阻止列表方法。如果安全選項（DoT）比不安全選項的可用性更低，那么用戶和應用程序可能會試圖退回到未加密的DNS。這隨后可能允許攻擊者強制用戶使用不安全的版本。

這種回退攻擊不是僅存于理論上的。SSL剝離此前曾被用于將HTTPS網站降級為HTTP，從而允許攻擊者竊取密碼或劫持賬戶。

另一種方法，NS Queries over HTTPS（DoH），旨在支持兩個主要用例：

防止路徑上的設備干擾DNS的上述問題。這包括上面的端口阻塞問題。

允許web應用程序通過現有的瀏覽器API訪問DNS。

DoH本質上是HTTPS，與web使用的加密標準相同，并且重用相同的端口號（tcp/443）。Web瀏覽器已經不支持不安全的HTTP，而支持HTTPS。這使得HTTPS成為安全傳輸DNS消息的最佳選擇。您可以在這里找到此類DoH的請求示例。

DoH：通過安全的HTTPS流傳輸DNS查詢和響應

一些用戶擔心HTTPS的使用可能會削弱隱私性，因為cookie可能會被用于跟蹤目的。DoH協議設計者考慮了各種隱私方面的問題，并明確建議不要使用HTTP cookie以防止跟蹤，這一建議已得到廣泛遵循。TLS會話恢復可提高TLS 1.2握手性能，但可以被潛在地用于關聯TLS連接。幸運的是，使用TLS 1.3可以通過默認情況下減少往返次數來消除TLS會話恢復的需要，從而有效地解決了與之相關的隱私問題。

使用HTTPS意味著HTTP協議的改進也可以使DoH受益。例如，基于QUIC的正處于開發之中的HTTP/3協議可以提供額外的性能改進，以解決由于缺少前端阻塞而導致的數據包丟失。這意味著當一個數據包丟失時，我們可以通過安全通道同時發快遞多個DNS查詢，而不會互相阻塞。

還有一個基于DNS over QUIC（DNS/QUIC）的草案，類似DoT，但是由于使用了QUIC，因此沒有前端阻塞問題。然而，HTTP/3和DNS/QUIC都需要一個UDP端口才能訪問。理論上，兩者都可以分別通過HTTP/2和DoT退回到DoH。

部署DoT和DoH

由于DoT和DoH都是相對較新的技術，它們還沒有得到普遍應用。在服務器端，主要的公共解析器包括Cloudflare的1.1.1.1和谷歌DNS都支持它。然而，許多ISP解決方案仍然缺乏對它的支持。您可以在DNS服務器源上找到支持DoH的一小部分公共解析器，還可以在DNS隱私公共解析器上找到另一種支持DoT和DoH的公共解析器。

有兩種方法可在最終用戶設備上啟用DoT或DoH：

添加對應用程序的支持，繞過來自操作系統的解析器服務。

添加對操作系統的支持，透明地為應用程序提供支持。

在客戶端，DoT或DoH通常有三種配置模式：

關閉：DNS將不會被加密。

機會模式：嘗試為DNS使用安全傳輸，但如果前者不可用，則退回到未加密的DNS。這種模式容易受到降級攻擊，攻擊者可以迫使設備使用未加密的DNS。機會模式的目的是在沒有活躍的攻擊者時提供隱私性。

嚴格模式：嘗試通過安全傳輸使用DNS。如果不可用，則出現嚴重故障并向用戶顯示錯誤。

通過安全傳輸進行DNS的系統范圍配置的當前狀態：

Android 9：通過其“私有DNS”功能支持DoT。模式：

默認情況下使用機會模式（“自動”）。將使用網絡設置（通常為DHCP）中的解析器。

可以通過設置明確的主機名來配置嚴格模式。不允許使用IP地址，使用默認解析器解析主機名，該主機名還用于驗證證書。（相關源代碼）

iOS和Android用戶還可以安裝1.1.1.1應用程序從而在嚴格模式下啟用DoH或DoT支持。在內部，它使用VPN編程接口來啟用對未加密DNS流量的攔截，然后再通過安全通道轉發。

通過systemd 239解析的linux：通過DNSOverTLS選項啟用DoT。

默認為關閉。

可以配置機會模式，但不執行證書驗證。

從systemd 243開始提供嚴格模式。接受由受信任的證書頒發機構簽署的任何證書。但是，GnuTLS后端沒有主機名驗證，而OpenSSL后端需要一個IP地址。

在任何情況下，都不會發快遞服務器名稱指示（SNI）。證書名稱沒有經過驗證，這使得中間人變得微不足道。

linux、macOS和Windows可以在嚴格模式下使用DoH客戶端。cloudflared proxydns命令默認情況下使用Cloudflare DNS解析器，但用戶可以通過proxydnsupstream選項覆蓋它。

Web瀏覽器支持DoH而非DoT：

Firefox 62支持DoH，并提供了幾種可信遞歸解析器（TRR）設置。默認情況下，DoH處于禁用狀態，但是Mozilla正在進行一項實驗，為美國的一些用戶啟用DoH。這個實驗目前使用的是Cloudflare的1.1.1.1解析器，因為我們是目前唯一滿足Mozilla所要求的嚴格解析器策略的提供商。由于許多DNS解析器仍然不支持加密的DNS傳輸，Mozilla的方法將確保使用DoH保護更多用戶。

當通過實驗或網絡設置中的“通過HTTPS啟用DNS”選項啟用時，Firefox將使用機會模式（network.trr.mode=2 at about:config）。

可以使用network.trr.mode=3啟用嚴格模式，但是需要指定一個明確的解析器IP（例如，network.trr.bootstrapAddress=1.1.1.1）。

盡管Firefox會忽略系統中的默認解析器，但可以使用其他解析器進行配置。此外，使用不支持DoH解析器的企業部署可以選擇禁用DoH。

如果系統解析器地址與硬編碼的DoH提供者之一（源代碼更改）匹配，Chrome 78就會啟用機會DoH。除Linux和iOS之外，所有平臺均啟用了此實驗，并且默認情況下不包括企業部署。

Opera 65添加了一個選項，來通過Cloudflare的1.1.1.1解析器啟用DoH。默認情況下，此功能是關閉的。啟用后，它似乎會使用機會模式：如果1.1.1.1:443（無SNI）可訪問，它將被使用。否則，它會退回到默認的解析器（未加密）。

curl項目中的DNS over HTTPS頁面擁有一個DoH提供程序和其他實現的完整列表。

除了加密設備和外部DNS解析器之間的整個網絡路徑之外，還可以采取一種折衷的方法：在設備和本地網絡的網關之間使用未加密的DNS，但是對網關路由器與外部DNS解析器之間的所有DNS通信進行加密。假設有一個安全的有線或無線網絡，這將保護本地網絡中的所有設備不受ISP監視或互聯網上其他對手的攻擊。由于公共WiFi熱點被認為是不安全的，這種方法在開放WiFi網絡上也不安全。即使它有WPA2PSK的密碼保護，其他人仍然能夠窺探和修改未加密的DNS。

其他安全注意事項

前面幾節描述了安全DNS傳輸、DoH和DoT。這些只能確保您的客戶端從DNS解析器收到未經篡改的應答。但是，它不能保護客戶端不受解析器返回錯誤應答的影響（通過DNS劫持或DNS緩存中毒攻擊）。“真實”答案由權威名稱服務器報告的域或區域的所有者決定。DNSSEC允許客戶端驗證返回的DNS答案的完整性，并捕獲客戶端與權威名稱服務器之間路徑上的任何未經授權的篡改。

但是，錯誤轉發DNS消息的中間盒阻礙了DNSSEC的部署，而且即使信息可用，應用程序使用的存根解析器也可能無法驗證結果。2016年的一份報告發現，只有26%的用戶使用DNSSEC驗證解析器。

DoH和DoT保護客戶端和公共解析器之間的傳輸。公共解析器可能必須與其他權威名稱服務器聯系才能解析名稱。傳統上，任何解析器和權威名稱服務器之間的路徑都使用未加密的DNS。為了保護這些DNS消息，我們對Facebook進行了實驗，在1.1.1.1和Facebook的權威名稱服務器之間使用DoT。雖然使用TLS設置安全通道會增加延遲，但它可以分攤到許多查詢中。

傳輸加密可確保解析器結果和元數據受到保護。例如，DNS查詢中包含的EDNS客戶端子網（ECS）信息可以顯示啟動DNS查詢的原始客戶端地址。沿路徑隱藏這些信息可以提高隱私性。它還可以防止由于轉發DNS中的問題而導致損壞的中間盒破壞DNSSEC。

DNS加密的操作問題

DNS加密可能會給依賴于監視或修改DNS流量的個人或組織帶來挑戰。依賴被動監視的安全設備監視著計算機或網絡邊緣上的所有傳入和傳出網絡流量。例如，基于未加密的DNS查詢，他們可能識別出被惡意軟件感染的機器。如果對DNS查詢進行了加密，那么被動監視解決方案將無法監視域名。

某些團體期望DNS解析器出于以下目的而應用內容過濾：

阻止用于分發惡意軟件的域。

屏蔽廣告。

執行家長控制過濾，阻止與成人內容相關的域。

根據當地法規禁止訪問提供非法內容的域。

提供一個拆分域DNS，根據源網絡提供不同的回應。

阻止通過DNS解析器訪問域的一個優點是它可以被集中完成，而不需要在每個應用程序中重新實現它。不幸的是，它也相當粗糙。假設一個網站在example.com/videos/forkids/和example.com/videos/foradults/為多個用戶托管內容。DNS解析器將只能看到“example.com”，并可以選擇是否阻止它。在這種情況下，特定于應用程序的控件（如瀏覽器擴展）將更有效，因為它們可以實際查看url并有選擇地阻止訪問內容。

DNS監控并不全面。惡意軟件可能會跳過DNS和硬編碼IP地址，或使用其他方法來查詢IP地址。但是，并非所有惡意軟件都這么復雜，因此DNS監控仍可以充當深度防御工具。

所有這些非被動監視或DNS阻塞用例都需要DNS解析器的支持。依賴于當前解析器的DoH/DoT機會式升級的部署將保持未加密DNS上通常提供的相同特性集。不幸的是，正如前面提到的，這很容易被降級。為了解決這個問題，系統管理員可以將端點指向嚴格模式下的DoH/DoT解析器。理想情況下，這可以通過安全的設備管理解決方案（MDM，Windows上的組策略等）來實現。

結論

互聯網的基石之一是使用DNS將名稱映射到地址。DNS傳統上使用不安全，未加密的傳輸。過去，這已被ISP濫用于廣告注入，但也導致了隱私泄漏。咖啡店里的安管閑事的顧客可以使用未加密的DNS來跟蹤您的活動。所有這些問題都可以通過使用DNS over TLS（DoT）或DNS over HTTPS（DoH）來解決。這些保護用戶的技術相對較新，而且正在被越來越多的人采用。

從技術角度來看，DoH與HTTPS非常相似，并且遵循行業普遍趨勢來棄用非安全選項。與DoH相比，DoT是一種更簡單的傳輸模式，因為它除去了HTTP層，但是這也使得它更容易被阻塞，不管是故意的還是意外的。

選擇安全的DNS解析器是啟用安全傳輸的第二要務。一些供應商會使用本地配置的DNS解析器，但會嘗試將未加密的傳輸升級為更安全的傳輸（DoT或DoH）。不幸的是，DNS解析器通常默認由ISP提供，而ISP可能不支持安全傳輸。

Mozilla采取了不同的方法。它們允許用戶明確地選擇一個解析器，而不是依賴于甚至可能不支持DoH的本地解析器。Mozilla推薦的解析器必須滿足高標準，以保護用戶隱私。為了確保基于DNS的家長控制功能繼續發揮作用，并支持分割域用例，Mozilla添加了一種機制，該機制允許私有解析器禁用DoH。

DoT和DoH傳輸協議已經為我們轉移到更安全的互聯網做好了準備。從前面的數據包跟蹤中可以看出，這些協議類似于現有的保護應用程序通信流的機制。當這個安全和隱私漏洞被關閉后，將來還會有更多的問題需要解決。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。