☰

ソースサブネットに応じて異なる DNS エントリを解決するにはどうすればよいですか?

tag-icon • tag-icon domain-name-system bind internal-dns dns-zone
ソースサブネットに応じて異なる DNS エントリを解決するにはどうすればよいですか?

複数のサイトに新しい社内 Web サイトを設置しており、使用するソース サブネットに応じて、その FQDN をサイト固有のサブドメインに解決したいと考えています。現在、バインド DNS は、FQDN 解決がサイト A でマスターされ、サイト B と C にスレーブ化される (すべて Puppet 経由) ように設定されているため、サイト B と C に異なる回答を持つ個別のレコード ファイルを設定してこれを行うことはできません。

たとえば、サイト a の IP 172.10.0.0/16 で server.domain.com を server.a.domain.com に解決し、サイト b の IP 172.11.0.0/16 で server.domain.com を server.b.domain.com に解決するなどです。

Bind RPZ を調べていますが、サブネットの特定の解決オプションは提供されていないようです。私の読み方が間違っていなければ、サブネット全体をドロップまたはブロックする機能のみがあるようです。解決のために正しいゾーンに転送するのではなく、cname をリダイレクトするように動作させることはできますが、これは、私が使用しようとしているようなクライアント IP トリガーを使用していないすべてのサーバーに一般的に適用され、domain.com ゾーンの CNAME を更新することになるかもしれません。

name.d.conf.options に追加

response-policy { zone "rpz"; };

rpz ゾーン ファイル

zone "rpz" {
  type master;
  file "/etc/named/zones/rpz/db.rpz.conf";
  allow-query { none; };
};

dbファイル

@       IN    SOA  nstest.domain.com. domain.com.  (
                      2   ; serial
                      3H  ; refresh
                      1H  ; retry
                      1W  ; expiry
                      1H) ; minimum

@        IN    NS    nstest.domain.com. ; destination IP rewrite

16.0.0.16.172.rpz-ip CNAME server.domain.com.
server.domain.com     CNAME   server.a.domain.com.

これらの設定により、ソースIPに関係なく、このns経由のserver.domain.comへのすべてのリクエストはserver.a.domain.comに解決されます。

あるいは、RPZ を使用するのは間違った方法なのでしょうか。調査中にバインド ビューも見たことがありますが、サイトごとにゾーン ファイル全体を再作成する必要があるようです。私は単一の CNAME レコードを変更したいだけです。

ご協力いただければ幸いです。

答え1

  • 場所 B 専用サーバー

この場合、RPZ を簡単に使用できます。解決策としては、この DNS サーバーを非標準ポート (つまり、53 TCP/UDP 以外) で実行し、ファイアウォール レベルでポート リダイレクトを設定して、特定のネットワークからの要求がこのポートにリダイレクトされるようにすることもできます。その他のすべての要求は、標準ポートの DNS サーバーによって処理されます (「グローバル」RPZ が問題であるため、他のトラフィックにも DNS サーバーが必要であると考えられます)。

  • 「共有」DNSサーバーは場所Bだけではない

ビューはおそらくあなたにとって正しい方向です。明示的に CNAME が必要ではなく、A レコードであってもかまわない場合は、ビューで「特定のサブドメイン」だけを簡単に定義し、残りは「通常の」解決/他の DNS サーバーへの転送を維持することができます。

ドメインを持っているとします例.com場所AのDNSサーバー上にserver.example.comこれは通常、192.0.2.10のAレコードとして解決されます。また、別のレコードもあります別の.example.com値 192.0.2.20 の A に解決されます。

次に、ローカルのどこか（場所B）にバインドサーバーがあり、ローカルクライアントを解決します。特定のクライアント（場所BのローカルIP）のローカルビューを作成し、ドメインを作成できます。server.example.com。

@       IN    SOA  dns.example.com. admin.example.com.  (
                      2   ; serial
                      3H  ; refresh
                      1H  ; retry
                      1W  ; expiry
                      1H) ; minimum

@        IN    NS    dns.example.com ; destination IP rewrite

@        IN    A     192.0.2.30

クライアントが server.example.com のリクエストを送信すると、そのリクエストはローカルの「マスター」ゾーンとしてローカルに解決されます。クライアントが他のリクエスト (server.example.com のサブドメインを除く) を送信すると、他の構成に基づいて通常の解決または転送が行われます...

したがって、場所 A では結果は次のようになります。

server.example.com => 192.0.2.10
another.example.com => 192.0.2.20

場所 B では次のようになります。

server.example.com => 192.0.2.30
another.example.com => 192.0.2.20

この方法では、サブドメインの明示的なリストのみを上書きできます。欠点は、追加ゾーンであるため、少なくとも SOA とおそらく NS レコードが必要であり、この場合は CNAME を使用できないことです。

関連情報