MENU
「安心のセキュリティをお得な価格」でご提供!
Fortinet商品など
ENGAGE fotinet

DNSの条件付きフォワーダとは

DNSの条件付きフォワーダとは、特定の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サーバーへ転送すれば、必要な名前解決ができるようになります。

Active Directory の別ドメイン・別フォレスト間連携

Windows Server 環境では、別ドメインや別フォレスト間で相互に名前解決したい場面で、条件付きフォワーダがよく使われます。

たとえば、

  • ad-a.local
  • ad-b.local

のように別々に管理されている環境で、それぞれ相手側の名前を引けるようにするために利用されます。

拠点・子会社・部門ごとにDNS管理が分かれている場合

本社、工場、開発環境、子会社などでDNS管理が分離されている場合、各名前空間ごとに条件付きフォワーダを設定すると、分散管理しやすくなります。

クラウドとオンプレミスを組み合わせた環境

オンプレミス側では解決できないクラウド上のプライベートDNSゾーンに対して、そのクラウド環境のDNSサーバーやDNS転送基盤へ問い合わせを振り分ける用途でも使われます。

条件付きフォワーダの考え方をやさしく言うと

実務上は、次の理解でかなり本質に近いです。

条件付きフォワーダとは、「その名前空間をよく知っているDNSサーバーに、そのドメインだけ問い合わせを任せる仕組み」です。

たとえば、

  • 社内ドメインは社内DNS
  • 子会社ドメインは子会社DNS
  • 提携先ドメインは提携先DNS
  • クラウド内のプライベートドメインはクラウド側DNS

というように、名前空間ごとに問い合わせ先を分担させるイメージです。

スタブゾーンとの違い

条件付きフォワーダと比較されやすいのがスタブゾーンです。

条件付きフォワーダ

  • 特定ドメイン向け問い合わせを、あらかじめ設定したDNSサーバーへ転送する
  • 自分はそのゾーン情報そのものを保持しない
  • 設定が比較的シンプル

スタブゾーン

  • 相手ゾーンの情報を丸ごと持つのではなく、そのゾーンの権威DNSサーバーを識別するための最小限の情報を保持する
  • 主に、どの権威DNSサーバーに問い合わせるべきかを知るために使う

つまり、

  • 条件付きフォワーダは「このドメインはこのDNSへ転送する」
  • スタブゾーンは「このドメインの権威DNSサーバーはどこかを把握する」

という違いがあります。

DNS委任との違い

DNS委任(Delegation)も似た文脈で登場しますが、意味は別です。

たとえば

  • 親ゾーン: example.com
  • 子ゾーン: dev.example.com

という構成があるとします。

このとき親ゾーン側で dev.example.com の権威DNSサーバーを NS レコードで示すのが委任です。

これは、DNS階層の中で正式に問い合わせ先を案内する仕組みです。

一方、条件付きフォワーダは、DNSサーバーの運用設定として「この名前空間の問い合わせは、このDNSサーバーに転送する」と定義するものです。

つまり、

  • 委任: 親ゾーンが子ゾーンの権威DNSサーバーを示す正式な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.arpaip6.arpa に関する問い合わせを、特定のDNSサーバーに転送する運用です。

そのため、条件付きフォワーダは「ホスト名をIPに変換する正引き専用機能」と理解するより、特定のDNS名前空間向け転送機能と捉えるほうが正確です。

Windows Server でのイメージ

Windows DNS では、条件付きフォワーダは「特定のDNSドメインについて、このDNSサーバー群に問い合わせる」という設定として扱われます。

たとえば、

  • DNSドメイン: partner.local
  • 転送先DNSサーバー: 192.168.100.10, 192.168.100.11

のように登録すると、*.partner.local に対する問い合わせを指定先へ転送できます。

Active Directory 環境では特に、別ドメイン・別フォレスト間の名前解決でよく利用されます。

BIND系での考え方

BIND でも、特定ゾーンに対して forwarding を設定することで、同様の構成が可能です。

考え方としては、「このゾーンは転送型として扱い、指定の forwarders に任せる」というものです。

概念的には次のような設定です。

zone "partner.local" {
    type forward;
    forward only;
    forwarders { 192.168.100.10; 192.168.100.11; };
};

この例では、partner.local に対する問い合わせを自力で解決せず、指定したDNSサーバーへ転送します。

forward only と forward first の違い

実装によっては、条件付きフォワーダに近い forwarding 設定に次のような動作差があります。

forward only

  • 必ず指定したフォワーダへ送る
  • フォワーダが失敗しても、自分で別経路の解決は試みない

forward first

  • まず指定したフォワーダへ送る
  • 失敗した場合は、自分で通常の再帰解決を試みることがある

内部専用ドメインでは、外部に問い合わせても答えが得られないことが多いため、forward only 的な設計が向くことがあります。

まとめ

DNSの条件付きフォワーダとは、特定のDNS名前空間に対する問い合わせだけを、あらかじめ指定した別のDNSサーバーへ転送する仕組みです。

ポイントを整理すると、次のようになります。

  • 通常のフォワーダは、自分で解決できない問い合わせを既定の転送先へ送る
  • 条件付きフォワーダは、特定ドメインごとに転送先を分ける
  • 別組織、別ドメイン、別フォレスト、クラウド連携などでよく使われる
  • スタブゾーンや委任とは似ているが別の仕組み
  • シンプルで便利だが、依存先DNSやループ設定には注意が必要

実務向けにひとことで言い直すなら、「その名前空間を管理しているDNSサーバーに、そのドメインの問い合わせだけを任せる仕組み」と理解すると分かりやすいです。

以上、DNSの条件付きフォワーダについてでした。

最後までお読みいただき、ありがとうございました。

カテゴリ一覧

ページトップへ