Cloudflare OdoH，改善DNS安全和隱私

去年，Cloudflare發(fā)布了一項用于改善DNS安全和隱私的新的DNS標(biāo)準(zhǔn)ODoH。標(biāo)準(zhǔn)由Cloudflare，Apple和Fastly的工程師共同撰寫，標(biāo)準(zhǔn)通過將IP地址與查詢分隔開，防止相關(guān)信息的泄露。Cloudflare也在Github開源了協(xié)議實現(xiàn)和客戶端的源代碼，可以讓大家自己試運行和驗證OdoH服務(wù)。

概述

域名系統(tǒng)（DNS）是人類可以使用的Internet的基礎(chǔ)。它將可用的域名（例如cloudflare.com）映射到IP地址以及連接到該域所需的其他信息。在接入網(wǎng)絡(luò)后設(shè)備與DNS解析器之間的網(wǎng)絡(luò)路徑上的任何人都可以看到包含所需主機名（或網(wǎng)站）的查詢以及標(biāo)識設(shè)備的IP地址。

為了保護DNS免受旁觀者和第三方的侵害，IETF推出了基于HTTPS上的DNS（DoH）和TLS協(xié)議DNS（DoT）對DNS傳輸進行標(biāo)準(zhǔn)化加密。兩種協(xié)議都可以防止DNS查詢在中間過程中被攔截，重定向或篡改。目前很多客戶端系統(tǒng)，包括新版本的Firefox，iOS等中都已經(jīng)實現(xiàn)了對DoT和DoH的支持，但是還未得到全網(wǎng)范圍的廣泛部署和支持。

基于但是使用對DoT和DoH后目，存在著兩個明顯的問題：一個是集中化的DNS會引入單點故障。

另一個問題是解析器仍然將所有查詢鏈接到客戶端IP地址。

為了解決這個問題，Cloudflare和合作伙伴推出了一個改進的協(xié)議，該協(xié)議可以實現(xiàn)以下功能：HTTPS Oblivious DNS，或簡稱ODoH。這些合作伙伴包括PCCW，SURF和Equinix。

OdoH工作原理

ODoH是IETF正在開發(fā)的新協(xié)議。ODoH通過添加一層公共密鑰加密機制以及客戶端和DoH服務(wù)器之間的網(wǎng)絡(luò)代理（例如1.1.1.1）來工作。通過兩個添加元素的組合確保只有查詢用戶才能同時訪問DNS消息和及其IP地址。

OdoH實現(xiàn)中有三個參與者。目標(biāo)服務(wù)器通過代理解密由客戶端加密的查詢。同樣，目標(biāo)對響應(yīng)進行加密并將其返回給代理。目標(biāo)可以是解析器，也可以不是。代理服務(wù)器只負責(zé)在客戶端和目標(biāo)之間消息轉(zhuǎn)發(fā)。客戶端行為與在DNS和DoH中的行為相同，但是通過對目標(biāo)的查詢進行加密并解密目標(biāo)的響應(yīng)來進行區(qū)別。選擇這樣做的任何客戶端都可以指定代理和選擇的目標(biāo)。

增加的添加的加密和機制和代理提供了以下保證：

目標(biāo)僅可以查看查詢和代理的IP地址。

代理無法查看DNS消息，無法識別，讀取或修改客戶端發(fā)送的查詢或目標(biāo)返回的答案。

只有預(yù)期的目標(biāo)才能讀取查詢的內(nèi)容并發(fā)出響應(yīng)。

這三個保證在保持DNS查詢的安全性和完整性的同時改善了客戶端的隱私。但是這些保證中的每一項都依賴于一個基本屬性：代理服務(wù)器和目標(biāo)服務(wù)器不相互影響。只要兩者沒有串通，攻擊者只有全部拿下代理服務(wù)器和目標(biāo)服務(wù)器才能成功。

在該體系架構(gòu)中目標(biāo)與執(zhí)行DNS解析的上游遞歸解析器是分開的。同樣，重要的是，客戶可以完全控制代理和目標(biāo)選擇。無需任何類似TRR的程序，客戶端除了安全性之外，還可以保留其查詢的隱私權(quán)。由于目標(biāo)只和代理聯(lián)系，目標(biāo)服務(wù)器和任何上游解析程序都不能獲得客戶端IP地址。這樣客戶可以更好地控制其查詢及其使用方式。例如，客戶可以出于任何原因隨時選擇和更改代理和目標(biāo)服務(wù)器。

ODoH消息流

在ODoH中，"O"表示Oblivious（遺忘），該屬性來自DNS消息本身的加密級別。加密是客戶端和目標(biāo)之間的"端到端"，并且獨立于TLS/HTTPS提供的連接級加密。有人可能會問為什么在存在代理的情況下還需要額外的加密。因為需要兩個單獨的TLS連接來支持代理功能。具體來說，代理會終止來自客戶端的TLS連接，并啟動到目標(biāo)的另一個TLS連接。在這兩個連接之間，DNS消息上下文將以純文本形式顯示。為此，ODoH還會在客戶端和目標(biāo)之間加密消息，這樣代理無法訪問消息內(nèi)容。

整個過程從客戶端使用HPKE加密對目標(biāo)的查詢開始。客戶端通過DNS獲取目標(biāo)的公鑰，并將其捆綁到HTTPS資源記錄中并由DNSSEC保護。當(dāng)此密鑰的TTL過期時，客戶端會根據(jù)需要請求密鑰的新副本（就像A/AAAA記錄的TTL過期時一樣）。使用目標(biāo)的DNSSEC驗證的公共密鑰可確保只有目標(biāo)目標(biāo)可以解密查詢并加密響應(yīng)。

客戶端通過HTTPS連接將這些加密的查詢傳輸?shù)酱?。收到后，代理將查詢轉(zhuǎn)發(fā)到指定目標(biāo)。然后目標(biāo)解密該查詢，通過將查詢發(fā)送到遞歸解析器（例如1.1.1.1）來生成響應(yīng)，然后將響應(yīng)加密到客戶端。來自客戶端的加密查詢包含封裝的密鑰材料，目標(biāo)可從中獲得響應(yīng)加密對稱密鑰。

然后將該響應(yīng)發(fā)送回代理，然后轉(zhuǎn)發(fā)給客戶端。盡管這些DNS消息是通過兩個單獨的HTTPS連接（客戶端代理和代理目標(biāo)）傳輸?shù)模型ㄐ哦际墙?jīng)過端到端加密的，因此所有通信都經(jīng)過身份驗證和保密。否則在代理中顯示為純文本的消息實際上是加密的亂碼。

性能測試

Tranco百萬數(shù)據(jù)集中隨機選擇了10,000個域，統(tǒng)計了使用不同公鑰對A記錄的加密及其解密。結(jié)果中，99%的代理的DoH查詢/響應(yīng)與其ODoH對應(yīng)對象之間的額外開銷始終小于1毫秒。

但是，ODoH請求：響應(yīng)管道不僅限于加密。查看度量的一種非常有用的方法是查看累積分布圖。下圖顯示了通過Tor網(wǎng)絡(luò)傳輸時DoH，ODoH和DoH中查詢/響應(yīng)時間的累積分布。從左側(cè)開始的水平虛線是50%標(biāo)記。沿著該水平線，對于任何繪制的曲線，虛線下方的曲線部分為數(shù)據(jù)點的50%。x軸是時間的度量。左邊的線比右邊的線變化的快。最后一個重要的細節(jié)是x軸以對數(shù)刻度繪制，標(biāo)記的標(biāo)記之間的距離（10x）在累積分布中相等，但是'x'是指數(shù)，代表數(shù)量級。因此，盡管前兩個標(biāo)記之間的時間差為9毫秒，但第3個標(biāo)記和第4個標(biāo)記之間的時差為900毫秒。

在圖表中，中間曲線代表ODoH測量值。還測量了隱私保護方案的性能，例如，通過Tor網(wǎng)絡(luò)傳輸?shù)腄oH查詢，如圖表中的右曲線所示。與其他面向隱私的DNS變體相比，ODoH將查詢時間縮短了一半甚至更好。

在不到228毫秒的時間內(nèi)，解決ODoH查詢的時間占50%?，F(xiàn)在，將中間線與代表"直線"（或正常）DoH的左側(cè)線進行比較，而無需進行任何修改。左邊的繪圖線表示，在50%的時間內(nèi)，DoH查詢在不到146ms的時間內(nèi)得到解決。從低于50%的標(biāo)記看，差值的時間永遠不會大于100ms。

這些曲線還隱藏了很多信息，因此深入研究測量值很重要。下表具有三個不同的累積分布曲線，這些曲線描述了我們通過代理和目標(biāo)的延遲來選擇ODoH的性能。這也是測量曲線中，其中一些是違反直覺的。例如，0.5之上看，這些曲線表明，無論選擇代理和目標(biāo)，ODOH查詢/響應(yīng)時間的50%實際上是無法區(qū)分的。在0.5以下，并將兩條實線與代表整體平均值的虛線相比較。該區(qū)域表明選擇最低延遲代理和目標(biāo)對平均值的改進很小。最重要的是，其表明選擇最低延遲代理會導(dǎo)致性能變差。

OdoH驗證

目前Cloudflare已經(jīng)開源了odoh-rs（Rust）和odoh-go（Golang）中開源了可互

操作的OdoH服務(wù)器實現(xiàn)，并將目標(biāo)集成到了Cloudflare DNS解析器中。

還開源了odoh-client-rs（Rust）和odoh-client-go（Golang）客戶演示ODoH查詢。

1.1.1.1公共DNS中已經(jīng)支持ODoH查詢。可以通過直接查詢由OdoH加密的HPKE配置：