DNSリークとは？IPを隠しても閲覧履歴が露出する可能性があります

プロキシを使ったりIPアドレスを変更したりすれば、インターネット上で「見えなくなる」と考える人は少なくありません。しかしセキュリティテストでは、見落とされやすい弱点がよく見つかります。IPが変わっていても、どのWebサイトを閲覧したかという情報がインターネットサービスプロバイダーにひそかに伝わる可能性があるのです。これがDNSリークです。オンラインプライバシーを本当にコントロールしたいなら、まずその仕組みを理解する必要があります。

まず確認：DNSは何をするもの？

DNS（Domain Name System）は、インターネットの「電話帳」のようなものです。ブラウザに google.com のようなドメインを入力しても、コンピューターはその文字列がどのアドレスを指すのかを最初から知っているわけではありません。DNSサーバーに「このドメインに対応するIPアドレスは何ですか？」と問い合わせ、回答を受け取って初めてWebサイトに接続できます。

DNSリークとは？

簡単に言えばDNSリークとは、プロキシなどの暗号化されたツールを使っているにもかかわらず、本来は暗号化された経路を通るべきDNSの名前解決リクエストが、誤ってローカルネットワークからインターネットサービスプロバイダー（ISP）のDNSサーバーへ直接送信されてしまう現象です。その結果、どのWebサイトにアクセスしているかが知られる可能性があります。

例えるなら、暗号化した手紙を送っているのに、封筒には宛先を大きな文字で書いているようなものです。中身は守られていても、配送業者には行き先が見えます。DNSリクエストが誤った経路を通ると、普段は意識しない接続部分からプライバシー情報が漏れることがあります。

DNSリークはどのように起こる？

次のような状況は、DNSリークの代表的な原因です。

• システム設定が適切でない：一部のOSは高速化のために複数のDNSサーバーへ同時に問い合わせ、最も早く応答したサーバーを利用します。ISPのローカルDNSサーバーが先に応答すると、問い合わせが暗号化経路を迂回することがあります。
• ネットワーク環境の切り替え：自宅のWi-Fiからモバイルホットスポットへ、あるいはオフィスからカフェへ移動すると、端末は新しいIPを取得する必要があります。ツールに接続切断時の保護機能がないと、再接続の短い間にOSが先にISPのDNSへ接続する場合があります。
• ソフトウェア機能の競合：一部のISPは「透過型DNSプロキシ」を使って通信を強制的に傍受・転送します。ソフトウェア側でDNS設定を変更しても、問い合わせがISPのサーバーへ戻されることがあります。
• IPv6に対応していない：ネットワークはIPv4からIPv6へ移行しつつありますが、IPv4しか対応していないツールも少なくありません。IPv6対応サイトへアクセスした際、IPv6のDNSリクエストが暗号化トンネルの外へ出て、暗号化されていない経路を通る可能性があります。

リークするとどんなリスクがある？

この「名前解決」の段階は目立ちませんが、影響は現実的です。

1. 行動を追跡される可能性がある：DNS問い合わせログから、どのサイトを訪れたかが分かり、オンライン行動のプロファイル作成に利用される可能性があります。
2. ネットワーク環境や位置情報が露出する可能性がある：利用しているDNSサーバーの所属や所在地から、実際の地域やISPを推測され、位置を隠す効果が弱まることがあります。
3. ハイジャックやフィッシングの危険：ローカルISPのDNS保護が弱い場合、名前解決結果が改ざんされる可能性があります。たとえば銀行のドメインが偽のフィッシングサイトへ誘導されても、見た目だけでは気づきにくいことがあります。
4. セキュリティポリシーが機能しなくなる可能性がある：企業や高セキュリティ環境では、DNSリークによってアクセス制御やコンプライアンスポリシーが迂回される場合があります。

DNSリークを検出する方法

最も簡単なのは、オンラインのDNSリークテストを使う方法です。結果に実際のISP名が表示された場合、DNSリクエストが意図しない経路から外へ出ている可能性があります。プロキシ接続後にテストし、定期的な確認項目にするのがおすすめです。

DNSリークを防ぐ5つの方法

• ファイアウォールでDNSの送信先を制限する：DNSリクエストを指定したサーバーにのみ許可し、ローカルネットワークインターフェースからのポート53通信を遮断します。ツールが停止したりネットワークが切り替わったりした場合の補助的な防御になります。
• 切断保護に対応した信頼できる暗号化サービスを選ぶ：サーバー側ではプライベートな暗号化DNSを利用し、名前解決をトンネルへ強制的に戻します。クライアント側には、接続が不安定なときにデータが公共ネットワークへ漏れないようKill Switchがあると安心です。
• 必要に応じてIPv6を無効にする：IPv4とIPv6の互換性問題はDNSリークの原因になりやすいポイントです。必要な場合はシステムのネットワークアダプターでIPv6を一時的に無効化し、通信を保護されたIPv4へ統一します。
• ブラウザでDNS over HTTPS（DoH）を有効にする：主要なブラウザはセキュアDNSに対応しています。DoHを有効にするとDNS問い合わせが暗号化されたHTTPS通信に含まれるため、ISPが平文のDNSリクエストとして識別しにくくなります。
• 複数アカウント運用では設定可能な環境ツールを使う：複数のEC、SNS、広告アカウントを運用する場合は、「リーク防止」と「アカウント環境の分離」を両立したいケースがあります。ブラウザ環境レベルで一元管理する方法が有効です—PurpleMarkはアカウントごとに独立したブラウザ環境を作成し、必要に応じてネットワークパラメータを設定できます。DNS名前解決、ネットワーク出口、fingerprint設定を比較的一貫して管理可能な範囲に保つことで、環境の混在によるリークや関連付けのリスクを抑えるのに役立ちます。

注意：DNSやWebRTCのリーク防止は、正当な運用とプライバシー保護を目的とするものであり、プラットフォームのルールを回避したり、禁止行為を行ったりするためのものではありません。

まとめ

DNSリークは、見落とされやすいドメイン名の名前解決段階で発生します。通信が暗号化され、IPが隠されていても、DNSリクエストが誤った経路を通れば、実際の閲覧行動が記録・利用される可能性があります。原因を理解して定期的にテストし、ファイアウォール制御、DoH、IPv6管理、環境ツールを組み合わせて複数の漏えいポイントをふさぐことが、より実質的なオンラインプライバシー保護につながります。