VPNのDNSとブラウザのDoH：漏えいテストが教えないこと

漏えいテストのページはDNSは問題ないと言い、ブラウザのバッジは安全だと言い、社内ウィキはそれでも読み込まれない。三つは同時に正しいことがあり得る。リゾルバーのアドレスは、それを選んだポリシーや問い合わせが通った経路とは同じものではないからだ。人がDNS漏えいと呼ぶものは、実は一つの問いである。どのリゾルバーが名前を受け取ったのか、そしてその選択は意図的だったのか。これを整理するには三つの確認が必要で、設定を変えるのは最後の一つだけだ。

神話その一：バッジがリゾルバーを示す

漏えいテストはプローブ名を解決し、応答したアドレスを報告する。それはそのリゾルバーを選んだポリシーを報告しないし、問い合わせがDNS over HTTPSで包まれている場合、経路上の中間装置は名前をまったく見られない。まったく異なる二台のマシンが同じ安心のバッジを出す。一方ではVPNが10.8.0.1を押し込みブラウザがそれを使い、もう一方ではブラウザがシステムの一覧を無視して、名前をトンネル経由で独自の暗号化プロバイダーへ送っている。

この違いは、プライベート名が解決に失敗した瞬間に効いてくる。前者ではVPNのリゾルバーが社内ゾーンに応答するが、後者ではブラウザが一度も尋ねていないので、短いホスト名は解決されず、故障は壊れたVPNのように見える。この確認は別の漏えいテストではなく、一つのリゾルバーしか知らない名前への問い合わせである。

神話その二：ブラウザはトンネルを出る

DNSはアドレスを選び、ルーティングは接続を運ぶ。これは別々の層だ。公開DoHプロバイダーへ送られる問い合わせも、依然としてルーティング可能なアドレスへのTCPポート443である。ルートテーブルがデフォルトルートをトンネルへ送っているなら、その問い合わせもトンネルを通る。リゾルバーのブランドが経路を決めるのではない。

ブラウザのDoHが変えるのは、名前の受け取り手だ。それは本当のプライバシー判断であり、本当のポリシー判断でもあるが、ルーティングの回避ではない。名前をVPN事業者のもとに留めたいという要件なら、他人への暗号化された問い合わせはその要件を満たさない。それでも実際の接続にはトンネルを使っている。

神話その三：どのVPNもどのブラウザも上書きする

ブラウザの安全なDNSにはモードがあり、スイッチではない。オフ、フォールバック付きの既定プロバイダー、カスタムテンプレート、あるいはOSや組織が強制するポリシーだ。断続的な報告を生むのはフォールバックの場合である。暗号化されたエンドポイントに到達できないと、ブラウザはシステムのリゾルバーへ戻ることがある。そのため同じノートPCが月曜にはプライベート名を正しく解決し、火曜には解決しない。

同時に、ほとんどのVPNクライアントは接続時にシステムのリゾルバーを設定し、切断時に元へ戻す。カスタムの暗号化リゾルバーを持つブラウザは、その復元をまったく観察しない。だから同じプロファイルが二台のノートPCで違う振る舞いをし、ブラウザが今も別の相手に尋ねているのにresolv.confは正しく見える。

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

接続中にこれらを実行し、各リゾルバーがどのドメインを主張するかを記録し、ブラウザが自分のモードについて報告する内容と比べる。MozillaのDoHのドキュメントは、ブラウザの既定とフォールバックの動作がどうなるべきかの妥当な説明である。

判断の入力は三つあり、一つではない

プライベート名、事業者への信頼、到達可能性が正しい配置を決める。VPNのリゾルバーしか知らない名前は分割DNSを強制する。プライベートなサフィックスは押し込まれたリゾルバーへ行き、それ以外は公開名のために選んだポリシーに従う。事業者への信頼は、公開名もそのリゾルバーへ送るか別サービスへ送るかを決める。到達可能性は、選んだ暗号化リゾルバーがこのネットワークでそもそも使えるかを決める。

これらの行のどれも普遍的な推奨ではない。VPNが運営するリゾルバーは観察をその事業者に集中させる。別のサービスは問い合わせされた名前の受け取り手をさらに増やす。どちらの配置も、ポリシーを読まない限り保持について何も証明しない。

判断はプロファイルごとに書き留める。これらの設定はずれていくからだ。先月リゾルバーを押し込んだプロファイルが今日は何も押し込まないこともあり、ブラウザは今も応答する古いカスタムエンドポイントを喜んで保持する。メモに書くべきは、リゾルバーのアドレス、それが持つサフィックス、ブラウザのモードであり、サービスのブランドではない。

設定したつもりのポリシーを試す

バッジではなく名前で試す。公開名とプライベート名をシステムのリゾルバーで解決し、次に使うつもりのモードでブラウザ自身の安全なDNS設定を使って繰り返す。プライベート名がブラウザだけで失敗するなら、VPNの設定を一つも触らずに受け取り手の不一致を見つけたことになる。

その後に再接続して復元を確認する。引き継ぎの不具合はそこに住んでいるから、切断して前のリゾルバーが戻ったことを確認し、再接続して押し込まれた方が戻ったことを確認する。最後に、管理ポリシーのあるブラウザがあれば試す。そのモードは変更を完全に拒否し、前のリゾルバーを静かに保持することがある。

名前空間の問いから始めれば、そのほとんどを避けられる。マシンが社内名に到達する必要があるなら、ブラウザの暗号化リゾルバーは公開側だけの判断であり、プライベート側はVPNが押し込んだものに委ねられる。