DNSリークはどう検出する？4ステップでプロキシのDNS問題を確認

要点：IP検査に合格しても、それはアクセスの出口が変わっただけの意味で、DNS問い合わせも同じ経路を通ったことにはなりません。プロキシとDNSは、異なる二つの処理を担います。プロキシは接続をどのネットワーク出口から出すかを決めます。DNSはドメイン名をIPアドレスに変換します。名前解決の問い合わせが想定外の経路を通れば、それがDNSリークです。検出は4ステップで足ります。結果を読み解くことのほうが、テストの実行よりも重要です。

プロキシを設定し、IP確認サイトを開くと、ページにはプロキシのIPが表示されます。そこで「ネットワーク環境は問題ない」と判断します。数日後にアカウントの異常を調べて初めて、DNS問い合わせがずっとローカル回線を使っていたと分かるのです。

問題はプロキシそのものではないのかもしれません。

プロキシを有効にしても、なぜDNSを確認するのか

プロキシとDNSは別々の二つの処理であり、プロキシの有効化はDNSの引き継ぎを意味しません。プロキシは接続をどのネットワーク出口から送るかを決め、DNSはドメイン名の解決を担います。両者は異なるネットワーク段階に関わります。プロキシが正常に動作しても、DNS問い合わせが期待どおりとは限りません。確認が必要です。

具体的なリクエストの流れで見てみます。サイトにアクセスする際、クライアントはまずDNS問い合わせで対象ドメインのIPを取得するか、ドメイン名をプロキシ側に任せるかのどちらかです。どちらになるかは、プロキシプロトコル、クライアントの実装、ブラウザのDNS設定で決まります。プロキシを有効にしても、すべての解決クエリが想定の経路を通るとは自動的には言えません。判断は実際の検出に頼るしかありません。プロキシが「接続済み」と表示されるだけで安心することはできません。

ここで、一つの境界もはっきりさせておきます。DNSリークは、実際の公開IPの露出とイコールではありません。漏れるのはドメイン問い合わせの経路です。どのドメインを調べたかを、解決サービス提供元やローカルネットワークに見られる可能性があります。実際のIPが露出しているかどうかは、独立したIP検査で判断します。シンガポールのサイバーセキュリティ庁はVPNのセキュリティ勧告の中で、DNSリークテストとIPアドレス漏えいテストを、二つの独立した検査として挙げています。理由はまさに、両者が同じ問題を検証するものではないからです（CSAのVPNセキュリティガイダンス）。

DNSリークはどうやって起きるのか

最も多いのは三つの原因で、いずれも設定に関わり、プロキシの良し悪しとは無関係です。順に見ていきます。

プロキシが一部のトラフィックしか処理しない

プロキシ設定によっては、ブラウザのウェブリクエストだけを引き受け、名前解決はローカルシステムが行う場合があります。こうなるかどうかは、プロキシプロトコルとクライアントの処理方式で決まります。ウェブリクエストはプロキシ経由、解決クエリはローカル経由という状態です。この場合、検出結果にローカルネットワークのリゾルバが現れます。

ブラウザで独立したセキュアDNSが有効になっている

ChromeとFirefoxはどちらもDNS over HTTPS（DoH）に対応しています。有効にすると、解決クエリは暗号化されたHTTPS接続で指定の解決サービスへ送られます。ローカルネットワークが問い合わせを直接観察する機会を減らせます。ただし暗号化は、クエリが必ずプロキシを通ることを意味しません。選んだ解決サービスが現在の環境の想定に合うことも保証しません。Firefoxのこの機能は個別に切り替えられます。詳細はMozillaの公式ドキュメントを参照してください。

システム・ブラウザ・プロキシクライアントがそれぞれ別の設定を使う

一番見つけにくい形です。システムが一つのリゾルバを使い、ブラウザでDoHを有効にしてまた別の一つを使い、プロキシクライアントがさらに一つ設定する。重なっていくと、解決経路はブラックボックスになります。プロキシソフトが「接続済み」と表示しても、判断の材料にはなりません。実際に動いているブラウザがどの経路を通ったかを見るしかありません。

解決経路がローカルISPに落ちる場合、問い合わせはISPの解決サービスを経由します。ISPプロキシの仕組みと適用場面を併せて参照してください。

DNSリークの検出方法：4つのステップ

検出自体は難しくありません。鍵は、テスト前に期待値を持ち、テスト後に照合することです。手順は単純です。この4ステップを終えて初めて、結論が固まります。

ステップ 1：先に期待結果を書き出す。テスト前に三つのことを明確にします。現在のプロキシの出口がどの地域か、ドメイン解決は誰が担うべきか、ブラウザでDoHが有効か。期待値がなければ、結果を見ても判断できません。

ステップ 2：プロキシ有効のままテストを実行する。DNSリーク検出に対応したサイトを使います。たとえばdnsleaktest.comで拡張テスト（Extended test）を実行すると、ページに多くのリゾルバが表示されます。BrowserLeaksのDNSチェックページで、リゾルバの所属組織を確認することもできます。リゾルバ名、所属組織、地域を記録しておきます。

ステップ 3：期待値と照らして判断する。結果のリゾルバが、現在のシステム・ブラウザ・プロキシの設定と合致するかを確認します。リゾルバが期待したDNSサービスに属し、想定外のローカル解決経路がなければ、今回のテストは期待どおりと一次判断できます。ローカルISPや見慣れない解決サービスが出たら、まずそれが本当に想定外の設定に属するかを確認します。そのうえで、プロキシクライアントのDNS処理、ブラウザのセキュアDNS、システムのネットワーク設定を一つずつ見ていきます。決めつけは禁物です。一回の検出はその時のテスト条件を反映するだけです。すべてのリクエストに問題がないことを保証するものではありません。

ステップ 4：設定を一か所だけ変えて、再テストする。変更は一か所だけです。プロキシクライアントのDNS処理、ブラウザのDoHスイッチ、システムのネットワーク設定のどれか一つを変えます。再テストして比較します。一度に複数変えると、どの変更が効いたのか分からなくなります。

検出結果の読み方

同じ結果でも、読み方を誤れば手がかりが誤判断に変わります。よくある五つの結果と、それぞれの対応です。

公共DNSはAnycast配信で表示がずれることがあります。

DNSリーク・WebRTCリーク・ブラウザフィンガープリントの違い

四つの検査は四つの異なる情報を見ており、一つの合格は他の合格を意味しません。まずは表からです。並べて見ると、境界が一番はっきりします。

DNSとWebRTCは、どちらも「リーク」という言葉を冠するため、最も混同されやすい二つです。しかし検出の原理も対処法も、まったく異なります。WebRTCリークの検出と設定方法は別記事で扱いました。ここでは割愛します。また、IPv6リークは同じファミリーのもう一項目で、IPv6アドレスがプロキシをバイパスしていないかを見ます。方法はIPv6リーク検出の方法を参照してください。

この四つはそれぞれ異なる情報を反映し、互いに代替できません。プロキシ環境を調べるときは、まず公開IPを確認します。次にDNSとWebRTCを見て、最後にフィンガープリントと環境設定を照合するのがお薦めです。項目の優先度は、実際の利用シーンで決めてください。

MostMate利用時、これらの検査をどう順序立てるか

確認の順序は、まず出口、次に解決、次にWebRTC、最後に環境設定です。まずは出口からです。MostMateで複数のブラウザ環境を管理するときは、プロキシの接続確認とDNSリーク検出を分けて行えます。

プロキシ設定が最初です。環境にプロキシをバインドしたら、製品内のプロキシテストで接続状態を確認します。プロトコル種別（HTTP、HTTPS、SOCKS5、SSH）と認証情報も併せて照合します。プロキシテストの合格は、DNSリーク検出の代わりにはなりません。DNS問い合わせの実際の経路は、プロキシクライアント・ブラウザ・システムの設定に依存するためです。

そのあと、該当プロキシをバインドした環境でDNSチェックページを開きます。手順は同じです。リゾルバの所属が期待どおりかを見ます。

二つ目は、環境の分離です。複数アカウントのシーンでは、各環境のプロキシ・Cookie・フィンガープリントパラメータをそれぞれ独立させます。使い回さないようにします。分離の具体的な範囲はブラウザ環境分離の範囲と設定を参照してください。環境のプロキシ設定を誤ったり設定を共用したりすると、検出結果に照合の意味がなくなります。分離はセッションと設定の管理に役立ちます。ただし、DNS経路が自動的に正しくなるわけではなく、外部検出の代用にもなりません。

三つ目は、境界の確認です。フィンガープリントブラウザの役割は、環境を整理して整えることです。プロキシが実際に機能しているか、DNSが想定の経路を通っているかは、外部の検出で確認します。検査はここで終わりません。設定変更やシステム更新のあとは、再テストをお薦めします。

よくある質問

プロキシを有効にしているのに、DNS検出でローカルリゾルバが出ます。プロキシの故障ですか？

一概にそうとは言えません。プロキシはウェブリクエストだけを引き受け、解決クエリをシステムやブラウザが別途処理している可能性があります。プロキシクライアントのDNS処理とブラウザのDoH設定を一つずつ確認します。変更は一度に一つ。そのつどテストしてください。

DNSリークで実際のIPは露出しますか？

イコールにはできません。DNSリークが映すのは、ドメイン解決リクエストの経路です。実際に何が露出するかは、ネットワーク設定と検出シーン次第です。実際の公開IPが隠れているかは、独立したIP検査で確認します。DNS解決経路は別途チェックします。

フィンガープリントブラウザを使ってもDNSリークは起きますか？

起こる可能性があります。フィンガープリントブラウザが管理するのは、環境分離とフィンガープリントパラメータです。DNSの挙動はプロキシプロトコルとシステム・ブラウザの設定次第です。検出は省けません。

DNS検出に合格したあと、他に何を確認すべきですか？

WebRTCリークとブラウザフィンガープリントの二つが残ります。それぞれ対応するツールで検証します。すべて合格すれば完了です。この環境のネットワーク層の検査は、そこで初めて成立します。

まとめ

DNSリーク検出の価値は、「合格」か「不合格」かの判定を得ることではなく、現在の環境のネットワークリクエストが期待どおりかを確認することにあります。公開IP・DNS・WebRTC・ブラウザフィンガープリントにはそれぞれ対応する検査方法があり、一つの結果で他の検証を代用することはできません。どのフィンガープリントブラウザを使っていても、プロキシやネットワーク設定の変更後には、再検出をお薦めします。

複数のブラウザ環境を管理する必要があれば、まずMostMateの環境設定とプロキシ管理の方式を確認します。そのうえで、本稿の手順に沿って一つずつ検証してみてください。プロキシの層をより安定して設定したいなら、MostMateをダウンロードできます。無料版は2環境まで使えます。まずは最初の環境から。検出フローを一通り通してみてください。