DNS漏洩とは何か — そして実際にテストする方法

簡単にまとめると：VPNトンネルは、デバイスが他のサーバーに送るIPパケットを暗号化します。DNSはパケットが送られる前に行われる名前解決です — デバイスが「example.comのIPアドレスは何か？」と問い合わせる処理です。この問い合わせがVPN経由ではなくISPのリゾルバに送られると、暗号化されたその後のトラフィックは見えなくても、ISPにはドメインが見えてしまいます。それが漏洩です。最もシンプルな理由でVPNのプライバシーの約束を破ることになります：間違ったDNSリゾルバに問い合わせてしまうのです。朗報としては、漏洩は検出が簡単で、通常は修正も容易であり、適切に構築されたVPNアプリのほとんどはデフォルトで防止しています。悪い知らせは、「ほとんど」は「すべて」ではなく、いくつかの一般的な設定では、それ以外は正しく設定されたVPNでも漏洩が発生するということです。

DNSが実際に何をするか、そしてなぜ漏洩するか

DNS（Domain Name System）はインターネットのアドレス帳です。デバイスがウェブサイトに接続するたびに、まず人間が読めるホスト名（example.com）を、ルーターが実際にパケットを転送できる数値のIPアドレス（93.184.216.34のようなもの）に変換する必要があります。この変換ステップがDNSクエリであり、その後に行われる実際のウェブリクエストとは別のネットワーク操作です。

一般的な家庭の接続では、DNSリゾルバはISPによってDHCPで割り当てられます — IPアドレスを配布するのと同じ仕組みです。Wi-Fiに接続すると、ルーターはデバイスに「DNSサーバーは192.168.1.1で、ISPの再帰リゾルバに転送されます」と伝えます。あなたが調べるすべてのドメインはそのリゾルバを通ります。ISPはそれを記録し、データブローカーに販売し（米国ではこれは合法です）、または法執行機関に提供できます。

VPNに接続すると、2つのことが起きるべきです。まず、ネットワークトラフィックが暗号化されてVPNトンネルを経由するようになります。次に、DNSリゾルバが変わるべきです — ISPのリゾルバから、VPNプロバイダー（または暗号化トンネルを通じてのみアクセス可能なプライバシー重視のサードパーティリゾルバ）が運営するものへと。前半だけが行われると、DNS漏洩が発生します。トラフィックは暗号化されていますが、トラフィックの前に行われた名前解決は依然としてISPに流れ、これからアクセスするすべてのサイトをISPに伝えてしまいます。

プライバシーの観点から、DNSクエリはトラフィック自体とほぼ同じくらい多くを明かします。クエリは正確なドメイン（サブドメインまで — mail.example.comはwww.example.comと区別できます）とタイミングを明らかにします。直後の暗号化トラフィックの量と組み合わせることで、DNS漏洩のあるVPNはほぼすべての意味においてあなたのブラウジングセッションを再構築するのに十分なメタデータを観察者に与えます。

DNS漏洩が発生する4つの原因

DNS漏洩は単一のバグではありません。それぞれ異なる根本原因と異なる修正方法を持つ、関連した設定ミスのグループです。頻度のおおよその順番で：

1. OSバイパス — Windows分割DNS / Smart Multi-Homed Name Resolution

WindowsにはSmart Multi-Homed Name Resolutionという機能があります。これが有効な場合、VPNがアクティブであっても、物理インターフェース上のISPのリゾルバを含む、利用可能なすべてのDNSリゾルバに並行してDNSクエリを送信します。最も早く応答したリゾルバが勝ち、他は無視されますが、クエリ自体はすでに送信されています。ほとんどのWindowsマシンではこれがデフォルトで有効です。修正方法は、グループポリシーを通じてこの機能を無効にするか、接続時にVPNクライアントがそれを行うよう設定することです。Linuxでも、正しく設定されていない場合はsystemd-resolvedで同様の問題が発生します。macOSとiOSはこれをよりうまく処理しますが、完璧ではありません。

2. スプリットトンネルの設定ミス

スプリットトンネリングでは、一部のアプリをVPN経由で、他のアプリを通常の接続経由でルーティングできます。よくある設定ミスは、アプリベースのスプリットトンネリングをアプリごとのDNS設定なしに行うことです — これにより、VPNトンネル外にルーティングされたアプリがVPNのDNSリゾルバを使おうとしたり、逆のことが起きたりして、OSが提供するどちらかのパスを通じて漏洩してしまいます。より悪いバリエーション：スプリットトンネルはアプリのTCPトラフィックをトンネル外に正しくルーティングしているが、OS全体のDNSリゾルバがまだISPのリゾルバであるため、トンネルされているかどうかにかかわらず、すべてのアプリがDNSクエリをISPに漏洩させます。この幅広いトピックはスプリットトンネリングが実際に何をするかの記事で詳しく説明しています。

3. IPv6フォールバック

多くのVPNクライアントはIPv4が唯一のルーティングの懸念事項だった時代に設計されました。これらはIPv4のファイアウォールとルーティングルールをインストールしてDNSをトンネル経由で正しくルーティングしますが、対応するIPv6ルールをインストールしません。ネットワークにIPv6接続がある場合、OSはDNSクエリにIPv6を優先することがあります — そしてそれらのクエリはVPNを完全にバイパスして裸のインターフェースから出て行きます。これは2026年において最も一般的な漏洩モードの一つで、ISPからデュアルスタックIPv4/IPv6を持つ住宅用ブロードバンド接続で特によく見られます。修正方法はIPv6をグローバルに無効にすること（強引ですが信頼性が高い）か、IPv6ルートを明示的に処理するVPNクライアントを使用することです。

4. WebRTCとブラウザ解決DNS

Chrome、Edge、Firefox、Safariなどの最新のブラウザは、OSリゾルバを使用する代わりに自分でDNS名前解決を実行できます。最もよく知られているケースはWebRTCです。これはビデオチャットで使用されるピアツーピアプロトコルです。WebRTCはSTUNサーバーを使用してあなたの実際のローカルおよびパブリックIPアドレスを発見し、歴史的にはVPNがアクティブであっても両方をブロードキャストしていました。WebRTCからの「本物の」IPは、明示的な対策が必要なブラウザサイドの長年の漏洩問題です。別途、DNS-over-HTTPS（DoH）を使用するブラウザは、OSリゾルバの設定に関係なく、DNSクエリを直接Cloudflare、Google、またはNextDNSにルーティングできます — これが助けになることもあれば（公開リゾルバへのDoHはISPへの平文よりプライベート）、損害になることもあります（公開リゾルバはまだあなたのクエリを見ており、ブラウザはVPNのDNSルールをバイパスしています）。

1分以内にDNS漏洩をテストする方法

DNS漏洩のテストは、実際にやるよりも説明する方が時間がかかります。VPNに接続してから、以下の3つのツールのいずれかにアクセスしてください。それぞれが漏洩面の少し異なる側面を明らかにします。

dnsleaktest.com

定番です。dnsleaktest.comにアクセスし、「Extended test」をクリックして約20秒待ちます。このツールは管理するユニークなホスト名に対して一連のDNSクエリを発行し、実際にそれらの名前解決を行ったリゾルバを表示します。リゾルバリストにISPの名前（Comcast、Verizon、BTなど）が表示されたら漏洩しています。VPNプロバイダーのリゾルバ（またはQuad9やCloudflareの1.1.1.1のようなプライバシー重視の公開リゾルバ）のみが表示されれば、OS DNSパスは正しく設定されています。

browserleaks.com/dns

dnsleaktestよりも詳細です。どのリゾルバがクエリを処理したかだけでなく、その地理的位置、ASN（ネットワーク事業者）、DNS-over-HTTPSまたはDNS-over-TLSをサポートしているかどうかも表示します。正しい種類のリゾルバが使用されているが間違った国にある微妙な漏洩を検出したり、暗号化DNSプロトコルが実際に使用されていることを確認するのに役立ちます。

ipleak.net

最も包括的です — DNS漏洩、WebRTC漏洩、IPv4とIPv6の可視性をテストし、あなたのジオロケーションがどのように見えるかを表示します。WebRTCセクションは重要です：192.168.x.xまたは10.x.x.xの範囲の「ローカルIP」アドレスがVPNエンドポイントに一致する「パブリックIP」と並んで表示されていれば、VPNは正しく機能していますがブラウザがWebRTC経由で漏洩しています。IPv6セクションはdnsleaktestが見逃すことがあるIPv6フォールバック漏洩を検出します。

クリーンな結果と漏洩している結果の違い

正しく設定されたVPNでdnsleaktest.comの拡張テストを実行すると、次のような結果が表示されるはずです：

Test results (clean): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 1.2.3.5 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Conclusion: No DNS leak detected. All queries went to the VPN's resolver.

そして漏洩している場合はこのようになります：

Test results (leaking): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 75.75.75.75 Hostname: cdns01.comcast.net ISP: Comcast Country: United States Server: 75.75.76.76 Hostname: cdns02.comcast.net ISP: Comcast Country: United States Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.

重要なシグナルはISP列です。VPNプロバイダー（または意図的に選んだ公開リゾルバ）以外のものが表示されれば、DNSが漏洩しています。国列にVPN出口国と並んであなたの実際の国が表示されれば漏洩しています。VPNのエンドポイントの国のみが表示されていれば、安全です。

漏洩タイプの比較

4種類の漏洩タイプにはそれぞれ、テスト結果に異なるフィンガープリントがあり、それを悪用できる観察者が異なり、修正方法も異なります：

4つの一般的な原因の修正

OSバイパス漏洩の修正（Windows）

Windows 10および11では、グループポリシー（コンピューターの構成 → 管理用テンプレート → ネットワーク → DNSクライアント → 「スマートなマルチホーム名前解決を無効にする」→ 有効）を通じて、またはPowerShellでSet-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1を実行して、Smart Multi-Homed Name Resolutionを無効にします。再起動してください。メンテナンスが行き届いたVPNクライアントは接続時に自動的にこれを行います — あなたのクライアントが行わない場合は、手動で行ってください。

スプリットトンネル漏洩の修正

スプリットトンネルのルールセットを確認してください。保護されるべきすべてのアプリに対して、TCPトラフィックとDNSクエリの両方がトンネルを通じてルーティングされていることを確認してください。一部のVPNクライアントではアプリごとのDNSを設定できますが、ほとんどはできません。あなたのクライアントができない場合は、スプリットトンネリングを完全に無効にしてフルトンネルを使用するのがより安全なデフォルトです — これはすべてのもの（すべてのDNSを含む）をVPN経由でルーティングします。ほとんどのユーザーにとって、スプリットトンネリングの利便性は漏洩リスクに見合いません。

IPv6漏洩の修正

最も信頼性の高い修正は、トンネル内でIPv6をサポートするVPNクライアントを使用すること（または少なくともトンネルがアクティブな場合にIPv6トラフィックをブロックする対応するIPv6ファイアウォールルールをインストールすること）です。クライアントを変更できない場合は、物理ネットワークインターフェースでIPv6を無効にしてください：Windowsではアダプタープロパティで；macOSではシステム設定 → ネットワーク → 詳細 → TCP/IPで。これは強引ですが（IPv6接続性が完全に失われます）、漏洩ベクターを排除します。

WebRTC漏洩の修正

Firefoxでは、about:configでmedia.peerconnection.enabledをfalseに設定してください。ChromeとEdgeでは、WebRTC Network LimiterやuBlock OriginのWebRTCブロックオプションのような拡張機能をインストールしてください。Safariはデフォルトでより保守的にWebRTCを処理しますが、一部の設定ではローカルIPが漏洩することがあります；Safari 17以降ではこれが大幅に改善されました。変更後にipleak.netでテストしてください。

「VPNを使う」だけでは漏洩がないことを保証しない理由

VPNに接続すると自動的にDNS漏洩が防止されるという一般的な思い込みがあります。そうではありません — 防止はVPNクライアントが一連のことを正しく行うかどうかにかかっています：システムDNSリゾルバの変更、ISP直接DNSをブロックするファイアウォールルールのインストール、IPv6の処理、Windows SMHNRの無効化（または同等のOSレベルバイパス機能）、そしてネットワーク変更（Wi-Fiローミング、スリープ/ウェイクサイクル）後も漏洩を再導入せずに機能し続けること。

適切に構築されたVPNクライアントはこれらすべてを自動的に行い、あなたが考える必要はありません。不十分なもの — またはOSの組み込みVPNプロファイルを追加の漏洩保護なしに使用する「無料」VPN — は一部しか行わず、漏洩ベクターを開いたままにします。あなたがどちらのカテゴリーにいるかを知る唯一の方法は、接続後に実際に漏洩テストを実行することです。テストがクリーンに戻ってきたら、心配するのをやめられます；漏洩が表示されたら、修正すべき具体的な問題があり、それが何かがわかります。

iOS、Android、Mac、WindowsでのDNS漏洩防止

iOS

iOSはNetworkExtensionフレームワークを通じてDNSを処理します。適切に構築されたVPNアプリは、トンネルがアクティブな間に使用されるカスタムリゾルバを指定するためにNEDNSSettingsオブジェクトを使用します。iOSはこれをOSレベルで強制します — アプリは明示的な許可なしに設定されたDNSをバイパスできません。iOSの主な漏洩ベクターはiCloud Private Relayです。VPNと並行して有効にすると、VPNのリゾルバの代わりにAppleのリゾルバを通じてDNSをルーティングすることがあります。プライバシーのためにVPNを使用している場合は、iCloud Private Relayを無効にして両者の競合を防いでください。iOS 14ではincludeAllNetworksフラグが追加され（キルスイッチ動作と合わせてよく使用されます）、システムレベルのDNSもトンネルを通じることが保証されます。

Android

AndroidのVpnService APIにより、VPNクライアントはすべてのトンネルされたトラフィックに適用されるDNSサーバーを指定できます。「常にオンのVPN」システム設定で「VPNなしの接続をブロック」を有効にすると、最も強力な保証が得られます — トンネルがアクティブでないと、アプリはDNSを解決できません。Androidはまたシステム全体のプライベートDNS（設定 → ネットワークとインターネット → プライベートDNS）をサポートし、すべてのDNSが選択したプロバイダーへのDNS-over-TLSを使用するよう強制します。常にオンのVPNとプライベートDNSを組み合わせることで、DNS漏洩に対するダブルの保護が得られます。

macOS

macOSはDNS設定を管理するためにscutilとSystem Configurationフレームワークを使用します。NetworkExtensionフレームワークを通じて実行されるVPNクライアントは、トンネルがアクティブな間に優先されるDNS設定をインストールできます。macOSの主な漏洩ベクターはブラウザレベルのDNS-over-HTTPSで、これはシステムリゾルバを完全にバイパスします — ブラウザレベルのDoHを無効にするか、VPNと同じリゾルバを指すよう設定してください。ターミナルでscutil --dnsを実行してアクティブなリゾルバを確認してください；トップ優先度セクションにはVPNのリゾルバのみが表示されるはずです。

Windows

WindowsはSmart Multi-Homed Name Resolutionにより、主要なOSの中で最大の漏洩面を持ちます。SMHNRを無効にする（上記）以外に、VPNの仮想アダプターが物理アダプターよりも高いメトリック優先度を持っていること、IPv6が無効化されているかまたは適切にトンネルされていること、そしてアプリが独自のDNS上書きで設定されていないことを確認してください。Windows 11ではDNS設定UIが改善されましたが、基本的な動作はWindows 10と似ています。ipconfig /allコマンドでインターフェースごとのアクティブなリゾルバを確認できます。

優れたVPNアプリが漏洩を防ぐために内部で行うこと

優れた設計のVPNクライアントは、DNS漏洩について考えさせません。接続プロセスの基本的な部分としてそれらを処理します。具体的には：

• 接続時にカスタムリゾルバを設定します。クライアントはOSに「接続中は、すべてのDNSクエリはこの特定のIPアドレスに送られます」と伝えます — 通常、トンネルを通じてのみ到達可能なVPNプロバイダー独自のリゾルバです。クライアントは切断時に以前のDNS設定も復元します。
• 直接DNSをブロックするファイアウォールルールをインストールします。アプリが独自にDNSサーバーに問い合わせようとしても（例：8.8.8.8へのハードコードされたクエリ）、ファイアウォールルールがUDPポート53の送信パケットをブロックします。デバイスから出られるDNSはトンネルを通じて流れるものだけです。
• トンネル内で暗号化DNS（DoTまたはDoH）を使用します。クエリがトンネル内に入った後でも、リゾルバからサーバーへのホップはDNS-over-TLS（RFC 7858）またはDNS-over-HTTPSで暗号化され、上流のオペレーターはクエリの内容を見られません。DNS-over-HTTPSとDNS-over-TLSの比較の記事では、2つのプロトコル間のトレードオフについて説明しています。
• IPv6を明示的に処理します。IPv6ルートはVPN経由でトンネルされる（推奨）か、IPv6フォールバックを防ぐためにファイアウォールでブロックされます。クライアントはIPv6ルーティングを設定されていないままにすることはありません。
• キルスイッチと組み合わせます。トンネルが一時的に切断された場合、キルスイッチはトンネルが再確立されるまでDNSを含むすべてのトラフィックをブロックします。これにより「トンネルが切断、DNS漏洩、トンネル復帰」という競合状態が防がれます。これについてはVPNキルスイッチとは何かで詳しく説明しています。
• 接続ごとにテストします。一部のクライアントは接続後に毎回組み込みの漏洩テストを実行し、異常があればユーザーに通知します。これはまれですが、最も強力なモデルです。

Casper's CloakはWireGuardトンネル内でのみ到達可能なカスタムDNSリゾルバを使用し、DNS-over-TLSによりエンドツーエンドで暗号化され、IPv6ルートは明示的にトンネルされ、Windows SMHNRはインストール時に無効化されます。脅威保護機能は同じリゾルバで既知の悪意あるドメインに対してDNSレベルのフィルタリングを実行するため、漏洩保護されているのと同じDNSが、フィッシングとマルウェアを積極的にブロックしています。このメカニズムはDNSレベルフィルタリングが実際にどのように機能するかの記事に記載されています。結合した効果：デフォルトで適切に設定され、4つの一般的な障害モードのいずれでも漏洩なし、そしてその上に積極的なフィルタリング。

基礎となるプロトコルの背景として、DNS-over-TLSのIETF仕様はRFC 7858に記載されており、TLSで保護されたチャネルでDNSを送信するための暗号化とトランスポート層の要件をカバーしています。これは、プライバシー重視の公開リゾルバ（Cloudflare、Quad9、NextDNS）がセキュアDNSエンドポイントに使用しているのと同じフレームワークです。

結論：DNS漏洩はVPNのプライバシーの約束が静かに失敗する最も一般的な方法です。テストが簡単で、通常は修正も容易であり、信頼するVPNは手動操作なしに漏洩テストをパスするはずです。あなたのVPNがそうでない場合、それはシグナルです — 設定ミスか、乗り換えを検討するかのどちらかです。