ODoHとNumaでDNSプライバシーのパラドックスを打破する

Pi-hole、AdGuard Home、または標準的なフォワーディング・リゾルバを使用しているユーザーにとって、DNSプライバシーはしばしばトレードオフの関係にあります。単一のオペレーターを信頼して、IPアドレスと訪問するすべてのサイトの両方を彼らに見せるか、あるいはUnboundのような再帰的リゾルバに切り替えて、チェーン内のすべての権威ネームサーバーにIPアドレスをさらすか、のどちらかです。DNS over HTTPS (DoH) や DNS over TLS (DoT) はトランスポート層を暗号化しますが、ユーザーの閲覧習慣について誰が何を知るかという根本的な現実は変わりません。

AppleのiCloud Private Relayは、イングレス・プロキシ（IPは見えますがリクエストは見えない）とエグレス・プロキシ（リクエストは見えますがIPは見えない）の間でパスを分割することで、この問題を解決しようとしました。しかし、このソリューションはサブスクリプション、特定のハードウェア、および厳選されたパートナーによって制限されています。セルフホスト・コミュニティにとって、アカウント要件やプラットフォームのロックインなしに、真に匿名なDNSオプションは、ODoHの採用まで実現困難なものでした。

ODoHを理解する：Oblivious DNS over HTTPS

ODoH (RFC 9230) は、クライアントとターゲット・リゾルバの間にリレーを導入することで、DNSクエリを匿名化するように設計されたIETFプロトコルです。プロセスは一連の暗号学的ハンドシェイクを通じて機能します：

クライアント: ターゲット・リゾルバのHPKE (Hybrid Public Key Encryption) 公開鍵を使用して、DNSクエリを暗号化します。また、レスポンス用の対称鍵も含まれます。
Numa リレー: リクエストを受け取ります。クライアントのIPアドレスは見えますが、中身は暗号文のみです。質問されている内容は見ることができません。
ターゲット (例: Cloudflare): 自身のプライベート鍵を使用して質問を復号します。リクエストは見えますが、リレーのIPアドレスのみが見え、元のクライアントのIPアドレスは見えません。
リターン・パス: ターゲットは、クライアントから提供された対称鍵を使用して回答を暗号化し、リレー経由で送り返します。リレーは内容に対して盲目なままです。

HPKE (RFC 9180) を使用することで、ODoHはチェーン内のどの単一のエンティティも、ユーザーの身元（IP）と意図（DNSクエリ）の両方を所有しないことを保証します。

リレーの構築：セキュリティとアーキテクチャ

ODoHリレーをデプロイすることは、単にパケットを転送することほど単純ではありません。インフラストラクチャが悪用されるのを防ぐために、特定の保護策が必要です。Numaプロジェクトは、以下の主要なメカニズムを通じてこれらを実現しています：

SSRFの強化

リレーは、リクエストURLで指定されたターゲットへのアウトバウンド接続を開くため、Server-Side Request Forgery (SSRF) の主要な標的となります。これを軽減するために、NumaはRFC 1035 ASCIIラベルを強制し、IPリテラル、非443ポート、およびInternationalized Domain Names (IDNs) を明示的に禁止する、正規表現に厳格なホスト名バリデーターを採用しています。

同一オペレーター・チェック

ODoHの核心となるプライバシー保護の保証は、リレーとターゲットが異なる組織によって運営されていることに依存します。もし一つのエンティティが両方を制御している場合、彼らはリレーからのIPアドレスとターゲットからのクエリを相関させることができ、匿名性は「見せかけ」のものになってしまいます。Numaは、デフォルトでリレーとターゲットが同じ組織ドメインを共有している構成を拒否するために、eTLD+1チェックを実装しています。

ODoHの限界

ODoHはプライバシーを大幅に改善しますが、万能薬ではありません。考慮すべきいくつかの運用上および技術的な制約があります：

ターゲットの信頼: ODoHは信頼を排除するのではなく、信頼の対象を移動させます。ターゲット・リゾルバは依然として質問内容を見ることができます。保護の内容は、単にその質問が特定のユーザーに紐付けられていないということです。
再帰的リーク: ターゲットが再帰モードで動作している場合、ターゲットからルート、TLD、および権威サーバーへの後続のホップは、通常、プレーンテキストのUDP/TCPです。ODoHはクライアントからターゲットへの区間のみを保護します。
トラフィック分析: 小規模なリレーはタイミング攻撃に対して脆弱です。リレー上のアクティブなユーザーが一人しかいない場合、ターゲットは着信リクエストのタイミングを、ユーザーの身元を推測するために相関させることができます。プライバシーは、ユーザー数とパディング・トラフィックの量に比例します。
中央集権的な鍵配布: 現在、クライアントはHTTPS経由でターゲットの well-known エンドポイントからHPKE構成を取得します。これは WebPKI システムに依存しています。PKIが侵害された場合、ODoH構成の整合性がリスクにさらされます。

エコシステムの拡大

最近まで、公開ODoHエコシステムは非常に希薄でした。長らく、dnscrypt-proxy コミュニティティは、ほぼ単一の公開リレーに依存していました。Numaをクライアントとリレーの両方を単一の Rust バイナリで提供することで、Numaは、他のユーザーが独自の自前リレーを構築するための障壁を低くすることを目指しています。

このプロジェクトは分散化されたアプローチを推奨しています：独立したオペレーターが増えるほど、匿名性セットが強固になります。これを実装したいと考えている方には、Numaは、TLS終端のための Caddy を背後に配置してリレーをデプロイするための、すぐに使える Docker Compose レシピを提供しています。

結論

今日、匿名なDNSを求めている人々にとって、その道はより身近なものになりました。Numaをインストールしてモードを odoh に設定することで、ユーザーはクエリをートゥー・インディペンデント・オーガニゼーション（二つの独立した組織）経由でルーティングし、リレーがターゲット・リゾルバ・リゾルバのどちらにも、ユーザーのデジタル・フットプリントの完全な姿を見ることができないようにすることができます。