Split-DNS のキャプチャ：各観測がどこで取られたかを示す

二人が同じ Split-DNS の問題を調べ、別々の resolver アドレスを得る。一人は検索ツールを使い、一人はアダプター上でパケットを取得し、三人目はクライアント自身の診断を読んだ。誰も嘘をついておらず、誰も同じ段階を説明していない。観測点を名指しすれば、矛盾は地図に変わる。

ひとつの検索、いくつもの観測点

ひとつの内部名について、見るべき場所は少なくとも五つある。アプリケーションとそれが呼ぶ resolver API、クライアント上の有効なドメインポリシー、アダプターまたはフィルターでの取得、管理されたゲートウェイ境界、そして実際にクエリを受け取る resolver である。

それぞれが別の問いに答え、どれひとつだけではクエリがどこへ行ったかを証明できない。

アダプター上の取得はパケットを示すが、意図は示さない。クライアントがどの resolver を選んだかは分からず、空の取得はパケットが捨てられたのではなく、キャッシュされた応答や別の resolver API を意味する場合がある。各観測を一つの段階についての証拠として扱う。次に、その段階をつないで経路にする。

クライアントのフィルターはアプリと配線の間に位置する

Split-DNS を使う VPN クライアントは、パケットが端末を出る前にドメイン照合を適用する。トンネル側のサフィックスにある名前は内部 resolver へ、それ以外はすべてローカル resolver へ送られる。フィルターはポリシーであり、ポリシーはプラットフォームやクライアントのバージョンによって異なりうる。

Cisco の Secure Client の Split-DNS ガイダンス はドメイン照合と Windows のフィルターを扱い、アプリがネイティブの resolver API を使うときに見えるものと、nslookup のようなツールが見えるものを分けている。その区別こそが要点である。

有効なプロファイルと、ごく普通のアプリケーション検索から始める。特定のサーバーを名指しするテストは意図的な寄り道である。クライアント自身の診断でそれを説明し、受け入れ基準にしてはならない。

nslookup はアプリとは別の経路を通る

nslookup は独自の DNS クエリを組み立て、オペレーティングシステムの resolver ポリシーを迂回できる。そのため特定のサーバーに特定の問いを投げるには便利だが、アプリが何を経験するかを試すには誤解を招く道具になる。

Windows では、名前解決ポリシーの表がどのサフィックスにどのサーバーを使うかを決める。それを読めばアプリが従うポリシーが分かり、多くの場合それが欠けている部品である。

ポリシーを読み、次に同じ問いを通常の resolver 経由で投げる：

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

暗号化された resolver はクエリを隠すが、接続は隠さない

独自の DNS-over-HTTPS resolver を持つブラウザーはまったく別の事例である。クエリは TLS の内側を通って出ていくため、パケット取得では resolver アドレスへの接続は見えても、問い合わせている名前は見えない。

まずブラウザーの管理ポリシーを把握し、それをオペレーティングシステムの検索と比較する。独自の resolver を選べるブラウザーは、Split-DNS ポリシーをまったく見ないかもしれない。

同じ注意は、独自の resolver を同梱するあらゆるクライアントに当てはまる。遠隔の接続を特定する取得は、クエリ名についての証拠ではない。名前が必要なら、resolver 自身のログかアプリケーションの診断から取得し、適用されるプライバシー規則に従う。

ラベル付きのテストと比較する

テスト用に承認された内部名を選び、さらに機微な意味を持たない公開名を選ぶ。それぞれについて、時刻、レコード種別、応答、期待したポリシーを記録する。

許される場所では、resolver の受信をクライアントまたはゲートウェイの狭い観測と比較する：

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

比較を作るためだけに、私的な名前を無関係の公開 resolver へ決して送らず、共有するものはすべて伏せる。最後に、正しい DNS 応答とその後に続くサービス接続を切り分ける。解決された私的なアドレスには、依然として経路とアプリケーションの許可が必要である。