短い内部名が VPN で失敗する理由：決して見えない検索サフィックス

短い名前は社内では機能していたのに VPN では失敗し、一方、完全名は問題なく解決します。壊れているものはありません。intranet のような裸の名前は完全な名前ではありません。クライアントは検索リストからサフィックスを付けて結果を問い合わせます。VPN プロファイルがそのサフィックスを提供しなければ、見慣れた短い形は存在しなくなります。

これが神話のすべてです。DNS が壊れたのではなく、検索ポリシーが変わったのです。

裸の名前は名前ではない

ラベルを一つ入力すると、リゾルバーは何を問い合わせるか決めなければなりません。与えられた名前をそのまま試し、次に検索リストの項目を一つずつ追加して、何かが応答するまで繰り返します。Linux では resolv.conf が search と ndots の設定でその順序を制御します。Windows ではサフィックスリストと名前解決ポリシーが同じ役割を果たします。サフィックスを外せば、リゾルバーには付け足すものがありません。

つまり、動く短い名前はポリシーの証拠であり、健全な DNS サーバーの証拠ではありません。

サフィックスリストとリゾルバーアドレスがそれぞれ担うもの

この二つは絶えず混同されます。リゾルバーアドレスは誰に問い合わせるかを示し、サフィックスリストはどの名前について問い合わせるかを示します。VPN はサフィックスなしのプライベートリゾルバーを渡すことも、間違ったリゾルバーと一緒にサフィックスを渡すこともあります。その失敗のうち DNS 障害に見えるのは片方だけです。

間違った方を直すとサポートの時間枠を無駄にするため、別々に確認してください。

三つの症状、三つの異なる担当。

まず完全名を試す

推測ではなく、管理者が文書化した完全修飾名を尋ねてください。動く FQDN はリゾルバーに到達でき、レコードが存在することを証明し、一度の問い合わせで可能な原因の半分を排除します。どのサーバーが応答したかを示すツールを使い、キャッシュされた結果を読まないようにしてください。

テストは非公開にしてください。内部の変種を公開リゾルバーへ送ることは、名前を露出し、誰も意図しなかったポリシーを試すことになります。

修正はどこに属するか

所有するプロファイル、またはそれを生成する管理システムを修正してください。ローカルのリゾルバー設定を手で編集しても、再接続で消えるか、マシンが参加するすべてのネットワークに適用され、後者の方が悪化します。

Windows では、覚えているチェックボックスではなく有効なポリシーを調べてください。Get-DnsClientNrptPolicy は実際に効いている名前解決ルールを表示します。

macOS では、scutil --dns がスコープ付きインターフェースごとのリゾルバー設定を、VPN が押し込んだ検索ドメインを含めて出力します。

Linux では、VPN クライアントが書き換えていないか確かめつつ、/etc/resolv.conf の search 行を読んでください。ファイルが管理されているなら、レンダリングされたファイルではなく信頼できる情報源を編集してください。以前のネットワークから残った古い search 行はよくある原因です。

プロファイルと一緒に残すもの

修正した完全名、サフィックスリスト、リゾルバーアドレスをクライアントプロファイルのそばに保存してください。intranet サイトが落ちていると報告する次の人は、白紙から始める代わりに三つの既知の値を比較できます。

そして短い形だけが失敗するなら、チケットにそう書いてください。その一文がリゾルバーチームの午後を救います。