ドメイン コントローラー（Windows Server）のDNSサーバーで「フォワーダーを複数（A/B/C）入れたのに、思った通りに切り替わらない」「負荷分散されているのか分からない」と悩むことは多いです。この記事では、Windows DNSサーバーの複数フォワーダーの選択ロジック、NXDOMAIN（名前が存在しない）やREFUSED（拒否）時の扱い、Windows 10/11 クライアント側の問い合わせ動作の違いまで、運用目線で整理します。
結論：複数フォワーダーは「負荷分散」ではなく「順番＋フェイルオーバー」
先に要点をまとめると、Windows DNSサーバーでフォワーダーを複数登録する主目的は、基本的に上流DNSが応答しないときの冗長化（フェイルオーバー）です。ラウンドロビンで均等に振り分けてくれる仕組みではありません。
- 問い合わせは「設定された順番」をベースに送られます（ただし既定では応答速度により内部的な順番が一時的に入れ替わることがあります）。
- 次のフォワーダーへ進むのは、原則として前のフォワーダーから応答が返ってこない（タイムアウト等）場合です。
- フォワーダーからNXDOMAIN（名前が存在しない）やREFUSED（拒否）など「何らかの応答」が返ってきた場合は、その結果を採用して終了します（次に回しません）。
- Windows 10 / 11 クライアントはフォワーダーを使いません。NICに設定されたDNSサーバーに対して、別のタイムアウト／フォールバック手順で問い合わせます。
| よくある期待 | 実際の挙動（Windows DNSサーバー） | 対処の方向性 |
|---|---|---|
| A/B/Cに均等に振り分けたい | 均等分散は基本しない（順番＋フェイルオーバー） | 上流側で負荷分散（Anycast/ロードバランサ/冗長リゾルバ）を検討 |
| AがNXDOMAINならBでも確認してほしい | NXDOMAINは「応答があった」扱いなので次へ回さない | 条件付きフォワーダー/スタブゾーン/スプリットDNSなど設計で解決 |
| フォワーダーを4つ以上入れれば安心 | 既定タイムアウトのままだと、実際には3つ目までしか試せない場合がある | ForwardingTimeout/RecursionTimeoutの見直し、フォワーダー数の適正化 |
まず整理：Windows DNSサーバーが名前解決するときの優先順位
フォワーダーの動作だけを見ても混乱しがちなので、DNSサーバーが問い合わせを受けたときの「優先順位」を先に押さえます。Windows DNSサーバーは、受け取ったクエリを概ね次の順で解決しようとします。
| 優先 | 参照する情報 | 例 | ポイント |
|---|---|---|---|
| 高 | 自分が保持するゾーン（プライマリ/セカンダリ/AD統合） | corp.example.local のA/SRVレコード | ここで答えられるなら外へは聞きに行かない |
| ↓ | DNSサーバーのキャッシュ | 直前に引いた www.microsoft.com の結果 | キャッシュがあるとフォワーダーに飛ばない |
| ↓ | 条件付きフォワーダー（該当ドメインのみ転送） | partner.example.com だけ相手DNSへ | 「特定ドメインは必ず相手へ」の設計ができる |
| ↓ | （通常の）フォワーダー | インターネット向け外部解決 | 今回のA/B/Cはここ |
| 低 | ルートヒント（必要に応じて） | フォワーダーが使えない/設定によりフォールバック | 外部へ直接問い合わせる構成は露出やトラフィック面の注意が必要 |
フォワーダーを設定しているDNSサーバーは、外部名を解決するときにまずフォワーダーへ再帰クエリを投げ、短時間待って応答がなければルートヒントを使った解決へ進みます（設定や環境により挙動は変わります）。フォワーダーを使うことで、社内DNSサーバーがインターネット上の多数のサーバーへ直接問い合わせる状況を減らし、キャッシュ効率や情報露出の面でメリットがあります。
複数フォワーダー（A/B/C）の選択ロジック
基本は「リストの順番」で試行される
Windows DNSサーバーは、フォワーダーに複数のIPを登録した場合、登録された順番を基準に問い合わせます。DNSマネージャー上で A → B → C の順に並べていれば、まずAに投げ、応答が得られなければB…というのが基本動作です。
既定の「動的フォワーダー再並べ替え」で、見かけ上の順番が変わることがある
実務で混乱を生むのが、既定で有効なDynamic Forwarder Reordering（動的フォワーダー再並べ替え）です。これはラウンドロビンではなく、応答が遅いフォワーダーを後ろに回し、速いフォワーダーを優先しやすくする仕組みです。
| 項目 | 内容（概要） | 運用での見え方 |
|---|---|---|
| 内部に「動的リスト」を持つ | DNSサービスがフォワーダーの並びを一時的に保持する | 設定順とは別の順で試行されることがある |
| 応答時間で並べ替え | 応答が遅いフォワーダーを末尾に回す | 「Aを先頭にしたのにBが先に使われた」ように見える |
| 一定間隔で設定順に戻る | 動的リストは定期的に設定順へリセットされる | しばらくすると再びAが先頭に戻る、を繰り返す |
目安として、動的リストはおおむね15分周期で設定順へ戻り、応答が1秒を超えると「遅い」と見なされ、遅い応答が続くフォワーダーは末尾へ回されます。つまり複数フォワーダーは「均等分散」ではなく、速いものを優先して使い、遅いものは後回しにする方向に寄ります。
Windows Server 2022以降の注意：全フォワーダー未応答が続くと“先頭固定”になる場合
さらに、Windows Server 2022以降では「フォワーダーが全滅（どれも応答しない）」状態が続くと、DNSサービス再起動まで動的リストの先頭だけを使い続ける、といった注意点も示されています。フォワーダーの死活監視はDNS機能の外側で行う必要があるため、監視・アラートとセットで運用するのが安全です。
次のフォワーダーへ進む条件（最重要ポイント）
次へ進むのは「応答が返ってこない」場合
フォワーダーAに問い合わせて、ネットワーク遅延・パケットロス・経路不通・上流DNSの停止などで応答がDNSサーバーに戻ってこないと、DNSサーバーは一定時間待ってから次のフォワーダーBへ問い合わせます。これが「複数フォワーダーによる冗長化」が効く代表的なケースです。
NXDOMAIN/REFUSEDなど「応答が返ってきた」場合は、そこで確定して次へ回さない
重要なのはここです。フォワーダーAが応答を返した時点で、たとえそれがエラー応答であっても、DNSサーバーは「応答を得られた」と判断します。たとえば次のようなケースでは、B/Cへ回しません。
- NXDOMAIN（Name error / 名前が存在しない）：フォワーダー側に該当レコードが無い、またはそのドメインが存在しないという意味の応答。
- REFUSED（拒否）：フォワーダー側のポリシー等で問い合わせを拒否された応答。
この場合、DNSサーバーは同じ応答（または状況により Server failure）をクライアントへ返し、2台目以降のフォワーダーには問い合わせません。「AがダメならBへ」という発想は、“応答が返ってこない”ときにだけ成立する、と覚えると整理しやすいです。
| フォワーダーAの状況 | DNSサーバーの判断 | B/Cへ問い合わせる？ | クライアントへ返りやすい結果 |
|---|---|---|---|
| 応答なし（タイムアウト/到達不能） | 「未応答」扱い | はい（次のフォワーダーへ） | 次のフォワーダーの結果、または最終的にServer failure |
| 正常応答（NOERRORでA/AAAA/CNAME等が返る） | 「解決できた」 | いいえ | 解決結果を返す |
| NXDOMAIN（Name error） | 「名前が存在しない」応答を取得 | いいえ | NXDOMAINを返す（負のキャッシュ対象） |
| REFUSED（拒否） | 「拒否」応答を取得 | いいえ | Server failure等として失敗を返すことがある |
現場で起こりがちな「誤解」の例
実際に事故が起きやすいのは、次のような“混ぜ方”です。
- A：社内のセキュリティ機器（特定ドメインをブロックし、REFUSEDを返す）
- B：パブリックDNS（ブロックせず解決できる）
この構成だと、AがREFUSEDを返した時点でクエリは確定するため、Bはバックアップとして機能しません。意図が「Aが落ちたらBへ」なら良いのですが、「Aで拒否されたらBで回避」にはなりません。フォワーダーを複数入れるときは、同等のポリシー・同等の解決範囲を前提にするのが安全です。
タイムアウトの落とし穴：フォワーダーを増やしても「実際には試せていない」ことがある
「3台もフォワーダーを入れているのに切り替わらない／安定しない」という相談で多いのが、タイムアウト設定の影響です。Windows DNSサーバーには、少なくとも次の2つのタイマーが関係します（値はWindows Server 2012〜2022の既定例）。
| 設定名 | 意味 | 既定値（例） | 影響 |
|---|---|---|---|
| ForwardingTimeout | 各フォワーダーを待つ時間 | 3秒 | 短すぎると「遅いが生きているフォワーダー」を未応答扱いにしやすい |
| RecursionTimeout | 再帰解決全体の許容時間 | 8秒 | これを超えると途中でServer failureに向かう（次のフォワーダーへ進めない） |
さらに実運用では、待ち時間にオーバーヘッド（例：0.5秒程度）が乗ることがあります。既定値のままフォワーダーを4つ以上登録しても、再帰タイムアウトに先に到達してしまい、4つ目以降に到達しないことがあり得ます。つまり「登録してある」ことと「実際に試行される」ことは別です。
既定値のイメージ（通常フォワーダーが応答しない場合）
| 経過時間の目安 | DNSサーバーの動き | 補足 |
|---|---|---|
| 0秒 | フォワーダーAへ転送 | 即時 |
| 約3.5秒 | Aが未応答ならフォワーダーBへ転送 | ForwardingTimeout（3秒）＋オーバーヘッド |
| 約7.5秒 | Bが未応答ならフォワーダーCへ転送 | 次の試行までさらに待ちが入る |
| 8秒前後 | RecursionTimeoutに到達 | この時点で次のフォワーダーへ到達できないケースが出る |
| 11秒前後 | クライアントへServer failureを返す | “タイムアウト直後”ではなく、次の試行タイミングで返ることがある |
条件付きフォワーダーはさらに「2台目まで」で終わりやすい
条件付きフォワーダーは、ゾーン単位でForwarderTimeout（既定例：5秒）が使われるため、同じRecursionTimeout（既定例：8秒）との組み合わせでは、既定のままだと2台目までで時間切れになりやすい点も要注意です。相手先DNSがWAN越しで遅い場合は、ゾーン単位のタイムアウト調整が必要になります。
タイムアウト調整の考え方
フォワーダーを「3台以上」本気で活かすなら、ForwardingTimeoutとRecursionTimeoutの関係を見直す必要があります。Microsoftの情報では、これらはレジストリ／dnscmd／PowerShellで確認・設定できます。変更は影響範囲が広いので、まずは検証環境や営業時間外で段階的に行うのが安全です。
# 現在値の確認（例）
Get-DnsServerRecursion
Get-DnsServerForwarder
# dnscmdで設定（例：秒）
dnscmd /config /RecursionTimeout 12
dnscmd /config /ForwardingTimeout 4キャッシュの存在：一度の結果が「しばらく固定」される
フォワーダーの議論で忘れてはいけないのが、DNSサーバー自身のキャッシュです。Windows DNSサーバーは、正の応答だけでなく負の応答（NXDOMAINなど）もキャッシュします。これにより、フォワーダーAが一時的に誤った応答を返したり、ある瞬間だけ到達できなかったりすると、後続の問い合わせの見え方が大きく変わります。
| キャッシュ種別 | 例 | 運用上の影響 |
|---|---|---|
| 正のキャッシュ | www.example.com → 93.184.216.34 | 同じ名前は上流に聞かず高速になる（ただし変更の追随が遅れる場合がある） |
| 負のキャッシュ | foo.example.com は存在しない（NXDOMAIN） | 一定時間「存在しない」が固定される（後から作ったレコードが反映されないように見える） |
PowerShellの設定では、MaxTTL（正のキャッシュ上限）が1日、MaxNegativeTtl（負のキャッシュ上限）が15分が既定です。実際の保持時間は応答側のTTLやSOAなどに依存しますが、まずは「負の結果もキャッシュされる」点が重要です。
挙動確認や切り分けでは、次のコマンドが便利です（本番環境では影響範囲に注意して実行してください）。
Get-DnsServerCache
Clear-DnsServerCache -ForceWindows 10 / 11 クライアントは同じ動きか
結論から言うと、同じではありません。フォワーダーは「DNSサーバーが上流に聞きに行くための設定」であり、Windows 10 / 11 クライアントが使うのはNIC（ネットワークアダプター）に設定されたDNSサーバーの一覧です。
Windowsクライアントには、DNSサーバーを複数設定した場合の既定のフォールバック／並列問い合わせの手順があります。ポイントは次の2つです。
- 最初は上から順に試すが、一定時間経過すると「リストの全DNSへ同時に問い合わせる」動きが出る。
- どれかのDNSサーバーから名前エラー（負の応答）が返ると、その時点で探索を止める（次のDNSに“確認”しにいくわけではない）。
クライアントの既定タイムライン（例）
| DNSサーバー設定 | 時間経過（秒） | クライアントの動き（概要） |
|---|---|---|
| DNSが1台 | 0 | そのDNSへ問い合わせ |
| 1 | 未応答なら同じDNSへ再問い合わせ | |
| 2 | 未応答なら再問い合わせ | |
| 4 | 未応答なら再問い合わせ | |
| 8 | 未応答なら再問い合わせ | |
| 10 | 未応答なら停止（タイムアウト） | |
| DNSが2台 | 0 | 1台目へ問い合わせ |
| 1 | 未応答なら2台目へ問い合わせ | |
| 2 | 未応答なら2台目へ再問い合わせ | |
| 4 | 未応答なら両方へ同時問い合わせ | |
| 8 | 未応答なら両方へ同時問い合わせ | |
| 10 | 未応答なら停止（タイムアウト） | |
| DNSが3台以上 | 0 | 1台目へ問い合わせ |
| 1 | 未応答なら2台目へ問い合わせ | |
| 2 | 未応答なら3台目へ問い合わせ | |
| 4 | 未応答ならリスト全台へ同時問い合わせ | |
| 8 | 未応答なら再び全台へ同時問い合わせ | |
| 10 | 未応答なら停止（タイムアウト） |
ここから分かる通り、クライアント側は「並列問い合わせ」をする局面がありつつも、負の応答が返ったら探索を止めるため、“NXDOMAINなら別DNSへ確認”にはならない点はDNSサーバー側と似ています。Active Directory環境では、クライアントのDNSは社内DNS（通常はドメイン コントローラー上のDNS）を複数台に寄せ、外部解決はDNSサーバー側のフォワーダーで吸収する構成が一般にトラブルが少ないです。
運用で効く：おすすめの設計パターン
複数フォワーダーの挙動を踏まえると、「何を冗長化したいのか」を明確にして設計するのが近道です。
| やりたいこと | おすすめパターン | 理由 |
|---|---|---|
| インターネット名前解決を安定させたい | 信頼できる上流リゾルバを2台程度フォワーダー登録（同一系統） | 応答が返った時点で確定するため、性質の違うDNSを混ぜると結果が不安定になりやすい |
| 相手先ドメインだけ別経路で解決したい | 条件付きフォワーダーを使う | ドメイン単位で転送先を固定でき、意図が明確になる |
| フォワーダーの負荷分散をしたい | 上流側でAnycastやロードバランサ、冗長リゾルバ製品を使う | Windows側の複数フォワーダーは均等分散ではないため |
| 特定ドメインだけ解決が不安定 | 条件付きフォワーダーの優先・ゾーン設計・上流側のレコード整備 | NXDOMAIN/REFUSEDは次へ回らないため、上流側の整合が重要 |
トラブルシューティング手順（現場で迷わないチェックリスト）
DNSフォワーダー関連トラブルは、原因がクライアント・DNSサーバー・上流DNS・ネットワークのどこにあるかで手が変わります。以下は切り分けを早めるための現実的な順序です。
状況の切り分け
- 解決できないのは外部名か内部名か（条件付きフォワーダーの対象かどうか）。
- 影響範囲は全クライアントか一部か（特定セグメント/特定DNSサーバーに偏っていないか）。
- クライアントからだけ失敗するのか、DNSサーバー自身で引いても失敗するのか。
確認コマンド（例）
| 観点 | コマンド例 | 見たいこと |
|---|---|---|
| クライアントのDNS設定 | ipconfig /all | 参照DNSが意図通りか |
| クライアントキャッシュ | ipconfig /flushdns | 古い結果の影響を外す |
| DNSサーバーのフォワーダー設定 | Get-DnsServerForwarder | 登録先、UseRootHintsの状態など |
| 条件付きフォワーダーの有無 | Get-DnsServerZone -Name <domain> | 対象ドメインが条件付きで定義されていないか |
| DNSサービス稼働 | Get-Service -Name DNS | DNSサービスが動いているか |
| 通信（UDP/53） | Test-NetConnection <ForwarderIP> -Port 53 | 上流DNSへ到達できるか（FW/経路） |
パケットキャプチャで最短確認するポイント
挙動が曖昧なときは、DNSサーバー／フォワーダー間の通信をキャプチャして「Aに投げたのか？Bに投げたのか？そもそも応答が返ってきているのか？」を確認すると、議論が一気に終わります。特に、上流からREFUSEDやNAME ERRORが返っているのに「次に回るはず」と思い込んでいるケースは、キャプチャで確定できます。
まとめ
- Windows DNSサーバーの複数フォワーダーは、基本は「順番に試す」フェイルオーバー設計で、均等な負荷分散はしません。
- 次のフォワーダーへ進むのは主に「応答なし（タイムアウト等）」の場合で、NXDOMAIN/REFUSEDのように“応答があった”場合はそこで確定し、次へ回しません。
- 既定のタイムアウト設定だと、フォワーダーを増やしても実際には後ろまで試せないケースがあり、数とタイマーのバランスが重要です。
- Windows 10 / 11 クライアントはフォワーダーを使わず、NICに設定されたDNSサーバーに対して別のタイムアウト手順で問い合わせます。
コメント