作者：Annie Edmundson、PaulSchmitt 和 Nick Feamster

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

       域名系統(tǒng)（DNS）

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

       你或你的任何設(shè)備訪問互聯(lián)網(wǎng)時，第一步通常是在域名系統(tǒng)（DNS）中查找域名（比如“google.com”或“princeton.edu”）以確定聯(lián)系哪一個互聯(lián)網(wǎng)地址。DNS本質(zhì)上是互聯(lián)網(wǎng)域名的電話簿。

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

        DNS：互聯(lián)網(wǎng)最大的隱私漏洞

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

       由于查詢和響應(yīng)未經(jīng)加密，任何第三方只要能查看客戶端與遞歸解析器（即權(quán)威服務(wù)器）之間的通信內(nèi)容，就能查看DNS解析過程中的各個步驟。

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

       現(xiàn)有方法

       現(xiàn)有的擬議標(biāo)準(zhǔn)可保護(hù)用戶隱私的某些方面，包括DNSQuery Name Minimization（DNS查詢名稱最小化）和DNSover TLS。

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

• DNS查詢名稱最小化提供了一種機(jī)制，那樣對DNS域名層次體系中不同部分具有權(quán)威性的DNS服務(wù)器無法了解完整的DNS查詢。比如說，對所有*.com具有權(quán)威性的服務(wù)器不一定了解針對maps.google.com的查詢，只了解客戶需要解析google.com的某個子域。然而，這種機(jī)制無法阻止遞歸式DNS解析器了解完整的DNS查詢和發(fā)出查詢的客戶端的IP地址。

• DNS over TLS為加密DNS查詢提供了一種機(jī)制。不過，即便使用DNSover TLS，遞歸解析器仍需要解密初始查詢，那樣它才能為客戶端解析查詢。它仍然無法阻止遞歸式DNS解析器了解查詢和發(fā)送查詢的IP地址。

       第三方最近一直在構(gòu)建聲稱尊重用戶隱私的新DNS解析器：Quad9（9.9.9.9）和Cloudflare的1.1.1.1就運(yùn)行這種開放式DNS遞歸解析器，聲稱可以清除有關(guān)用戶查詢的信息。Cloudflare另外支持DNS over HTTPS：就像DNSover TLS那樣，它確保從瀏覽器到遞歸式DNS解析器，DNS查詢?nèi)碳用堋?/span>

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

       Oblivious DNS

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

       Oblivious DNS（ODNS）的目的是，確保沒有任何一方能觀察到DNS查詢和發(fā)出查詢的IP地址（或子網(wǎng)）。ODNS作為傳統(tǒng)DNS上的某種覆蓋層來運(yùn)行，它不需要改動已經(jīng)部署的任何DNS基礎(chǔ)設(shè)施。

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

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

       客戶端應(yīng)用程序啟動DNS查詢時，客戶端的存根解析器有意模糊客戶端請求的那個域（通過對稱加密），導(dǎo)致遞歸式解析器不知道請求的域。ODNS權(quán)威域名服務(wù)器將客戶端的身份與對應(yīng)的DNS請求分離開來，那樣域名服務(wù)器就無法知道誰在請求特定的域。ODNS協(xié)議采取的步驟如下：

1. 客戶端為www.foo.com生成請求時，存根解析器生成會話密鑰k，對請求的域進(jìn)行加密，并在后面添加TLD域名.odns，因而生成{www.foo.com}k.odns。

2. 客戶端將此請求轉(zhuǎn)發(fā)給遞歸解析器，會話密鑰由DNS查詢的“額外信息”記錄中.odns服務(wù)器的公鑰（{k}PK）來進(jìn)行加密，然后遞歸解析器將請求轉(zhuǎn)發(fā)給.odns的授權(quán)域名服務(wù)器。

3. ODNS查詢的權(quán)威服務(wù)器使用其私鑰對會話密鑰進(jìn)行解密，然后使用會話密鑰對請求的域進(jìn)行解密。

4. 權(quán)威服務(wù)器將遞歸DNS請求轉(zhuǎn)發(fā)給原始域的相應(yīng)域名服務(wù)器，然后該服務(wù)器將結(jié)果返回給ODNS權(quán)威服務(wù)器。

5. ODNS權(quán)威服務(wù)器因而可以將結(jié)果（域和IP地址都經(jīng)過加密）返回給遞歸解析器，遞歸解析器將其轉(zhuǎn)發(fā)給客戶端的存根解析器。反過來，存根解析器可以對域和IP地址進(jìn)行解密。

       其他域名服務(wù)器可以看到進(jìn)入的DNS請求，但這些服務(wù)器只能看到ODNS遞歸解析器的IP地址，ODNS遞歸解析器實際上為原始客戶端代理處理DNS請求。這些步驟對應(yīng)于下圖。

       原型實施和初步評估

       我們用Go語言實施了一個原型，以評估部署ODNS的可行性，還評估了使用ODNS相比使用傳統(tǒng)DNS的性能開銷。我們實施了一個ODNS存根解析器，并且實施了一臺還能發(fā)出遞歸查詢的權(quán)威域名服務(wù)器。

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

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

        同樣，我們評估了整個網(wǎng)頁加載的開銷（加載過程包括獲取頁面，并對頁面中的嵌入式對象和資源進(jìn)行任何后續(xù)的DNS查詢），從而評估ODNS會如何影響典型互聯(lián)網(wǎng)用戶的瀏覽體驗。我們使用ODNS獲取了含有大量內(nèi)容的熱門網(wǎng)頁，比較了執(zhí)行同樣操作的結(jié)果。

       加載整個網(wǎng)頁的開銷極小。

       在條形圖的每五組中，圖中的左側(cè)條使用常規(guī)DNS，右側(cè)條表示使用ODNS所花的時間。我們發(fā)現(xiàn)，ODNS和傳統(tǒng)DNS在頁面加載時間方面并沒有顯著差異，原因是DNS查詢給整個頁面加載過程帶來的開銷極小。與以前一樣，這些實驗是在使用“冷緩存”的情況下運(yùn)行的，實際上我們預(yù)計開銷還要小。

       總結(jié)和后續(xù)步驟

       過去幾年，DNS查詢暴露的隱私風(fēng)險備受關(guān)注（這不無道理）。雖然允許用戶使用替代DNS解析器的現(xiàn)有方法邁出了可喜的一步，但從某種意義上來說，它們只是將信任點從用戶的ISP轉(zhuǎn)移到另一方。我們認(rèn)為，一種更好的最終狀態(tài)是，用戶不必信任任何DNS遞歸解析器的運(yùn)營商。為了實現(xiàn)這個目標(biāo)，我們開發(fā)出了ODNS，幫助客戶身份與相應(yīng)的DNS查詢分離開來，還實施了一個原型。我們正在搞更大規(guī)模的實施、部署和評估工作。想了解ODNS的更多信息，請訪問我們的項目網(wǎng)站（http://odns.cs.princeton.edu/）。我們歡迎任何反饋和意見。我們準(zhǔn)備探究更廣泛部署的機(jī)會，并在積極尋求合作伙伴，幫助我們在運(yùn)營環(huán)境中部署ODNS解決方案。