プライバシー護衛隊 - デジタル活動の痕跡：DNSクエリに隠されたプライバシー情報と、DoH/DoT/ODoHによる技術的防御

デジタル活動の痕跡：DNSクエリに隠されたプライバシー情報と、DoH/DoT/ODoHによる技術的防御

Tags: DNS, プライバシー, DoH, DoT, ODoH

はじめに：見過ごされがちなDNSクエリのプライバシーリスク

インターネットを利用する際、私たちは無意識のうちに「ドメインネームシステム（DNS）」の恩恵を受けています。WebサイトのURLを入力したり、アプリケーションが外部サービスに接続したりする際に、その裏側ではドメイン名に対応するIPアドレスを問い合わせる「DNSクエリ」が必ず発生しています。DNSはインターネットのインフラストラクチャとして不可欠な要素ですが、このクエリ情報自体が私たちのデジタルプライバシーにとって、見過ごされがちな、しかし重大なリスクとなり得ます。

ほとんどのインターネット通信は、近年TLS/SSLによって暗号化され、通信内容の傍受は困難になっています。しかし、通信相手のIPアドレスを特定するための最初のステップであるDNSクエリは、長らく暗号化されずに平文でやり取りされてきました。これは、インターネットサービスプロバイダ（ISP）、中間者攻撃者、あるいはネットワーク管理者など、通信経路上に存在する第三者が容易に傍受し、解析できることを意味します。

DNSクエリからは、ユーザーがどのWebサイトにアクセスしようとしているか、どのオンラインサービスを利用しようとしているかといった情報が筒抜けになります。これらの情報は、個人のオンラインでの行動パターン、興味関心、利用サービスなどを詳細にプロファイリングするために悪用される可能性があります。例えば、特定の医療サイトへのアクセス履歴、金融サービスの利用履歴、あるいは特定のニュースサイトへの頻繁なアクセスなど、センシティブな情報が第三者に把握されるリスクが存在します。

さらに、国家レベルでのインターネット検閲や、特定のサイトへのアクセスを妨害する手段としても、DNSレベルでの監視や改ざんが悪用されることがあります。企業環境においては、従業員のWeb利用状況の監視に用いられることが一般的ですが、意図せぬ情報漏洩や、悪意のある第三者による情報収集の起点となりうる点も考慮する必要があります。

本稿では、従来のDNSが抱えるプライバシー上の課題を掘り下げ、そのリスクを軽減するための技術的な解決策として近年注目されている「DNS over TLS (DoT)」、「DNS over HTTPS (DoH)」、そして「Oblivious DNS over HTTPS (ODoH)」といった技術について、その仕組み、利点、および導入における考慮事項を解説します。デジタル時代のプライバシー護衛隊として、これらの技術を理解し、適切に活用することは、私たち自身の、そして組織のデジタルプライバシーを守る上で不可欠なステップと言えるでしょう。

従来のDNSの仕組みとプライバシーリスク

ドメイン名前解決のプロセス

インターネット上のサーバーを識別するためにはIPアドレスが必要ですが、人間にとっては「www.example.com」のようなドメイン名の方が扱いやすいため、DNSがドメイン名とIPアドレスの変換（名前解決）を仲介します。

一般的な名前解決のプロセスは以下のようになります。

ユーザーのデバイス（PCやスマートフォン）上のアプリケーションが、特定のドメイン名に対応するIPアドレスを知る必要がある場合、OSのスタブリゾルバに問い合わせます。
スタブリゾルバは、設定されたローカルネットワーク上のDNSサーバー（通常はルーターやISPのDNSサーバー）にDNSクエリを送信します。
ローカルDNSサーバーは、自身が保持するキャッシュを検索するか、ルートDNSサーバーから順に権威DNSサーバーに問い合わせを行い、最終的に目的のドメイン名に対応するIPアドレスを取得します。
ローカルDNSサーバーはそのIPアドレスをキャッシュし、ユーザーのデバイスに返答します。
ユーザーのデバイスは取得したIPアドレスを用いて目的のサーバーと通信を開始します。

従来のDNSが抱えるプライバシー課題

従来のDNSは、UDPまたはTCPのポート53を使用して通信を行います。この通信において、DNSクエリと応答は暗号化されず、平文のままインターネット上を流れます。

この「平文での通信」という特性が、以下のプライバシーリスクを生み出します。

クエリ内容の傍受: ネットワーク上の任意の地点（ISPの設備、悪意のある無線LANアクセスポイント、国家の監視装置など）で通信を傍受している第三者は、通過するDNSクエリとその応答の内容を容易に読み取ることができます。これにより、ユーザーがアクセスしようとしているドメイン名（すなわち、利用しようとしているサービスや見ようとしているWebサイト）が筒抜けになります。
通信相手の特定: DNSクエリの送信元IPアドレスは、そのクエリを発行したデバイスやネットワークを特定します。傍受したドメイン名と送信元IPアドレスを組み合わせることで、「どのIPアドレスのユーザーが、いつ、どのドメインにアクセスしようとしたか」という活動履歴が正確に把握されてしまいます。
行動プロファイリング: 継続的にDNSクエリを収集・分析することで、個人の興味関心、勤務先、利用しているSaaS、アクセス頻度などを詳細に把握し、個人のプロファイルを構築することが可能になります。これは、ターゲティング広告、市場調査、あるいはサイバー攻撃の準備（特定の組織が利用しているサービスの特定など）に悪用される恐れがあります。
検閲・通信妨害: 政府などが特定のドメインへのアクセスを制限したい場合、DNSサーバーでの名前解決を拒否したり、偽のIPアドレスを返したりすることで、ユーザーが目的のサイトに到達するのを妨害することが可能です（DNSフィルタリング、DNSポイズニング）。平文であるため、特定のドメイン名を含むクエリを検出して制御することが容易です。

HTTPSなどによる通信内容の暗号化が進む現代において、通信の「入口」にあたるDNSクエリの平文通信は、デジタルプライバシーにおける重大な脆弱性として認識されるようになりました。

DNSプライバシーを強化する技術

従来のDNSが抱える平文通信の課題を克服し、DNSクエリのプライバシーとセキュリティを向上させるために、いくつかの新しい技術が開発され、普及が進んでいます。主要なものとして、DNS over TLS (DoT)、DNS over HTTPS (DoH)、そしてOblivious DNS over HTTPS (ODoH) が挙げられます。

DNS over TLS (DoT)

DoTは、DNS通信をTLS（Transport Layer Security）プロトコルで暗号化する技術です。これにより、DNSクエリと応答の内容が暗号化され、通信経路上の第三者による傍受や改ざんを防ぐことができます。

仕組み: TCPポート853を使用して、DNSサーバーとの間にTLSトンネルを確立します。その確立されたセキュアなチャネル上でDNSクエリを送信します。
利点:
- DNSクエリ/応答の内容が暗号化されるため、盗聴や改ざんのリスクを低減できます。
- DNSSEC（DNS Security Extensions）と組み合わせて使用することで、偽装された応答に対する検証も可能になります。
- 比較的シンプルで、従来のDNSプロトコル（RFC 1035）のメッセージ形式をそのまま使用できます。
欠点:
- 使用するポート番号が53番（従来のDNS）とは異なる853番であるため、ネットワークファイアウォールなどでブロックされる可能性があります。特定のポートでの通信であるため、ネットワーク管理者によるDNSトラフィックの識別と比較が比較的容易です。
- 名前解決を行うDNSサーバー（リゾルバ）には、クエリの発行元IPアドレスが直接伝わります。

DoTは、Android 9以降のプライベートDNS機能などでサポートされており、OSレベルでの設定が可能です。

DNS over HTTPS (DoH)

DoHは、HTTPS（HTTP over TLS）プロトコルを利用してDNS通信を行う技術です。Web通信と同じポート番号（TCP 443）を使用することで、DNSトラフィックを一般的なWebトラフィックに紛れ込ませ、ネットワーク管理者による識別を困難にする側面があります。

仕組み: HTTP/2プロトコル上でDNSクエリを送信します。HTTPSを使用するため、TLSによる暗号化が施されます。DNSクエリは通常、HTTPのPOSTまたはGETリクエストのペイロードとして含まれます。
利点:
- DNSクエリ/応答の内容が暗号化されるのはDoTと同様です。
- TCPポート443を使用するため、多くのファイアウォールやネットワーク環境で許可されており、ブロックされにくい傾向があります。これにより、特定のDNSトラフィックを検閲・ブロックしようとする試みを回避できる場合があります。
- 一般的なWebトラフィックの中に紛れ込むため、DNSクエリであることの識別が難しくなります（ただし、トラフィック量やパターン分析により推測される可能性はあります）。
欠点:
- 名前解決を行うDNSサーバー（リゾルバ）には、クエリの発行元IPアドレスが直接伝わります。
- HTTP/2プロトコルを使用するため、DoTと比較してオーバーヘッドが大きくなる場合があります。
- HTTP/2のHead-of-Line Blockingの問題がパフォーマンスに影響を与える可能性があります。
- トラフィックがポート443に集中するため、ネットワーク管理者にとってはHTTP/Sトラフィック全体の中からDNSクエリだけを特定してフィルタリングや監視を行うことが難しくなり、かえって制御が効きにくくなるという側面があります。これは、企業内ネットワークにおけるセキュリティポリシーの適用という観点からは課題となり得ます。

DoHは、主要なWebブラウザ（Firefox, Chrome, Edgeなど）や、Windows 10/11、macOSといったOSでサポートが進んでいます。

Oblivious DNS over HTTPS (ODoH)

ODoHは、DoHの仕組みをさらに発展させ、DNSクエリのプライバシーをより強化する技術です。クライアント、プロキシ、ターゲットリゾルバという3者構造をとることで、リゾルバにクライアントのIPアドレスが直接伝わらないように設計されています。

仕組み:
1. クライアントは、プロキシサーバーに対して暗号化されたDNSクエリ（暗号化にはターゲットリゾルバの公開鍵を使用）をDoHで送信します。
2. プロキシサーバーは、クライアントからのリクエストを受け取りますが、その内容は（ターゲットリゾルバの公開鍵で暗号化されているため）読み取れません。プロキシは、その暗号化されたリクエストをターゲットリゾルバに転送します。この際、プロキシは自身のIPアドレスを使用してターゲットリゾルバと通信します。
3. ターゲットリゾルバは、プロキシから暗号化されたリクエストを受け取り、自身の秘密鍵で復号してDNSクエリの内容を読み取ります。名前解決を行い、その結果を再び暗号化してプロキシに返します。ターゲットリゾルバにはプロキシのIPアドレスしか伝わらず、クライアントのIPアドレスは知られません。
4. プロキシは、ターゲットリゾルバからの暗号化された応答を受け取り、そのままクライアントに転送します。プロキシは応答の内容も読み取れません。
5. クライアントは、プロキシから応答を受け取り、自身で復号して名前解決の結果を得ます。
利点:
- 最も高いレベルのプライバシー保護を提供します。DNSクエリの内容と、クエリの発行元IPアドレスが、単一のエンティティに同時に知られることがありません（ターゲットリゾルバはクエリ内容を知るがクライアントIPを知らず、プロキシはクライアントIPを知るがクエリ内容を知らない）。
- DoHと同様にポート443を使用するため、ブロックされにくいです。
欠点:
- プロキシとターゲットリゾルバの連携が必要であり、システム構成が複雑になります。
- 通信経路が増えるため、名前解決のパフォーマンスに影響を与える可能性があります。
- プロキシとターゲットリゾルバが共謀した場合、プライバシー保護が無効になるリスクがあります。信頼できるプロキシおよびリゾルバの選択が重要です。

ODoHは比較的新しい技術であり、対応しているクライアントソフトウェアやサービスはまだ限定的ですが、プライバシー重視の文脈で今後の普及が期待されています。CloudflareなどがODoHサービスを提供しています。

企業におけるDNSプライバシー対策の考慮事項

個人ユーザーとしてこれらの技術を活用することはもちろん重要ですが、ビジネス環境においては、組織全体でDNSプライバシーをどのように管理・強化するかが課題となります。

内部DNSとDoH/DoT/ODoHの連携

多くの企業ネットワークでは、Active Directory連携や内部リソースの名前解決のために独自の内部DNSサーバーが運用されています。外部へのDNSクエリについては、この内部DNSサーバーからインターネット上のDNSサーバー（ISPのDNSやパブリックDNSサービスなど）へ転送される構成が一般的です。

このような環境下でクライアント端末が勝手にDoH/DoT/ODoHを使用して外部のパブリックリゾルバと通信した場合、以下の問題が発生する可能性があります。

内部リソースの名前解決不能: 内部DNSサーバーを介さずに名前解決を行うため、イントラネット内のサーバーやサービスにアクセスできなくなる可能性があります。
セキュリティポリシー・フィルタリングの Bypass: 多くの企業では、DNSクエリのログ収集や、特定の悪性サイトへのアクセスをDNSレベルでブロックするフィルタリング（DNSファイアウォール、SWGなど）を導入しています。クライアントがDoH/DoTを使用すると、この制御を回避してしまい、セキュリティポリシー違反やマルウェア感染のリスクを高める可能性があります。
可視性の低下: ネットワーク管理者は、従業員がどの外部サービスを利用しているか（特にクラウドサービスなど）をDNSログから把握している場合がありますが、DoH/DoT通信が増えるとこの可視性が失われます。

これらの問題を解決するためには、以下の対策が考えられます。

内部DNSサーバーのDoH/DoT/ODoH対応: 企業の内部DNSサーバー自体を、クライアントからのDoH/DoT/ODoHリクエストを受け付けられるように改修または置き換えることで、セキュアな通信を維持しつつ、内部リソースの名前解決やポリシー適用を可能にします。外部への転送部分のみをセキュアなチャネル（例えば、信頼できる外部DoH/DoTリゾルバへの転送）に置き換える構成も考えられます。
企業ポリシーによるDoH/DoTの制御:
- 許可制: 特定の信頼できるDNSサーバーへのDoH/DoT通信のみを許可し、それ以外の宛先への通信をブロックする。ホワイトリスト方式です。
- 強制: すべてのDNSクエリを内部DNSサーバーを経由させ、必要に応じて内部DNSサーバーがセキュアな外部リゾルバに転送するように強制する。クライアント端末でのパブリックDoH/DoTリゾルバへの直接通信はブロックします。
- OSやアプリケーションの設定管理（GPO、MDMなど）により、強制的に内部DNSサーバーを使用させる設定を適用します。
ネットワークレベルでの識別と制御: DoH/DoT/ODoHトラフィックは暗号化されていますが、パケットの振る舞い（宛先IPアドレス、トラフィックパターンなど）から識別を試み、ポリシーに基づいた制御を行う高度なファイアウォールやセキュリティゲートウェイ製品の導入も検討されます。

信頼できるDNSプロバイダの選択

DoH/DoT/ODoHを利用する場合、どのDNSサーバー（リゾルバ）を利用するかが非常に重要になります。いくら通信経路が暗号化されていても、最終的にクエリを受け付けるDNSサーバーの運用者が、クエリ内容を収集・蓄積し、悪用または第三者に提供する可能性があります。

信頼できるプロバイダを選択する際のポイントは以下の通りです。

ログポリシー: DNSクエリログをどの程度保持しているか、そのログをどのように利用するか、第三者に提供するかといったポリシーを明確に開示しているか。プライバシーを重視するプロバイダは、「ノーログポリシー」を掲げていることが多いです。
運営者の信頼性: プロバイダの運営主体は誰か、その評判や過去の事例はどうか。
所在地と法規制: プロバイダが所在する国や地域の法規制（例：データ保持義務、監視に関する法）が、プライバシー保護の観点から適切か。
パフォーマンスと可用性: 名前解決の速度、サーバーの安定性、地理的な分散度なども考慮します。

企業として利用する場合は、これらの観点に加え、サービスレベルアグリーメント（SLA）やサポート体制なども評価基準となります。

まとめと今後の展望

DNSクエリは、私たちがインターネット上で何を見ているか、何を利用しているかを示す重要なデジタルフットプリントです。従来のDNSが抱える平文通信のリスクは、個人のプライバシーだけでなく、組織の情報セキュリティやコンプライアンスにおいても無視できない課題となっています。

DoT、DoH、そしてODoHといった技術は、DNSクエリの通信を暗号化することで、これらのプライバシーリスクを大幅に軽減する強力な手段となります。DoTはポート分離による識別可能性が残るもののシンプルでセキュアな選択肢であり、DoHはWebトラフィックへの擬態による検閲耐性を持つ一方、中央集権化やネットワーク制御の課題も伴います。ODoHは最も高いプライバシー性を目指しますが、構成の複雑さやパフォーマンスがトレードオフとなり得ます。

これらの技術の普及はまだ過渡期にありますが、OSやブラウザでのサポートが進むにつれて、セキュアなDNS通信が標準となる未来が近づいています。特に企業においては、従業員がこれらの技術を各自で設定することで意図せずセキュリティポリシーを迂回するリスクがあるため、IT部門が主体となって、内部DNSとの連携、ポリシーによる制御、信頼できるプロバイダの選定といった対策を講じる必要があります。

デジタル時代のプライバシー保護は、単一の技術や対策で完結するものではありません。DNSプライバシーの強化は、通信内容の暗号化、安全な認証、データ利用の同意管理といった他の対策と組み合わせることで、より堅牢な防御体制を構築することができます。

私たち「プライバシー護衛隊」は、今後も最新のプライバシー技術動向やリスク情報を提供してまいります。本稿が、皆様のDNSプライバシーへの理解を深め、より安全なデジタル環境を構築するための一助となれば幸いです。