Cloudflare OdoH，改善DNS安全和隱私

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

概述

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

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

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

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

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

OdoH工作原理

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

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

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

目標僅可以查看查詢和代理的IP地址。

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

只有預期的目標才能讀取查詢的內容并發(fā)出響應。

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

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

ODoH消息流

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

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

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

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

性能測試

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

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

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

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

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

OdoH驗證

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

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

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

1.1.1.1公共DNS中已經支持ODoH查詢?？梢酝ㄟ^直接查詢由OdoH加密的HPKE配置：