分割 DNS と VPN：ドメイン規則は IP ルートではない

分割 DNS は名前でリゾルバを選び、回答には依然としてルートが必要です。ドメイン規則と経路を別々に、実際に動かしているプラットフォームで試してください。

ノート PC はトンネル経由で intranet.corp を解決する一方、gitlab.com はプロバイダのリゾルバに向かうままで、これは設計どおりに動いている状態です。これを生んだのは二つの別個の判断です。名前の一致規則がリゾルバを選び、ルートが回答を運び戻しました。どちらか一方が壊れれば、ブラウザには外から見れば同じ失敗が表示されます。分割 DNS の報告のほとんどは、最初の失敗の証拠を引きながら二番目の失敗を説明しています。

二つの半分は別々の場所にあり、ふつうは別の人が編集します。一つは VPN プロファイルに付く DNS ポリシーで、もう一つはトンネルが入れるか入れないルートです。どちらの半分が実際に動いたのかを誰も確定しないと、デバッグは止まります。

一つの要求に隠れた二つの判断

名前の半分はルートではなくポリシーオブジェクトです。Windows では VPN プロファイル上の名前解決ポリシー、Apple のプラットフォームでは DNS 設定オブジェクト上の一致ドメインの集合、Linux ではルーティングドメイン、分割リゾルバ行、または名前サービスの切り替え順です。経路の半分はトンネルか手作業で入れられる普通のルーティングで、ホスト名が何かは知りません。接尾辞を許可するプロファイルは誰が答えるかを決めるだけで、回答を到達可能にはしません。

簡単な症状テストが両者を分けます。名前をアドレスに置き換えてください。アドレスが通れば経路は正常で規則が誤りです。アドレスも失敗すれば、規則は正しく経路が欠けている可能性があります。

各プラットフォームが同じ名前規則をどう表すか

意図は同じでフィールド名は違います。あるクライアントから別のクライアントへコピーした例はきれいに解析され、決して一致しません。三つの形は次のとおりです。

PlatformWhere the rule livesWhat usually breaks
Windowsname-resolution policy on the VPN profileprecedence against the interface suffix list
Apple platformsmatch domains on the DNS settings objectdomains attached to the wrong extension
Linuxrouting domain, split resolver, nsswitch orderthe suffix written the wrong way round

一致ドメインやルーティングドメインは接尾辞のテストなので、intranet.corp は git.intranet.corp を覆い、corp.intranet は覆いません。これを逆にするのが設定全体で最も多い誤りです。Windows は対応付けをプロファイルに付いた名前解決ポリシーとして持ち、インターフェースがすでに持っていた接尾辞リストに対して独自の優先順位を持ちます。Apple のプラットフォームは一致ドメインをネットワーク拡張の DNS 設定オブジェクトに付け、システムはスコープ付きリゾルバごとに適用します。これらの形はいずれもルートではなく、到達できないアドレスを到達可能にはできません。Windows の名前解決ポリシーのリファレンスは、そのプラットフォームのフィールド名と優先順位の規則を並べており、Apple や systemd の文書が使うものとは違います。

正しい回答にも経路が必要

リゾルバの回答はアドレスにすぎません。アプリケーションはそこへ到達しなければなりません。分割トンネルの設計はよく 10.20.0.0/16 を押し出し、既定ルートを保留するので、内部名は解決しても接続がそのあと止まります。逆の場合は同じくらいよくあります。ルートはあり、公開リゾルバが社内名に NXDOMAIN を返し、障害はルーティング問題として記録されます。先に経路を試すと、決して解決しない名前のルートを見つめることになります。

どちらの半分も覆わない第三の関門もあります。ゲートウェイの ACL、ファイアウォール規則、クライアント側のポリシーは、両方の判断が正しくても接続を落とせます。名前が解決し、ルートがあり、それでも接続がタイムアウトするなら、DNS のテストをやめてください。

名前と経路を決まった順序で試す

順序を決めて守らないと、直近に失敗した手順を追いかけることになります。文書化された完全な内部名を解決し、回答がルート表で運べるアドレスであることを確認し、公開名で繰り返してトンネルがすべてを捕まえていないことを示します。systemd のホストでは、問い合わせとリゾルバのルーティングドメインはコマンド一つ分の距離です。

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows クライアントは同じ二つの問いを別のコマンドレットで尋ね、二つ目はシステムが実際に使うインターフェースを報告します。

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

検索がアドレスを返し、経路の確認が物理インターフェースを指すなら、名前の規則は働き、ルートは働いていません。短い名前が失敗して完全な名前が解決するなら、誤っているのは接尾辞リストで、リゾルバではありません。

比較がたいてい誤る場所

第一の誤りは、無関係な公開リゾルバに社内名を尋ね、その拒否を VPN の証拠として読むことです。第二は、公開検索が通ることがトンネルのリゾルバ経路を証明するとみなすことです。第三は、分割トンネルと分割 DNS を一つの設計判断として扱うことです。配備は一方で正しく、他方で壊れていることがあります。どの誤りも、非難された部分を一度も試していないテストから自信ある結論を生みます。

独自の安全な DNS を持つブラウザはシステム規則を迂回できます。だから一方のブラウザが失敗し他方が成功しても矛盾ではありません。答えたリゾルバを比べ、不満を言ったブラウザを比べないでください。

両方の半分が見えるようになれば、残る問いは技術ではなく方針の問いです。どの名前空間が組織に属し、各回答を誰が持ち、そのうちどれが端末を離れるべきかを、次に規則に触れる人が必要とするのでプロファイルの隣に書き留めてください。

関連記事