日前，Cloudflare發布了一項用於改善DNS安全和隱私的新的DNS標準ODoH。標準由Cloudflare，Apple和Fastly的工程師共同撰寫，標準通過將IP位址與查詢分隔開，防止相關信息的洩露。Cloudflare也在Github開源了協議實現和客戶端的原始碼，可以讓大家自己試運行和驗證OdoH服務。
概述
域名系統（DNS）是人類可以使用的Internet的基礎。它將可用的域名（例如cloudflare.com）映射到IP位址以及連接到該域所需的其他信息。在接入網絡後設備與DNS解析器之間的網絡路徑上的任何人都可以看到包含所需主機名（或網站）的查詢以及標識設備的IP位址。
為了保護DNS免受旁觀者和第三方的侵害，IETF推出了基於HTTPS上的DNS（DoH）和TLS協議DNS（DoT）對DNS傳輸進行標準化加密。兩種協議都可以防止DNS查詢在中間過程中被攔截，重定向或篡改。目前很多客戶端系統，包括新版本的Firefox，iOS等中都已經實現了對DoT和DoH的支持，但是還未得到全網範圍的廣泛部署和支持。
基於但是使用對DoT和DoH後目，存在著兩個明顯的問題：一個是集中化的DNS會引入單點故障。
另一個問題是解析器仍然將所有查詢連結到客戶端IP位址。
為了解決這個問題， Cloudflare和合作夥伴推出了一個改進的協議，該協議可以實現以下功能：HTTPS Oblivious DNS，或簡稱ODoH。這些合作夥伴包括PCCW，SURF和Equinix。
OdoH工作原理
ODoH是IETF正在開發的新協議。ODoH通過添加一層公共密鑰加密機制以及客戶端和DoH伺服器之間的網絡代理（例如1.1.1.1）來工作。通過兩個添加元素的組合確保只有查詢用戶才能同時訪問DNS消息和及其IP位址。
OdoH實現中有三個參與者。目標伺服器通過代理解密由客戶端加密的查詢。同樣，目標對響應進行加密並將其返回給代理。目標可以是解析器，也可以不是。代理伺服器只負責在客戶端和目標之間消息轉發。客戶端行為與在DNS和DoH中的行為相同，但是通過對目標的查詢進行加密並解密目標的響應來進行區別。選擇這樣做的任何客戶端都可以指定代理和選擇的目標。
增加的添加的加密和機制和代理提供了以下保證：
目標僅可以查看查詢和代理的IP位址。
代理無法查看DNS消息，無法識別，讀取或修改客戶端發送的查詢或目標返回的答案。
只有預期的目標才能讀取查詢的內容並發出響應。
這三個保證在保持DNS查詢的安全性和完整性的同時改善了客戶端的隱私。但是這些保證中的每一項都依賴於一個基本屬性：代理伺服器和目標伺服器不相互影響。只要兩者沒有串通，攻擊者只有全部拿下代理伺服器和目標伺服器才能成功。
在該體系架構中目標與執行DNS解析的上遊遞歸解析器是分開的。同樣，重要的是，客戶可以完全控制代理和目標選擇。無需任何類似TRR的程序，客戶端除了安全性之外，還可以保留其查詢的隱私權。由於目標只和代理聯繫，目標伺服器和任何上遊解析程序都不能獲得客戶端IP位址。這樣客戶可以更好地控制其查詢及其使用方式。例如，客戶可以出於任何原因隨時選擇和更改代理和目標伺服器。
ODoH消息流
在ODoH中，"O"表示Oblivious（遺忘），該屬性來自DNS消息本身的加密級別。加密是客戶端和目標之間的"端到端"，並且獨立於TLS/HTTPS提供的連接級加密。有人可能會問為什麼在存在代理的情況下還需要額外的加密。因為需要兩個單獨的TLS連接來支持代理功能。具體來說，代理會終止來自客戶端的TLS連接，並啟動到目標的另一個TLS連接。在這兩個連接之間，DNS消息上下文將以純文本形式顯示。為此，ODoH還會在客戶端和目標之間加密消息，這樣代理無法訪問消息內容。
整個過程從客戶端使用HPKE加密對目標的查詢開始。客戶端通過DNS獲取目標的公鑰，並將其捆綁到HTTPS資源記錄中並由DNSSEC保護。當此密鑰的TTL過期時，客戶端會根據需要請求密鑰的新副本（就像A/AAAA記錄的TTL過期時一樣）。使用目標的DNSSEC驗證的公共密鑰可確保只有目標目標可以解密查詢並加密響應。
客戶端通過HTTPS連接將這些加密的查詢傳輸到代理。收到後，代理將查詢轉發到指定目標。然後目標解密該查詢，通過將查詢發送到遞歸解析器（例如1.1.1.1）來生成響應，然後將響應加密到客戶端。來自客戶端的加密查詢包含封裝的密鑰材料，目標可從中獲得響應加密對稱密鑰。
然後將該響應發送回代理，然後轉發給客戶端。儘管這些DNS消息是通過兩個單獨的HTTPS連接（客戶端代理和代理目標）傳輸的，但所有通信都是經過端到端加密的，因此所有通信都經過身份驗證和保密。否則在代理中顯示為純文本的消息實際上是加密的亂碼。
性能測試
Tranco百萬數據集中隨機選擇了10,000個域，統計了使用不同公鑰對A記錄的加密及其解密。結果中，99%的代理的DoH查詢/響應與其ODoH對應對象之間的額外開銷始終小於1毫秒。
但是，ODoH請求：響應管道不僅限於加密。查看度量的一種非常有用的方法是查看累積分布圖。下圖顯示了通過Tor網絡傳輸時DoH，ODoH和DoH中查詢/響應時間的累積分布。從左側開始的水平虛線是50%標記。沿著該水平線，對於任何繪製的曲線，虛線下方的曲線部分為數據點的50%。x軸是時間的度量。左邊的線比右邊的線變化的快。最後一個重要的細節是x軸以對數刻度繪製，標記的標記之間的距離（10x）在累積分布中相等，但是'x'是指數，代表數量級。因此，儘管前兩個標記之間的時間差為9毫秒，但第3個標記和第4個標記之間的時差為900毫秒。
在圖表中，中間曲線代表ODoH測量值。還測量了隱私保護方案的性能，例如，通過Tor網絡傳輸的DoH查詢，如圖表中的右曲線所示。與其他面向隱私的DNS變體相比，ODoH將查詢時間縮短了一半甚至更好。
在不到228毫秒的時間內，解決ODoH查詢的時間佔50%。現在，將中間線與代表"直線"（或正常）DoH的左側線進行比較，而無需進行任何修改。左邊的繪圖線表示，在50%的時間內，DoH查詢在不到146ms的時間內得到解決。從低於50%的標記看，差值的時間永遠不會大於100ms。
這些曲線還隱藏了很多信息，因此深入研究測量值很重要。下表具有三個不同的累積分布曲線，這些曲線描述了我們通過代理和目標的延遲來選擇ODoH的性能。這也是測量曲線中，其中一些是違反直覺的。例如，0.5之上看，這些曲線表明，無論選擇代理和目標，ODOH查詢/響應時間的50%實際上是無法區分的。在0.5以下，並將兩條實線與代表整體平均值的虛線相比較。該區域表明選擇最低延遲代理和目標對平均值的改進很小。最重要的是，其表明選擇最低延遲代理會導致性能變差。
OdoH驗證
目前Cloudflare已經開源了odoh-rs（Rust）和odoh-go（Golang）中開源了可互
操作的OdoH伺服器實現，並將目標集成到了Cloudflare DNS解析器中。
還開源了odoh-client-rs（ Rust）和odoh-client-go（Golang）客戶演示ODoH查詢。
1.1.1.1公共DNS中已經支持ODoH查詢。可以通過直接查詢由OdoH加密的HPKE配置：