無知なDNS over HTTPS (ODoH): DNSプライバシーを改善する試み

ドメインネームシステム、またはDNSは、インターネット上に存在するさまざまなウェブサイトのための分散型命名システムです。これはインターネットの重要な構成要素の一つであり、30年以上にわたって存在しています。この期間の中で、システムは実装やプライバシーに関する懸念について批判を受けてきました。その結果、これらの懸念に対処するためのいくつかの試みが行われてきました。

その一つが、DNS over HTTPS (DoH)プロトコルの導入であり、これはDNS通信を暗号化された方法で送信することによって、DNS通信を保護することを約束しています。DoHは理論的には有望に見え、DNSの問題の一つを解決しますが、別の懸念を引き起こします。これを解決するために、Cloudflare、Apple、Fastlyによって共同開発された新しいプロトコル、無知なDNS over HTTPS (ODoH)があります。無知なDoHは基本的に、DNSクエリをユーザーのIPアドレスから切り離すことで、DNSリゾルバがユーザーが訪れるサイトを知ることを防ぐDoHプロトコルの拡張です — [この後詳しく説明します]。

「ODoHが目指すのは、クエリを行っているのが誰で、クエリが何であるかの情報を分離することです」とCloudflareの研究責任者Nick Sullivanはブログで述べています。

無知なDNS over HTTPS (ODoH)

ODoHが何であるかに飛び込む前に、まずDNSとその後のDNS over HTTPSが何であるか、そしてそれらがもたらす制限を理解しましょう。

DNS (ドメインネームシステム)

ドメインネームシステム、またはDNSは、インターネット上のすべてのウェブサイトの記録を保持する分散型システムです。これは、電話番号のリストを保持する電話帳のようなリポジトリとして考えることができます。

インターネットに関して言えば、DNSは、ドメイン名を入力するだけでウェブサイトにアクセスできるシステムを確立する上で重要な役割を果たしています。これにより、IP（インターネットプロトコル）アドレスを記憶する必要がなく、アドレスフィールドにtechpp.comを入力することで、このサイトを表示できます。IPアドレスは、デバイスとアクセスしようとしているウェブサイトとの接続を確立するために必要です。しかし、IPアドレスはドメイン名ほど覚えやすくないため、DNSリゾルバがドメイン名を関連付けられたIPアドレスに解決し、要求されたウェブページを返す必要があります。

DNSの問題

DNSはインターネットアクセスを簡素化しますが、いくつかの欠点があります — 最大の欠点はプライバシー（およびセキュリティ）の欠如であり、これはユーザーデータにリスクをもたらし、ISPによって閲覧されたり、インターネット上の悪意のある人物によって盗聴されたりする可能性があります。これが可能である理由は、DNS通信（DNSリクエスト/クエリと応答）が暗号化されておらず、平文で行われるため、ユーザーとISPの間にいる誰でも傍受できるからです。

DoH (DNS over HTTPS)

最初に述べたように、DNS over HTTPS (DoH)プロトコルは、この（セキュリティ）DNSの懸念に対処するために導入されました。基本的に、このプロトコルは、DoHクライアントとDoHベースのリゾルバ間のDNS通信を平文で行うのではなく、暗号化を使用して通信を保護します。これにより、ユーザーのインターネットアクセスを保護し、中間者攻撃のリスクをある程度減少させます。

DoHの問題

DoHはDNS上の暗号化されていない通信の問題に対処しますが、プライバシーの懸念を引き起こします — DNSサービスプロバイダーがあなたのネットワークデータを完全に制御することになります。DNSプロバイダーは、あなたとアクセスするウェブサイトの間の仲介者として機能するため、あなたのIPアドレスとDNSメッセージの記録を保持します。これにより、二つの懸念が生じます。一つは、単一のエンティティがあなたのネットワークデータにアクセスできるため、リゾルバがすべてのクエリをあなたのIPアドレスにリンクできること、もう一つは、最初の懸念のため、通信が単一の障害点（攻撃）にさらされることです。

ODoHプロトコルとその動作

Cloudflare、Apple、Fastlyによって共同開発された最新のプロトコルODoHは、DoHプロトコルの中央集権化の問題を解決することを目指しています。これに対して、Cloudflareは新しいシステムがDNSクエリからIPアドレスを分離することを提案しています。これにより、ユーザー以外の単一のエンティティが両方の情報を同時に見ることができなくなります。

ODoHは、二つの変更を実装することでこの問題に対処します。クライアント（ユーザー）とDoHサーバーの間に公開鍵暗号化の層とネットワークプロキシを追加します。これにより、ユーザーだけがDNSメッセージとIPアドレスの両方にアクセスできることを保証すると主張しています。

要するに、ODoHはDoHプロトコルへの拡張として機能し、以下のことを達成することを目指しています:

i. クライアントのアドレスを削除するためにリクエストをプロキシ経由でチャネル化することで、DoHリゾルバがどのクライアントがどのドメイン名を要求したかを知ることを防ぐ。

ii. プロキシがクエリと応答の内容を知ることを防ぎ、接続を層で暗号化することでリゾルバがクライアントのアドレスを知ることを防ぐ。

ODoHによるメッセージフロー

ODoHによるメッセージフローを理解するために、上記の図を考えてみてください。ここでは、プロキシサーバーがクライアントとターゲットの間に座っています。クライアントがクエリを要求すると（例: example.com）、同じリクエストがプロキシサーバーに送信され、次にターゲットに転送されます。ターゲットはこのクエリを受け取り、復号化し、（再帰的）リゾルバにリクエストを送信して応答を生成します。戻りの途中で、ターゲットは応答を暗号化し、プロキシサーバーに転送し、最終的にクライアントに戻します。最後に、クライアントは応答を復号化し、要求したクエリに対する応答を得ます。

この設定では、クライアントとプロキシ、プロキシとターゲットの間の通信はHTTPSを介して行われ、通信のセキュリティが向上します。さらに、クライアント-プロキシおよびプロキシ-ターゲットの両方のHTTPS接続を介して行われるすべてのDNS通信はエンドツーエンドで暗号化されているため、プロキシはメッセージの内容にアクセスできません。しかし、そうは言っても、ユーザーのプライバシーとセキュリティがこのアプローチで考慮されている一方で、すべてが提案通りに機能することを保証するためには、最終的な条件が必要です — プロキシとターゲットサーバーが共謀しないことです。したがって、企業は「共謀がない限り、攻撃者はプロキシとターゲットの両方が侵害されない限り成功しない」と提案しています。

Cloudflareのブログによると、暗号化とプロキシの保証は以下の通りです:

i. ターゲットはクエリとプロキシのIPアドレスのみを確認します。

ii. プロキシはDNSメッセージを視認できず、クライアントが送信するクエリやターゲットが返す応答を識別、読み取り、または変更する能力がありません。

iii. 意図されたターゲットのみがクエリの内容を読み取り、応答を生成できます。

ODoHの利用可能性

無知なDNS over HTTPS (ODoH)は、現時点では提案されたプロトコルに過ぎず、ウェブ全体で採用される前にIETF（インターネットエンジニアリングタスクフォース）によって承認される必要があります。Cloudflareは、これまでにPCCW、SURF、Equinixなどの企業をプロキシパートナーとして提案し、1.1.1.1 DNSサービスでODoHリクエストを受け付ける機能を追加したとしていますが、実際のところ、ウェブブラウザがプロトコルをネイティブにサポートしない限り、使用することはできません。プロトコルはまだ開発段階にあり、さまざまなプロキシ、レイテンシレベル、およびターゲットでのパフォーマンスがテストされています。そのため、ODoHの運命をすぐに決定するのは賢明ではないかもしれません。

利用可能な情報とデータに基づくと、このプロトコルはDNSの未来にとって有望に見えます — それが約束するプライバシーを達成し、パフォーマンスを損なわない限り。DNSはインターネットの機能に重要な役割を果たしていることは明らかですが、依然としてプライバシーとセキュリティの問題に悩まされています。そして、DNSのセキュリティ面を強化することを約束するDoHプロトコルの最近の追加にもかかわらず、プライバシーの懸念から採用は依然として遠いようです。

しかし、ODoHがプライバシーとパフォーマンスの観点でその主張を実現できれば、DoHとの組み合わせは、両者が連携してDNSのプライバシーとセキュリティの懸念に対処できる可能性があります。そして、結果として、今日の状態よりもはるかにプライベートで安全なものにすることができます。