DNS漏えいテスト：リゾルバ名は経路ではない

VPN利用者にとって正しいDNSとされる構成は三つあります。事業者のリゾルバへの問い合わせ、自分で選んだ暗号化リゾルバへの問い合わせ、そして社内名を組織へ送るsplit DNSです。漏えいテストが報告するのは一つのリゾルバであり、その一つのラベルから実際の構成は分かりません。まず意図した方針を決め、それに対してテストしてください。そうしなければ、数字と感覚を比べることになります。

結果を読む前に、望んでいたものを決める

方針を一文で述べてください。すべての名前をVPNのリゾルバへ送る、すべての名前を選んだ暗号化リゾルバへ送る、内部名を組織へ送るsplit DNS、のいずれかです。どれも利用者によっては正当化でき、それぞれ異なる期待結果を生みます。その一文がなければ、フォーラム投稿のスクリーンショットと違う結果はどれも不安に見えます。最初のテストの前に方針を書き留めてください。

方針を定める前に実行したテストは何も測りません。基準点のないリゾルバ名を出すだけです。

リゾルバ名は経路も受信者も証明しない

重要な問いは二つです。誰が問い合わせを受け取ったのか、どの経路がそれを運んだのか。設定画面に事業者のアドレスが表示されていても、第三者リゾルバへはトンネル経由で到達できます。漏えいテストのページのラベルは観測者の見え方を示すもので、あなたのルーティングテーブルではありません。

ブラウザは独自の暗号化DNSを使いながら、サイトの通信はトンネルを通ることがあります。またキャッシュされた応答があれば、新たな照会なしにページが読み込まれます。だから公開IPの結果はDNSについて何も語りません。DoHとDoTはリゾルバまでの問い合わせを保護しますが、そのリゾルバは名前を見ています。

resolvectl status
resolvectl query example.com
dig +short example.com

split DNSでは複数のリゾルバが正しい

組織は内部名を自社のDNSへ送り、それ以外を別の場所へ送ることがあります。したがって複数のリゾルバを列挙するテストは、障害ではなく意図した方針を表している場合があります。何かを無効にする前に、観測された集合を文書化されたsplit DNSの規則と比較してください。テストページをきれいに見せるために内部リゾルバを切ると、プライベート名が壊れます。

スプリットトンネリングとsplit DNSは別の選択です。一方はパケットを経路制御し、他方は問い合わせを経路制御します。トンネルの経路を変えても名前の照会は動かず、リゾルバを変えてもウェブサイトの経路は直りません。IPv6は三つ目の問いです。意図しないIPv6接続が自動的にDNS漏えいになるわけではありません。

結果を調査に変える

テストの前に、意図した方針とブラウザのセキュアDNS設定を記録してください。トンネルを有効にしたままテストを実行し、挙げられたリゾルバをすべて記録し、単一の期待アドレスではなく方針と集合を比較してください。

症状が再接続時に現れるなら、再接続後に繰り返してください。接続時に適用された方針は後から失われることがあります。設定を推測せず、クライアントの文書を内部DNSの例外に使ってください。

見つけた不一致を直してください。ブラウザの選択、VPNのDNS設定、split DNSの規則のいずれかです。トンネルが失敗したときに問い合わせを止める必要があるなら、kill switchは別の設定であり、DNS設定だけでは提供されません。暗号化リゾルバが何を隠し何を隠さないかを説明する必要があるとき、RFC 8484の仕様が役立ちます。