内部名を漏らさずに分割 DNS をテストする

内部名を公開リゾルバーに問い合わせると、名前が漏れるうえ、テストしたかったルールが飛ばされます。クエリは自分が管理していないサーバーに届き、応答はその名前を見るはずのなかった名前空間から返り、結果は分割 DNS が機能しているかどうかを何も語りません。分割 DNS をテストするとは、アプリケーションが実際に使うリゾルバー経路をテストすることです。その経路を選ぶのはオペレーティングシステムであり、VPN プロファイルのドメイン一覧であり、ときにブラウザーです。

名前を二つ選び、まず両方の答えを予測する

ネットワークの所有者に文書化された内部テスト名を一つ尋ね、組織について何も語らない普通の公開名を選びます。何かを実行する前に、それぞれ何が起きるべきかを書き留めます。内部名はトンネルのリゾルバーに届いて内部アドレスを返すべきであり、公開名はシステムが通常使うリゾルバーで解決されるべきです。この二つの予測こそがテストです。それがなければ、どんな結果も後から筋道を立てて説明できてしまいます。ペアは実行のたびに固定しておき、後で比較する意味を保ちます。

意図したルールではなく、実際に効いているルールを確認します。VPN 接続に付随するドメイン一覧が、どのサフィックスをどのリゾルバーへ送るかを決めており、その一覧の誤字はもっともらしく、しかし誤った分割を生みます。管理されたデバイスでは管理者の診断経路を使ってください。ローカルの上書きは次のチェックでポリシーにより戻されることがあります。

予測は同じチケット内で、観測した答えの隣に書きます。予測のないテストは失敗できず、失敗できないテストは何も教えてくれません。

アプリケーションが使う経路をテストし、自分が選んだ一つのサーバーを試さない

リゾルバーを明示的に指定するコマンドは、そのリゾルバーだけをテストし、それ以外は何もテストしません。内部サーバーが応答するかどうかは分かりますが、アプリケーションが名前をそこへ送っているかは分かりません。まず通常の経路でテストします。アプリケーションと同じように内部名を解決し、次に同じ方法で公開名を解決します。そのうえで初めて、特定のサーバーに問い合わせて挙動がどこで分かれるかを見つけます。

ブラウザーは話を複雑にします。安全な DNS の設定はシステムのリゾルバーを完全に迂回できるからです。独自の暗号化リゾルバーで構成されたブラウザーは分割を一切見ず、障害は壊れた VPN プロファイルのように見えます。トンネルを変える前にその設定を確認してください。

復元が論点なら、再接続後に検索を繰り返します。再接続前のキャッシュされた応答は、正しく復元された分割を実際より良くも悪くも見せることがあります。

成否だけでなく、応答のカテゴリーを記録する

四つのうち何が起きたのかを書き留めます。内部アドレス、公開アドレス、否定応答、タイムアウトのいずれかで、それぞれ意味が異なります。内部名に対する内部アドレスは期待どおりの成功です。内部名に対する公開アドレスは、クエリがトンネルの外へ出たことを示します。権威サーバーからの否定応答は、経路の障害ではなくレコードの欠落を指し、タイムアウトは到達性の問題、またはクエリを一度も受け取らなかったリゾルバーを示します。成功と失敗だけでは粗すぎて行動できません。

新しいクエリが見当たらない理由を解釈する前に、キャッシュに残った否定応答が存在しない名前とまったく同じに見えることを思い出してください。対応している手段で何かを消す前に応答を記録してください。最初の応答こそが証拠です。

推測せずに二つの分岐を解釈する

内部名が正しく解決し、それでもアプリケーションが失敗するなら、リゾルバーは役割を果たしており、次に疑うべきはリソース自体の経路と権限です。プライベート名が公開リゾルバーに届いたなら、その検索には分割ルールが適用されていないので、名前空間の所有者とともにドメイン一覧とブラウザーのポリシーを見直します。この二つの分岐は所有者が異なるため、どちらを見たかを記録することは、何かが壊れたと記録することより重要です。

共有する出力は構造を残したまま伏せます。どの名前空間か、どのルールか、どの応答カテゴリーか。リゾルバーの応答は内部アドレスやホスト名を含みうるので、チケットは両方の恒久的な置き場所になります。

そのうえで、観測した二つのカテゴリーを添え、名前を除いた結果を名前空間の所有者に渡します。それは一週間の推測ではなく、五分の会話です。