使用 ODoH 與 Numa 破解 DNS 私隱悖論

對於 Pi-hole、AdGuard Home 或標準轉發解析器（forwarding resolvers）的使用者而言，DNS 私隱往往是一種權衡。你要麼信任一個能同時看到你的 IP 地址和所有造訪網站的單一營運商，要要麼切換到像 Unbound 這樣的遞迴解析器，這會將你的 IP 地址暴露給鏈路中的每個權威名稱伺服器。雖然 DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 加密了傳輸層，但它們並未改變「誰能得知你的瀏覽習慣」這一根本現實。

Apple 的 iCloud Private Relay 嘗試透過將路徑拆分為一個入口代理（ingress proxy，能看到 IP 但看不到請求）和一個出口代理（egress proxy，能看到請求但看不到 IP）來解決此問題。然而，這個解決方案被鎖定在訂閱服務、特定硬體以及精選合作夥伴之後。對於自託管社群而言，一個無需帳戶要求或平台鎖定的真正匿名 DNS 選項一直難以實現——直到 ODoH 的採用。

理解 ODoH：Oblivious DNS over HTTPS

ODoH (RFC 9230) 是一種 IETF 協定，旨在透過在用戶端與目標解析器之間引入中繼站（relay）來實現 DNS 查詢的匿名化。其過程透過一系列加密握手完成：

用戶端： 使用目標解析器的 HPKE (Hybrid Public Key Encryption) 公鑰對 DNS 查詢進行加密。它還會包含一個用於回應的對稱金鑰。
Numa 中繼站： 接收請求。它能看到用戶端的 IP 地址，但只能看到密文。它無法看到所詢問的問題。
目標（例如 Cloudflare）： 使用其私鑰解密問題。它能看到請求，但只能看到中繼站的 IP 地址，而非原始用戶端。
回傳路徑： 目標使用用戶端提供的對稱金鑰對答案進行加密，並透過中繼站傳回，而中繼站對內容保持盲目。

透過使用 HPKE (RFC 9180)，ODoH 確保了鏈路中的任何單一實體都無法同時擁有使用者的身份（IP）與意圖（DNS 查詢）。

實作中繼站：安全性與架構

部署 ODoH 中繼站並不只是簡單的封包轉發；它需要特定的防護措施來防止基礎設施被濫用。Numa 專案實作了以下幾個關鍵機制：

SSRF 硬化

由於中繼站會對請求 URL 中指定的目標建立出站連接，因此它是伺服器端請求偽造 (SSRF) 的主要目標。為了減輕這種風險，Numa 採用了嚴格的正規表示式主機名驗證器，強制執行 RFC 1035 ASCII 標籤，並明確禁止 IP 字面量、非 443 埠口以及國際化域名 (IDNs)。

同一營運商檢查

ODoH 的核心私隱保障依賴於中繼站與目標由不同的組織營運。如果單一實體控制了兩者，他們就能將中繼站的 IP 地址與目標的查詢進行關聯，使匿名性變成「表演」。Numa 實作了 eTLD+1 檢查，預設拒絕中繼站與目標共享相同組織域名的配置。

ODoH 的限制

雖然 ODoH 顯著提升了私隱，但它並非萬靈丹。有幾個營運與技術限制需要考慮：

目標信任： ODoH 只是轉移了信任，而非消除它。目標解析器仍然能看到問題；保護措施僅在於該問題不會被歸因於特定使用者。
遞迴洩漏： 如果目標以遞迴模式運作，隨後的跳轉到根、TLD 和權威伺服器通常是明文 UDP/TCP。ODoH 僅保護用戶端到目標這一段路徑。
流量分析： 小型中繼站容易受到時間攻擊。如果中繼站上只有一名使用者在活動，目標可以透過觀察請求進入的時間點來推斷使用者的身份。私隱度會隨著使用者數量與填充流量 (padding traffic) 的規模而增加。
中央化金鑰分發： 目前，用戶端透過 HTTPS 從目標的 well-known 端點獲取 HPKE 配置。這依賴於 WebPKI 系統；如果 PKI 被攻破，ODoH 配置的完整性將面臨風險。

擴展生態系統

直到最近，公開的 ODoH 生態系統還非常單薄。長期以來，dnscrypt-proxy 社群幾乎完全依賴單一公開中繼站。透過將用戶端與中繼站封裝在單一的 Rust 二進位檔中，Numa 旨在降低他人建立自己中繼站的門檻。

該專案鼓勵去中心化方法：獨立營運商越多，匿名集合 (anonymity set) 就越強大。對於想要實作此技術的人，Numa 提供了一個開箱即用的 Docker Compose 配方，用於在 Caddy 後方部署中繼站以進行 TLS 終止。

結論

對於現今尋求匿名 DNS 的人來說，路徑變得更加容易實現。透過安裝 Numa 並將模式設定為 odoh，使用者可以將查詢路由至兩個獨立的組織，確保中繼站與目標都無法獲得其數位足跡的完整圖像。