DNS を自社 VPN リゾルバ経由だけに限定する：段階的な手順

名前を入力した瞬間から、一つの名前解決を追いかけてください。ブラウザは OS に問い合わせ、OS はポリシーが選んだリゾルバに問い合わせ、クエリは何らかのインターフェースと何らかのトランスポートで端末を離れます。あなたの VPN 設計は、応答は特定のリゾルバから特定の経路で来るべきだと述べています。この二つの記述の間の隙間こそ、あなたが設定し、その後に強制するものです。

ステップ 1：リゾルバと経路に名前を付ける

ファイアウォールに触れる前に三つ書き留めます。リゾルバのアドレス、期待するプロトコルとポート、そしてクエリが出ていくべきインターフェースです。この一覧がなければ、ルールは通信に関する推測であり、決定の執行ではありません。VPN がアプリケーションのデータを運びながら DNS が別の取り決めに従うことはあり、それ自体は誤りではありません。誰もクライアントに別のことを伝えていないときに起きることです。

経路を明示的に名付けることが、設計と偶然の違いです。後で検証する材料にもなります。観測のたびに書かれた期待と比べられるからです。その一覧は変更チケットに残し、誰かの記憶に置かないでください。

ステップ 2：ポリシーが実際に住んでいる場所に置く

リゾルバの選択はクライアント側の仕事です。OS のネットワーク設定、VPN クライアント自身の設定、あるいは管理されたブラウザポリシーです。まずそこに、プラットフォームが支える仕組みで設定します。ファイアウォールは、一度も知らされていないリゾルバをクライアントに選ばせることはできないからです。分割トンネルのクライアントでは、どのドメインが内部リゾルバへ行くかを明示します。管理された端末群では、ブラウザポリシーが DoH の唯一の手段になることがよくあります。ブラウザはシステム設定とは独立に独自の暗号化リゾルバを選べるからです。

これを飛ばしてファイアウォールへ直行すると、正しいリゾルバを許可するルールと、それを決して使わないクライアントが手に入ります。ルールは正しく見え、リゾルバのログは空のままで、切り分けに迷う組み合わせです。まず選択を設定し、その後に強制してください。

ステップ 3：経路を狭く強制する

次に許可する経路へのネットワーク許可を追加します。リゾルバのアドレス、プロトコルとポート、そして出ていくべきインターフェースです。すべての外向き DNS を許可するのではなく、ルールをそのリゾルバに限定してください。以下の三つの経路は現代のクライアントが取り得るもので、ポート 53 のルールが覆うのは最初の一つだけです。

DoH と DoT を遮断することは正当です。ポート 53 のルールがすでに遮断したと決めてかかることは正当ではありません。DoH を使うブラウザは、あなたのルールが一度も記述していない経路で名前を解決します。独自のリゾルバを同梱するアプリケーションも同じです。許可する経路と拒否する経路をそれぞれ書き出してください。経路に名前を付けないルールは、その経路について決めていません。

ステップ 4：プライベート名と公開名を追う

分割 DNS は意図的にプライベートな名前空間だけを内部リゾルバへ送り、公開名は別の場所へ送ります。したがって設計に複数のリゾルバがあることは漏えいではありません。漏えいとは、あなたのリゾルバへ行くはずのクエリが別の場所へ届くこと、あるいは意図した経路に到達できずクライアントが黙って後退することです。探すべきはこの二つです。意図したポリシーの下で内部名と公開名を一つずつ追い、どちらのリゾルバが答えたかを記録します。

あなたのリゾルバを報告するテストサイトは手がかりであって証拠ではありません。そこへ届いたクエリしか見えないからです。実際にどの経路を通ったかを知る必要があるときは、クライアント側でクエリを捕捉し、二つの観測を比べてください。食い違ったとき、誰も記録していない後退が見つかったことになります。

リゾルバのアドレスが正しいのに到達できない場合、問題はポリシーではなく 経路制御かフィルタリング にあります。そのアドレスへクエリを追跡し、リゾルバの設定を変える前に、応答が期待したインターフェースで戻ることを確認してください。

ステップ 5：戻る道を残す

ゲートウェイの DNS アクセスを厳しくする前に、名前解決に依存しない復旧手段を確認します。壊れたリゾルバはあらゆる修復ツールを遠ざけ、変更を巻き戻すための道具まで届きにくくします。新しいポリシーが証明されるまで、ローカルコンソールか帯域外の経路 を開いたままにしてください。ポリシーが再接続を耐えた後にだけ外します。

再接続やブラウザポリシーの更新の後は、実効状態をもう一度確認します。どちらもあなたのルールを変えずにリゾルバを変えられるからです。要件はクエリに対する既知の受信先と保護された経路であり、一枚のスクリーンショットにある安心させるリゾルバ表示ではありません。RFC 8484 の DNS over HTTPS 仕様 は、ポートのルールが見ていない暗号化経路の参照先です。