VPNが押し出す三つのDNSサーバー：どれが応答するのか

接続後に設定ページを開くと、DNSアドレスが三つ並んでいる。監査の問いは、そのうちどれが最後の問い合わせを処理したかだ。数だけでは何も答えられない。クライアントのプッシュ、物理インターフェース、ドメインごとのポリシーが同じ画面に書き込むからだ。これらの項目はそれぞれ異なるスコープを持ち、応答者を決めるのは位置ではなくスコープである。まず発生源を分け、次に必要な名前を持つものを試そう。

一覧がプロファイルより長くなる理由

VPNクライアントはトンネルリンク用のリゾルバーアドレスをプッシュし、OSはそれを物理インターフェースが既に持っていたものの隣に保持する。ルーター、企業のDHCPリース、二つ目のVPN、ドメインごとのポリシーがそれぞれ独自の項目を追加する。したがって画面上の三つのアドレスは、一つの仕事に対する三人の候補ではなく、三つのスコープを意味することがある。数を漏えいの証拠と読むのが、この監査の最初の誤りだ。

一つのインターフェース内では、クライアントは実際にサーバーを順番に試すので、順序付きの一覧は無意味ではない。キューではないのは統合ビューであり、プロファイル、物理リンク、ドメインごとのルールの項目が単一の順位付けなしに並ぶ。この区別が、何を試すかを決める。順序は一つのスコープ内の挙動を説明し、スコープはそれ以外のすべてを説明する。

暗号化DNSはアプリケーションの内側から絵を崩す。独自のDNS-over-HTTPSリゾルバーを持つブラウザーやチャットクライアントは、OSの一覧を完全に迂回して問い合わせを送るので、設定ページのアドレスはアプリが一度も生成しなかったトラフィックを説明している。名前が間違って出たことをプロファイルのせいにする前に、アプリ自身のリゾルバー設定を確認しよう。

三つの確認がそれぞれ何を語るか

各発生源は異なる場所に痕跡を残し、単一のコマンドですべてを示すことはできない。設定ページの隣に置いておく価値がある対応表はこれだ：

systemd-resolvedを使うシステムではresolvectl statusが正であり、リンクごとのDNSをルーティングドメインとともに報告する。macOSはscutil --dnsで応答し、スコープ付きリゾルバーを試行順に一覧する。Windowsは二つの半分に分ける。インターフェースごとのサーバーにはGet-DnsClientServerAddress、サフィックス規則にはGet-DnsClientNrptPolicyだ。実際に使われているリゾルバーに対応するコマンドを実行しよう。コンテナランタイムとデスクトップのリゾルバーが同居するマシンには複数入っていることがある。

あなたのゾーンに応答できないバックアップリゾルバー

二つ目の項目は通常、可用性のためにある。可用性はバックアップが名前を知っている場合にしか働かない。公開リゾルバーに社内ホスト名を尋ねればNXDOMAINが返るか、無関係な検索ドメインからのワイルドカード応答が返る。誰も確認していないフェイルオーバーは、まさに必要な瞬間に障害を起こす。

Split DNSはそれを防ぐためにある。会社のサフィックスはゾーンを持つリゾルバーへ行き、公開名は既定の経路に残る。設計は堅牢で、サフィックス一覧が完全であることに依存する。MicrosoftはWindowsでこれを動かすサフィックスごとのリゾルバーポリシーを文書化しており、同じ考え方はsystemd-resolvedのルーティングドメインやmacOSのスコープ付きリゾルバーとして現れる。

バックアップが応答してよいゾーンと、ポリシーにあるサフィックスを比較しよう。その比較は、トンネル変更後に社内サイトが解決しなくなったと利用者が報告する前に、隙間を見つける。

ポリシーを通して問い合わせ、迂回しない

サーバーへの直接問い合わせはポリシーを迂回し、そのサーバーが言うことだけを報告するので、OSのリゾルバーを通して問い合わせよう。二つの答えの間の隙間こそが要点だ：

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

システムの問い合わせがプライベートアドレスを返し、直接の問い合わせがNXDOMAINを返すなら、ポリシーは機能しており、弱点はバックアップだ。両方が同じ公開応答を返すなら、名前は意図したスコープの外で解決されており、サフィックス一覧を見るべきだ。両方の出力を保存しよう。リゾルバーの議論は、設定ページのスクリーンショットより二行で早く決着する。

誰も試していないフォールバックは前提にすぎないので、次に失敗経路を試そう。優先リゾルバーを一回の問い合わせだけブラックホールにして、どのアドレスが返るか見る：

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

問い合わせが終わったらすぐにそのルートを削除しないと、次の人が謎を引き継ぐ。その時間内に社内名がまだ解決するなら、意図したスコープの外の何かが応答している。代わりにタイムアウトするなら、フォールバックが無いか正しくスコープされている。どちらだったかはリゾルバー自身のログが教えてくれる。

決める：保持、スコープ限定、削除

必要な名前空間に応答し、プロファイルの下で到達可能なままなら、二つ目のリゾルバーを保持する。一つのサフィックスだけを見るべきならスコープを限定し、スコープも文書化された目的もないなら削除する。仕事のない項目は利益のない将来の漏えいであり、ベンダーの既定値は目的ではない。

結果を四つの列で記録する。サフィックス、リゾルバー、インターフェース、所有者だ。その一行はどのスクリーンショットより速く次の監査の問いに答え、一覧を静かに並べ替えるクライアント更新にも耐える。