二つの拠点、一つのプライベート DNS ゾーン：レコードは誰のものか

緑の拠点にホストを追加すると緑の利用者には解決されますが、黄色のオフィスは依然として NXDOMAIN を受け取ります。これは VPN の障害でも壊れたリゾルバーでもなく、プライベートゾーン内の所有権の空白です。別々に編集された二つのレコード一覧は、拠点同士が到達できるというだけで一つのゾーンにはなりません。解決策は公開の計画であり、もう一つのファイアウォール規則ではありません。

症状は欠けている所有者を示す

どの拠点にも、名前が必要になったときに誰かが加えたローカル上書き、Pi-hole の項目、または dnsmasq の行があるでしょう。緑のレコードは緑のリゾルバーにしか存在しないため、黄色のクライアントは自分のリゾルバーに問い合わせ、正直な「そのような名前はない」を受け取ります。古い応答は見え方が異なります：ホストが移り、一方の拠点はコピーを更新し、もう一方はいまだに古いアドレスを返します。

どちらのパターンもキャッシュの消去では長くは直りません。転送リゾルバーのキャッシュは、かつて受け取った応答の複製であり、新しい名前を公開する権威ではないので、今日動くキャッシュは明日のホストについて何も語りません。BIND の文書が一次、二次、再帰、転送という役割を分けて説明しているのは、まさにこのためです。

したがって設計上の問いは狭く、答えられます：誰がレコードを作成できるのか、そしてそのレコードは、それに答えるべきすべてのリゾルバーにどう届くのか。

選択肢 A：二次サーバーを伴う単一の権威ゾーン

internal.example.com の一次サーバーを動かし、対応している二次サーバーが各拠点でゾーンを取得できるようにします。各拠点の再帰リゾルバーはローカルの二次サーバーに問い合わせるため、答えはキャッシュではなく権威ある情報源から来て、一度行った変更は打ち直されるのではなく転送されます。

この構成には、先延ばしにしやすく、飛ばすと高くつく明示的な判断が必要です。誰がゾーンを編集できるのか。どのサーバーがそれを転送してよく、どのアドレスを経由するのか。拠点間のトンネルが落ちている間、クライアントには何が見えるべきか。二次サーバーは最後のコピーから答え続けますが、これは通常望ましい挙動であり、障害時の不意打ちではなく明示された選択でなければなりません。

ゾーン転送はアドレスで既知の二次サーバーに限定し、実装が対応している場合はトランザクション署名を使います。開かれた転送は、ポートに到達できる誰にとっても内部名前空間の写しです。

代償は調整です：編集経路を一つにし、変更レビューを一つにし、レコードが誤っているときに誰が待機するのかを共有して理解することです。

選択肢 B：拠点ごとのサブドメイン

green.internal.example.com を緑の拠点に、yellow.internal.example.com を黄色の拠点に委任します。各拠点は自分の名前について権威を持ち、親ゾーンは委任のレコードだけを運びます。一つのファイルをめぐる争いは消え、現地のチームは中央の変更を待たずにホストを追加できます。

委任は親ゾーンに存在しなければならず、拠点の権威サーバーを指す NS レコードが必要です。完全な委任が現実的でない場合、サブドメインへの条件付き転送は有効な代替ですが、それは公開された事実ではなくリゾルバーの設定なので、すべてのリゾルバーに同じ規則が必要です。

代償は消えるのではなく移ります：親ゾーンには依然として所有者が必要で、新しい拠点の作成はいまや一箇所ではなく二箇所の変更になります。

すべてのリゾルバーに選択を守らせる

対応している設定を通じて、承認されたリゾルバーと検索ドメインをクライアントに渡し、リゾルバーが問い合わせる必要のある任意の遠隔 DNS サーバーへの許可された VPN 経路を持っていることを確認します。また、正しい名前でも経路がなければ壊れた接続のままなので、アプリケーションにはそれらの応答が返すプライベートアドレスへの経路も必要です。

Pi-hole がローカル解決を担う場合は、どのレコードを所有し、どの問い合わせを転送するのかを書き留めます。別々に編集された二つの Pi-hole 一覧はやはり複製されません。Pi-hole v6 では、独自の dnsmasq 行は TOML、CLI、環境変数といったホスト側のオプションで設定し、API では公開されません；/etc/dnsmasq.d/ のファイルを読み込むのは別のオプションで、既定では無効です。

次に、どこでも見えるべき名前で両側から試します。

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA の応答は、黄色のリゾルバーが自分を権威とみなしているのか、二次サーバーに問い合わせているのか、単に転送しているのかを教えてくれます。これらは故障の仕方が異なる別の設計であり、応答は通常、実際に配備したのはどれかを示します。

三つの受け入れ条件で締めます：各拠点からの一つの名前、一時間以内に変更した一つのレコード、拠点間リンクが利用できないこと。最初の一つしか通らない設計は、紙の上の公開計画と本番のローカル上書きを抱えています。