Oblivious DNS：堵住互聯網最大的隱私漏洞

作者：Annie Edmundson、PaulSchmitt 和 Nick Feamster

近日傳出新聞稱Cloudflare在部署自己的DNS遞歸解析器，這再次在用戶當中燃起了希望：獲得更好的隱私，因為他們可以將經過加密的DNS流量發送到Cloudflare，而不是發送到ISP（互聯網服務提供商）。我們在本文中解釋了為什麼這種方法只是將你的私密數據從ISP發送到另一個第三方。你信任這第三方可能甚過信任ISP，但還是仍得信任它。我們在本文中提出了另一種替代設計：Oblivious DNS（隱蔽式DNS，https://odns.cs.princeton.edu/），那樣你根本沒必要作出這樣的選擇。

域名系統（DNS）

你的客戶端將google.com之類的域名轉換成IP地址時，它依賴DNS遞歸解析器來執行此操作。該解析服務系統的運營商可以同時看到你的IP地址和查詢的域名。

你或你的任何設備訪問互聯網時，第一步通常是在域名系統（DNS）中查找域名（比如「google.com」或「princeton.edu」）以確定聯繫哪一個互聯網地址。DNS本質上是互聯網域名的電話簿。

你運行的客戶端（包括瀏覽器、智能手機和家裡的任何物聯網設備）把針對每個域名的DNS查詢發送到所謂的「遞歸式DNS解析器」。在典型的家庭網路上，默認的遞歸式DNS解析器可能由互聯網服務提供商（ISP，比如康卡斯特和Verizon）來運行。谷歌和Quad9等其他公司也運行任何人都可以使用的「開放式」遞歸解析器，其想法是：這些替代的遞歸解析器為用戶提供了除ISP之外解析查詢的另一種方案。過去，這種替代方法在規避審查方面很有用。

DNS：互聯網最大的隱私漏洞

DNS查詢通常以明文格式發送，它們會泄露互聯網用戶可能希望保密的重要信息，包括用戶訪問的網站、發出初始查詢的那個設備的IP地址或子網，甚至包括用戶在家庭網路中擁有的設備的類型。比如說，我們之前的研究表明，DNS查詢可用於對來自Tor網路的流量進行去匿名化處理。

由於查詢和響應未經加密，任何第三方只要能查看客戶端與遞歸解析器（即權威伺服器）之間的通信內容，就能查看DNS解析過程中的各個步驟。

遞歸式DNS解析器的運營商（通常是你的ISP）可以看到單個IP地址（這可能對應於ISP用戶，或可能是單個最終用戶）以及伴隨查詢的完全符合標準的域名，但是用戶解析遞歸式DNS查詢依賴的任何第三方（比如谷歌）通常也能看到。即便在權威解析器這種情況下，DNS的擴展（比如EDNS0 Client Subnet）可能也會將用戶的IP地址或子網的信息泄露給DNS層次體系中更高層的DNS權威伺服器。

現有方法

現有的擬議標準可保護用戶隱私的某些方面，包括DNSQuery Name Minimization（DNS查詢名稱最小化）和DNSover TLS。

然而，這些方法無法阻止遞歸式DNS伺服器的運營商了解哪些IP地址針對特定的域名發出查詢――這是DNS隱私方面的根本問題：

第三方最近一直在構建聲稱尊重用戶隱私的新DNS解析器：Quad9（9.9.9.9）和Cloudflare的1.1.1.1就運行這種開放式DNS遞歸解析器，聲稱可以清除有關用戶查詢的信息。Cloudflare另外支持DNS over HTTPS：就像DNSover TLS那樣，它確保從瀏覽器到遞歸式DNS解析器，DNS查詢全程加密。

然而在所有這些情況下，用戶無法保證運營商了解的信息有沒有保留以用於運營或其他目的。當然，一旦這類信息保留起來，用戶隱私可能容易受到其他威脅，包括執法部門要求調閱數據。簡而言之，這些服務只是將信任點從ISP轉移到另外某個第三方，但你仍然得信任該第三方。

Oblivious DNS

雖然你可能有充分的理由相信提供商聲稱清除有關DNS查詢的所有信息，但我們認為用戶甚至本來就沒必要作出這樣的選擇。

Oblivious DNS（ODNS）的目的是，確保沒有任何一方能觀察到DNS查詢和發出查詢的IP地址（或子網）。ODNS作為傳統DNS上的某種覆蓋層來運行，它不需要改動已經部署的任何DNS基礎設施。

Oblivious DNS（ODNS）的工作方式類似傳統DNS，但有兩個新的部分：1）每個客戶端運行本地ODNS存根解析器，2）我們添加了一個ODNS權威區域，該區域還作為遞歸式DNS解析器來運行。該圖表明了基本方法。

Oblivious DNS（ODNS）在客戶端添加了一個自定義存根解析器（stub resolver），有意模糊原始查詢，而ODNS權威伺服器可以解密原始查詢。但是ODNS權威伺服器根本看不到發出查詢的客戶端的IP地址。

客戶端應用程序啟動DNS查詢時，客戶端的存根解析器有意模糊客戶端請求的那個域（通過對稱加密），導致遞歸式解析器不知道請求的域。ODNS權威域名伺服器將客戶端的身份與對應的DNS請求分離開來，那樣域名伺服器就無法知道誰在請求特定的域。ODNS協議採取的步驟如下：

其他域名伺服器可以看到進入的DNS請求，但這些伺服器只能看到ODNS遞歸解析器的IP地址，ODNS遞歸解析器實際上為原始客戶端代理處理DNS請求。這些步驟對應於下圖。

原型實施和初步評估

我們用Go語言實施了一個原型，以評估部署ODNS的可行性，還評估了使用ODNS相比使用傳統DNS的性能開銷。我們實施了一個ODNS存根解析器，並且實施了一台還能發出遞歸查詢的權威域名伺服器。

ODNS使未緩存的DNS查詢的解析時間增加了10-20毫秒。

我們先將運行ODNS查詢的性能開銷與傳統DNS作了一番比較。我們使用ODNS和傳統DNS向AlexaTop 10000個域發出了DNS查詢。下面的CDF顯示，ODNS使每個查詢增加了大約10-20毫秒。當然，實際上DNS廣泛利用了緩存，這個實驗表明的是最糟糕情況。我們預計實際上開銷小得多。

同樣，我們評估了整個網頁載入的開銷（載入過程包括獲取頁面，並對頁面中的嵌入式對象和資源進行任何後續的DNS查詢），從而評估ODNS會如何影響典型互聯網用戶的瀏覽體驗。我們使用ODNS獲取了含有大量內容的熱門網頁，比較了執行同樣操作的結果。

載入整個網頁的開銷極小。

在條形圖的每五組中，圖中的左側條使用常規DNS，右側條表示使用ODNS所花的時間。我們發現，ODNS和傳統DNS在頁面載入時間方面並沒有顯著差異，原因是DNS查詢給整個頁面載入過程帶來的開銷極小。與以前一樣，這些實驗是在使用「冷緩存」的情況下運行的，實際上我們預計開銷還要小。

總結和後續步驟

以下資料供各位讀者參考：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！