VPN 越しの BIND:条件付きフォワードか stub ゾーンか
VPN 経由でひとつのプライベートゾーンを解決する三つの方法と、それぞれが適する場面:forward、stub、secondary、そして判断を決める送信元アドレスの確認。
オフィスのリゾルバーは一つの社内名前空間を除いてすべてに応答し、それを知っている社内 DNS サーバーは VPN の向こう側にあります。BIND はその一つのゾーンを上流へ三通りの方法で渡せますが、失敗の仕方がそれぞれ異なります。条件付きフォワードは最も小さな約束で、stub ゾーンは委任データを保持し、secondary は完全なコピーを保持します。最初に見つけた設定例ではなく、上流が何を許し、リゾルバーに何を保持させたいかで選んでください。
一つの名前空間に対する三つの構成
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
条件付きフォワード:最も小さな約束
オフィスのリゾルバーを 192.168.10.53、社内サーバーを 10.40.0.53 とし、承認済みのトンネル経由で到達できるとします。宣言は三行で、興味深いのは forward only です。経路ではなく失敗時の挙動を変えるからです。
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};
forward only を付けると、上流に到達できない場合は反復解決へのフォールバックではなく、このゾーンに対して SERVFAIL を返します。プライベート名前空間では通常これが望ましい設定です。フォールバックするとプライベート名が公開リゾルバーへ送られ、インターネットから役に立たない応答が返るからです。 BIND のリファレンス は両方の方針を説明しており、その違いは設定例が示唆する以上に重要です。同じ名前の既存ゾーンを置き換えるのではなく、既存の設定にゾーンを統合してください。
stub か secondary か:委任が重要になる場合
stub ゾーンは社内サーバーにゾーンの NS レコードを問い合わせ、その後に権威サーバーへ直接問い合わせます。上流の領域が大きく分割されている場合や、すべてを一つのアドレスに固定せず委任をたどりたい場合に選びます。代償は、NS データが最新であることへの依存と、列挙された各ネームサーバーにリゾルバーの送信元アドレスから到達できることへの依存です。
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};
secondary はローカルデータから応答し、上流の停止にも耐えます。これが転送依存を受け入れる理由です。同時に、リゾルバーは自分が所有しないゾーンのコピーを保持することになるため、ファイルパス、プライマリ側の転送 ACL、更新タイマーがすべて運用面の一部になります。
両者を分ける確認
BIND は自分で外向きクエリを生成するため、問うべきはノート PC が 10.40.0.53 に届くかではなく、リゾルバーのホストが社内サーバーの見る送信元アドレスから届くかです。まずカーネルに、次にサーバーに、その順で問い合わせてください。
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example
経路上で UDP と TCP の両方を許可してください。切り詰められた応答は TCP を強制し、UDP だけを許可する方針はパケット損失に見える断続的な失敗を生みます。社内側には、リゾルバーの送信元に対する許可ルールと、そこへの戻り経路の両方が必要です。その送信元はリゾルバーのルーティング済みアドレスか明示的に変換されたアドレスであり、クライアントプールのアドレスであることはほとんどありません。NS クエリが失敗するなら、forward ゾーンがどう振る舞っても stub ゾーンは機能しません。
トンネルではなく応答を検証する
これまで問い合わせたことのない名前をオフィスのリゾルバー経由で引き、応答の authority セクションを見て社内ゾーンから来たかを確認します。キャッシュされた応答は現在の経路を何も証明せず、上流への直接クエリの成功はリゾルバーがそのゾーンを選んだことを証明しません。同じクエリを TCP で繰り返し、経路が切り詰めに耐えることを確かめてください。
クライアントをオフィスのリゾルバーに向けたままにする そして DNSSEC 検証は有効のままにしてください。独立した暗号化リゾルバーを設定したブラウザーはこの構成を完全に迂回し、予期しない応答を正しく見せるために検証を切ることは、見える失敗を目に見えない失敗と引き換えることになります。
三つのうちどれを選び、なぜ選んだかを書き留めてください。ゾーンの失敗に次に遭遇する人は、設定ファイルよりもその一文を必要とします。