DNSの条件付きフォワーダとは、特定のDNSドメイン名に対する問い合わせだけを、あらかじめ指定した別のDNSサーバーへ転送する仕組みです。
簡単にいうと、DNSサーバーが「このドメイン宛ての名前解決は、このDNSサーバーに聞く」というルールを持つ機能です。
通常のDNSフォワーダが「自分で解決できない問い合わせを既定の転送先へ送る」仕組みであるのに対し、条件付きフォワーダは問い合わせ先のドメイン名に応じて転送先を切り分ける点が特徴です。
DNSサーバーは、クライアントから名前解決の問い合わせを受けると、通常は次の順で処理します。
このうち、特定のドメインに対する問い合わせだけを、個別に指定したDNSサーバーへ転送するのが条件付きフォワーダです。
たとえば社内DNSサーバーに、次のような設定をしたとします。
partner.local への問い合わせは DNSサーバーB に転送subsidiary.local への問い合わせは DNSサーバーC に転送この場合、クライアントからの問い合わせは次のように振り分けられます。
fileserver.partner.local → DNSサーバーBへ転送db01.subsidiary.local → DNSサーバーCへ転送www.example.com → 通常の外部向け名前解決つまり、DNSサーバーが問い合わせの名前を見て、「この名前空間なら、このDNSに任せる」と判断するわけです。
ここは混同しやすいポイントです。
通常のフォワーダは、そのDNSサーバー自身で回答できない問い合わせを、既定の転送先DNSサーバーへ送る仕組みです。
つまり、何でもかんでも転送するわけではなく、
については自分で回答します。
条件付きフォワーダは、特定のドメインに一致する問い合わせだけを、専用の転送先DNSサーバーへ送ります。
整理すると、違いは次の通りです。
条件付きフォワーダは、主に自分では管理していない別の名前空間を、特定のDNSサーバー経由で解決したい場合に使われます。
代表的な利用例は次の通りです。
たとえば、自社ネットワークから提携先の内部システムにアクセスする必要があり、提携先が partner.local のような内部ドメインを使っているケースです。
この場合、自社のDNSサーバーは partner.local の情報を持っていません。
そこで partner.local だけを提携先のDNSサーバーへ転送すれば、必要な名前解決ができるようになります。
Windows Server 環境では、別ドメインや別フォレスト間で相互に名前解決したい場面で、条件付きフォワーダがよく使われます。
たとえば、
ad-a.localad-b.localのように別々に管理されている環境で、それぞれ相手側の名前を引けるようにするために利用されます。
本社、工場、開発環境、子会社などでDNS管理が分離されている場合、各名前空間ごとに条件付きフォワーダを設定すると、分散管理しやすくなります。
オンプレミス側では解決できないクラウド上のプライベートDNSゾーンに対して、そのクラウド環境のDNSサーバーやDNS転送基盤へ問い合わせを振り分ける用途でも使われます。
実務上は、次の理解でかなり本質に近いです。
条件付きフォワーダとは、「その名前空間をよく知っているDNSサーバーに、そのドメインだけ問い合わせを任せる仕組み」です。
たとえば、
というように、名前空間ごとに問い合わせ先を分担させるイメージです。
条件付きフォワーダと比較されやすいのがスタブゾーンです。
つまり、
という違いがあります。
DNS委任(Delegation)も似た文脈で登場しますが、意味は別です。
たとえば
example.comdev.example.comという構成があるとします。
このとき親ゾーン側で dev.example.com の権威DNSサーバーを NS レコードで示すのが委任です。
これは、DNS階層の中で正式に問い合わせ先を案内する仕組みです。
一方、条件付きフォワーダは、DNSサーバーの運用設定として「この名前空間の問い合わせは、このDNSサーバーに転送する」と定義するものです。
つまり、
という違いがあります。
「このドメインの問い合わせはこのDNSへ送る」という考え方なので、理解しやすく導入しやすいです。
相手が管理している名前空間を、自分で保持せずに解決できます。
特定ドメインは最初から適切なDNSサーバーへ送るため、意図した経路で名前解決させやすくなります。
インターネットに公開されていない内部専用ドメインでも、相手側DNSサーバーが知っていれば解決できます。
転送先が停止していると、そのドメインの名前解決ができなくなります。
当然ですが、転送先DNSサーバーへ到達できることが前提です。
DNSではUDP/TCP 53番ポートの通信が必要になります。
たとえばDNSサーバーAが partner.local をDNSサーバーBへ転送し、DNSサーバーBが同じドメインを再びDNSサーバーAへ転送するような設定をすると、問い合わせループの原因になります。
多数のドメインに対して個別設定を行うと、保守性が落ちることがあります。
そのDNSサーバー自身がすでに保持しているゾーン名については、通常、条件付きフォワーダで別DNSへ逃がすような設計はできません。
その場合は、ゾーン設計の見直しや委任の検討が必要です。
条件付きフォワーダは、通常は正引きの名前解決で説明されることが多いですが、環境によっては逆引き用の名前空間にも設定されます。
たとえば、in-addr.arpa や ip6.arpa に関する問い合わせを、特定のDNSサーバーに転送する運用です。
そのため、条件付きフォワーダは「ホスト名をIPに変換する正引き専用機能」と理解するより、特定のDNS名前空間向け転送機能と捉えるほうが正確です。
Windows DNS では、条件付きフォワーダは「特定のDNSドメインについて、このDNSサーバー群に問い合わせる」という設定として扱われます。
たとえば、
partner.local192.168.100.10, 192.168.100.11のように登録すると、*.partner.local に対する問い合わせを指定先へ転送できます。
Active Directory 環境では特に、別ドメイン・別フォレスト間の名前解決でよく利用されます。
BIND でも、特定ゾーンに対して forwarding を設定することで、同様の構成が可能です。
考え方としては、「このゾーンは転送型として扱い、指定の forwarders に任せる」というものです。
概念的には次のような設定です。
zone "partner.local" {
type forward;
forward only;
forwarders { 192.168.100.10; 192.168.100.11; };
};
この例では、partner.local に対する問い合わせを自力で解決せず、指定したDNSサーバーへ転送します。
実装によっては、条件付きフォワーダに近い forwarding 設定に次のような動作差があります。
内部専用ドメインでは、外部に問い合わせても答えが得られないことが多いため、forward only 的な設計が向くことがあります。
DNSの条件付きフォワーダとは、特定のDNS名前空間に対する問い合わせだけを、あらかじめ指定した別のDNSサーバーへ転送する仕組みです。
ポイントを整理すると、次のようになります。
実務向けにひとことで言い直すなら、「その名前空間を管理しているDNSサーバーに、そのドメインの問い合わせだけを任せる仕組み」と理解すると分かりやすいです。
以上、DNSの条件付きフォワーダについてでした。
最後までお読みいただき、ありがとうございました。