サイトを開くたびに、端末はドメイン名をIPアドレスに変換してもらうため、解決サーバー（リゾルバ）へ問い合わせています。この問い合わせは「これからどこへ行くか」を平文で記録したものであり、既定ではネットワーク側から渡された解決サーバー、つまり通常は契約中のプロバイダのものへ送られます。

DNSリークとは、その問い合わせが意図しない先へ流れてしまうことです。よくあるのは、独自の解決サーバーや暗号化された解決サーバーを使う設定にしてあるのに、構造的な理由のどれかによって、一部あるいはすべての問い合わせがプロバイダへ送られ続けている端末です。目に見えて壊れるものは何もなく、だからこそリークは何年も気づかれないまま続きます。

DNSは実際に何を漏らしているのか？

ドメイン名、時刻、そして送信元です。これだけあれば閲覧セッションは再構成できてしまいます。

従来のDNSは53番ポート上を暗号化なしで流れます。自分と解決サーバーのあいだに位置する者は誰でも問い合わせを読めますし、解決サーバー自身は、その全部を自分の接続に紐づいたものとして把握します。個別のページまでは見えませんが、たいていの場合、機微なのはドメイン名のほうです。

暗号化が変えるのは、この記録を誰が持つかであって、記録が残るかどうかではありません。

経路 暗号化 問い合わせが見える相手
平文DNS（53番ポート） なし 接続中のネットワーク、プロバイダ、解決サーバー
DNS over TLS（DoT、853番ポート） あり 自分で選んだ解決サーバー
DNS over HTTPS（DoH、443番ポート） あり 自分で選んだ解決サーバー。ネットワーク側からはウェブ通信と見分けにくい
DNSSEC なし —— 認証のための仕組み 平文DNSと同じ。応答が本物だと証明するだけで、内容は隠しません

いちばん誤解されているのがDNSSECです。これは応答に署名して偽造を防ぐ仕組みであり、秘匿性はまったく提供しません。

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

構造的な原因は6つで、ほぼすべてがこのどれかです。

原因 仕組み
経路の分割 一部の通信だけがトンネルを通り、DNSは既定のインターフェースへ出ていく
IPv6が通っていない トンネルがIPv4しか扱わないため、IPv6の問い合わせがプロバイダ経路へ流れる
OSの並列解決 Windowsは全インターフェースへ同時に問い合わせ、最初に返った答えを採用することがある
ブラウザ側のDoH ブラウザがシステム設定とは独立に名前解決する。方向はどちらにも起こりうる
ルーターによる上書き ルーターがDHCPで自身の解決サーバーを強制する、または53番ポートを横取りする
キャプティブポータル ホテルや空港のネットワークがDNSを乗っ取り、ログインページへ誘導する

ブラウザの件は、両方向に効くので明示しておく価値があります。独自のDoH設定を持つブラウザは、丁寧に設定したシステム側の解決サーバーを迂回してしまうことがありますし、逆に正しく設定されたブラウザは、そのブラウザの外側では全部漏れ続けているという事実を覆い隠すこともあります。片方だけを確かめてもう片方も大丈夫だと思い込むのが、検査でいちばんよくある誤りです。

どう確認すればいいのか？

各層を別々に検査してください。層ごとに答えが食い違うことがあるからです。

OS —— 設定されている解決サーバーを見る：

システム コマンド
macOS scutil --dns | grep nameserver
Windows Get-DnsClientServerAddress
Linux（systemd-resolved） resolvectl status
Linux（汎用） cat /etc/resolv.conf

実際に応答したのはどれか —— 設定と挙動は別物です。

dig +short whoami.akamai.net を実行すると、自分の代わりに名前解決を行った解決サーバーのIPアドレスが返ります。これを、自分が想定していた解決サーバーと突き合わせてください。

ブラウザ層： ブラウザのセキュアDNS設定を開き、有効になっているか、どの事業者が選ばれているかを確認します。そのうえで、同じブラウザでDNSリークテストのページを読み込みます。コマンドラインの検査と違う解決サーバーが報告されるなら、ブラウザは独立に名前解決しています。

IPv6： IPv6のみの問い合わせで同じ確認を繰り返します。IPv4しか通していないトンネルは、部分的なリークの原因として群を抜いて多いものです。

結果はどう読めばいいのか？

「良いアドレス」の一覧と照らすのではなく、解決サーバーの持ち主が自分の想定と一致するかで読みます。

観測されたもの 読み方
別のものを設定したのに、解決サーバーがプロバイダのものになっている リーク
解決サーバーが複数あり、うち1つがプロバイダのもの 部分的なリーク —— 問い合わせが分かれています
IPv4は想定どおりだが、IPv6はプロバイダのもの IPv6のリーク
ブラウザとシステムで報告される解決サーバーが違う 必ずしもリークではありませんが、検証すべき経路が2本あるということ
解決サーバーが想定外の国にある 珍しくありません —— エニーキャストの解決サーバーは最寄りの拠点から応答します
解決サーバーがルーターのプライベートアドレス 判定不能。ルーターは上流へ転送するので、ルーター自身の設定を確認してください

最後の行は、家庭内ネットワークでよく人を引っかけます。192.168.1.1 という結果から分かるのは、ルーターが応答したということだけです。そのルーターがどこへ転送しているかは別の問いで、答えはルーターのWAN設定やDNS設定にあります。

これを直したところで、どこまで守れるのか？

DNSリークを直すと、どのドメインを調べたかを誰が知るかが変わります。訪問そのものが秘密になるわけではなく、この点を大げさに語ることが、この話題がいちばん歪められる原因です。

名前が解決されたあと、端末はそのIPアドレスへ接続を張ります。経路上の観測者には宛先アドレスが見えますし、Encrypted Client Helloが両端で使われていないかぎり、たいていのTLS接続ではサーバー名がハンドシェイクの中を暗号化されずに流れます。この2つの手がかりは、どちらもDNSとは無関係にサイトを特定します。

ですから、正直にまとめると範囲は狭いものの、実質はあります。自分で選んだ解決サーバーへの暗号化DNSは、訪れたドメインの平文の一覧を、手元のネットワークとプロバイダのログから取り除き、代わりにその一覧を解決サーバーの運営者へ渡します。信頼をなくすのではなく、移し替えているだけです。だからこそ、誰がその解決サーバーを運営していて、何を記録しているのかが、本当に問うべきことになります。

関連する疑問