既存フォレスト（abc.com）のDNSに、すでに移行先ドメイン（efg.com）のゾーンを作ってしまった結果、条件付きフォワーダーが効かずフォレスト信頼やクロスフォレスト移行が進められない――この問題は「DNSゾーン競合」が原因です。状況の切り分けから、最も安全な解決手順、削除できない場合の代替案まで実務目線でまとめます。
今回のトラブルの本質：条件付きフォワーダーが効かない理由
Windows Server のDNSでは、名前解決の過程で「自分が権威を持つゾーン（Authoritative Zone）」が最優先で参照されます。つまり、abc.com 側DNSに efg.com のゾーンが存在する時点で、abc.com 側DNSは efg.com を“自分が答えを持つ領域”として扱います。
この状態で efg.com への条件付きフォワーダーを作っても、問い合わせは転送に回らず、abc.com 側の efg.com ゾーンで解決しようとしてしまいます（ゾーン内に必要なSRV/A/CNAME等が無い、または移行先の実態と一致しないため失敗する）。これが「ゾーン競合（Zone Conflict）」です。
| 処理の優先度 | DNSサーバーが参照するもの | 今回の現象との関係 |
|---|---|---|
| 高 | ローカルに保持する権威ゾーン（一次/AD統合/スタブ等） | abc側が efg.com ゾーンを持つため、転送より先にここを見てしまう |
| 中 | キャッシュ | 切替直後に古い情報が残ると検証が紛らわしくなる |
| 低 | 条件付きフォワーダー（対象ドメイン宛の転送） | 権威ゾーンが存在すると、ここに到達しにくい |
| 低 | 既定のフォワーダー／ルートヒント | インターネット向け問い合わせに流れてしまうとADのSRVが引けず失敗する |
なぜフォレスト信頼・クロスフォレスト移行でDNSが詰まるのか
フォレスト信頼（Forest Trust）やクロスフォレスト移行（例：ADMT、Exchangeのクロスフォレスト移行、サードパーティ移行ツールなど）は、最終的に「相手フォレストのドメインコントローラーを見つける」「Kerberos/LDAPで通信する」ことが前提です。ここでDC探索（DC Locator）が参照するのが、各ドメインのSRVレコードです。
代表的には次のようなクエリが成功しないと、信頼の確立・検証・認証・移行処理が連鎖的に失敗します。
- _ldap._tcp.dc._msdcs.efg.com（efg.comフォレスト/ドメインのDCを探す）
- _kerberos._tcp.efg.com（Kerberos関連）
- _ldap._tcp.gc._msdcs.efg.com（グローバルカタログ）
abc.com 側に efg.com ゾーンがあると、これらの問い合わせを“古い/空の efg.com ゾーン”で処理してしまい、移行先のDCに辿り着けなくなります。つまり、DNSの競合は信頼関係だけでなく、ログオン、認証、移行ツールの動作にまで影響します。
最も安全な解決方針：efg.comの権威を移行先へ集約する
結論として、最も事故が少なく、運用もシンプルになる方針はこれです。
abc.com 側DNSから efg.com を「権威ゾーンとして持たない」状態にし、efg.com の権威は新フォレスト（efg.com 側DNS）に集約する。そのうえで相互に条件付きフォワーダーを設定する。
ここからは、現場でそのまま実行できる粒度で手順を整理します。
棚卸し：abc.com側に存在するefg.comゾーンの“用途”を見極める
まず重要なのは、「なぜabc.com側に efg.com ゾーンを作ったのか」を正確に把握することです。今回のように Exchange の受信ドメイン（Accepted Domain）として efg.com を使っている場合、メール関連で内部DNSにレコードを作っているケースがよくあります（Autodiscover、SMTP送信先、証明書検証など）。
| レコード種別 | よくある用途 | 移行時の注意点 |
|---|---|---|
| A / AAAA | mail.efg.com、autodiscover.efg.com、社内Web等 | 新efg.com側ゾーンへ同等のレコードを再作成し、到達先IPも最新化する |
| CNAME | autodiscoverの別名、サービス切替用のエイリアス | 参照先がabc側サーバーを向いていないか確認（移行で向き先が変わる） |
| MX | メール配送経路（内部/外部） | 内部DNSにMXを持つ場合、送信経路の意図を確認（外部公開DNSと差異が出やすい） |
| TXT | SPF、ドメイン所有確認、サービス検証 | 内部DNSに必要なTXTがある場合は忘れやすい。棚卸し対象に必ず含める |
| SRV | AD/Skype/Teams/その他ディレクトリ連携 | efg.comが新ADドメインになるなら、最終的に“正しいADのSRV”が新側で自動生成される |
棚卸しのコツは、「DNSマネージャーで目視」だけで終わらせないことです。特にTXTやCNAMEは見落としやすいので、ゾーン内のレコード一覧をエクスポートしてレビューできる形にしておくと事故が減ります。
新フォレスト（efg.com）側でDNSゾーンを正しく用意する
新フォレスト側で efg.com ドメインを構築すると、通常はドメインコントローラー上のDNSに efg.com ゾーン（多くはAD統合）が作成され、DC関連のSRVレコードも自動的に登録されます。ここでのポイントは以下です。
- ゾーンはAD統合にして、複数DC/DNS間で確実に複製される設計にする
- 動的更新（Dynamic Update）は「セキュリティ保護のみ」を基本にする（要件によって調整）
- 複数DNSを用意するなら、クライアントが参照するDNSサーバーを冗長化する
- フォレスト信頼前提なら、後述の条件付きフォワーダーが設定できるネットワーク（UDP/TCP 53）が確保されているか確認する
レコード移行：メール関連・業務系の“静的レコード”を新側へ再配置する
abc.com 側で efg.com ゾーンを使っていた理由が「メールアドレスが efg.com だから」「Autodiscoverを作るため」などであれば、そこに存在した“静的レコード”は、新しい efg.com 側ゾーンへ移します。
移行のやり方は大きく2つです。
- 手動で再作成：少数なら確実。棚卸し表を作って二重チェックしやすい
- エクスポート/インポート（ゾーンファイル等）：レコードが多い場合に有効。ただし不要レコードまで持ち込みやすいので、移行後に必ず精査する
特に注意したいのは、Exchangeで使っている名前です。たとえば、以下のような名前が社内クライアントから引けなくなると、移行プロジェクト中に利用者影響が出ます。
- autodiscover.efg.com
- mail.efg.com / owa.efg.com / smtp.efg.com（環境依存）
- 証明書のSANに含めているFQDN
「受信ドメイン（Accepted Domain）」自体はExchangeの論理設定であり、DNSゾーンの権威とは別問題です。ただし、クライアントが接続するFQDNの名前解決はDNSが握っているため、DNS移行の段取りが悪いと“メールシステムは動いているのにクライアントが辿り着けない”という形で障害化します。
abc.com側からefg.comゾーンを削除する（または権威を外す）
棚卸しと新側への再作成が完了したら、abc.com 側DNSに存在する efg.com ゾーンを削除します。ここでの目的は、単に「ゾーンを消す」ことではなく、abc.com 側が efg.com に対して権威を持たない状態にすることです。
重要な実務ポイントは次の通りです。
- DNSサーバーが複数台あるなら、全DNS/全DCにe fg.comゾーンが残っていないことを確認する（1台でも残ると、そのDNSに当たったクライアントだけ失敗する）
- AD統合ゾーンの場合、削除はAD複製で伝播する。複製遅延を考慮して検証する
- 切替直後はキャッシュが残るため、DNSサーバー側・クライアント側のキャッシュも状況に応じてクリアする
条件付きフォワーダーを相互に設定する
ゾーン競合が解消できたら、ようやく条件付きフォワーダーが“狙い通り”効く状態になります。基本形はシンプルです。
- abc.com側DNS：efg.com 宛の条件付きフォワーダー → 転送先に efg.com側DNS（新フォレストDC/DNSのIP）を指定
- efg.com側DNS：abc.com 宛の条件付きフォワーダー → 転送先に abc.com側DNS（既存フォレストDC/DNSのIP）を指定
Windows DNSの条件付きフォワーダーは、環境によっては「ADに保存して複製する」設定が可能です。DNSサーバーが複数あるのに1台だけ設定してしまうのは移行あるあるの事故なので、どの範囲に複製するかも設計に含めてください。
| 観点 | 推奨 | 理由 |
|---|---|---|
| 転送先DNS | 最低2台（冗長） | 片系停止で信頼・移行・認証が止まるリスクを下げる |
| 設定の複製 | AD統合で全DNSへ複製 | DNSサーバーごとの設定差異を無くす（運用が楽） |
| 名前解決範囲 | フォレストルート（abc.com / efg.com）単位 | フォレスト信頼では _msdcs 配下の解決も必要になる |
ネットワークとファイアウォールの確認ポイント
条件付きフォワーダーは、指定した転送先DNSへクエリを投げます。よって次が満たされないと、設定はできても動きません。
- abc.com側DNS → efg.com側DNS へ UDP 53 が通る
- 必要に応じて TCP 53 も通る（応答サイズが大きい場合やゾーン転送系の要件など）
- 中間NWでDNS検査・プロキシ等がある場合、想定外のブロックが起きていない
検証手順：フォレスト信頼に必要な名前が引けるかを確認する
設定変更後は、「なんとなくnslookupで引けた」ではなく、フォレスト信頼・移行で必須となる名前を狙い撃ちして確認すると切り分けが早くなります。
| 確認したいこと | コマンド例 | 期待する結果 |
|---|---|---|
| efg.com側DCのSRVが引ける | Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.efg.com | efg.com側DCのFQDNが複数返る（SRV→A解決も成功） |
| abc.com側DCのSRVが引ける | Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.abc.com | abc.com側DCのFQDNが返る |
| クライアント視点でefg.comが解決できる | nslookup -type=SRV _kerberos._tcp.efg.com | efg.com側のSRVが返る（abc側DNS経由でもOK） |
| DNSキャッシュの影響を排除 | ipconfig /flushdns | 切替直後の「古い結果」を引きずらない |
フォレスト信頼の作成前に、abc.com側DNSから efg.com の _msdcs 配下が引けること、そして逆方向も同様に引けることが最低ラインです。これが通れば、信頼ウィザードでの検証エラーは大幅に減ります。
削除できない場合の代替案：スタブゾーン／セカンダリゾーンという選択肢
「社内事情で、abc.com側にe fg.comゾーンを完全には消せない」というケースもあります。その場合の現実的な代替案が、一次ゾーンとして抱え込むのではなく、移行先DNSを参照する形へ寄せる方法です。
| 方式 | 概要 | メリット | デメリット/注意点 |
|---|---|---|---|
| 条件付きフォワーダー | 対象ドメイン宛の問い合わせを特定DNSへ転送 | 構成が単純、運用が軽い、フォレスト信頼に相性が良い | 権威ゾーンが残っていると効かない（今回の主原因） |
| スタブゾーン | 委任に必要な最小限の情報（NS等）を同期して参照 | 移行先DNSの変更に追従しやすい | 理解不足だとトラブルシュートが難しい。設計/運用の成熟が必要 |
| セカンダリゾーン | 移行先のゾーンを複製して保持（ゾーン転送） | 参照はローカルで高速、障害時の耐性が上がることも | ゾーン転送の許可・セキュリティ設計が必須。不要な複製が増えやすい |
ただし、クロスフォレスト移行／フォレスト信頼の目的が「相互に正しいAD情報へ到達すること」である以上、最終的には権威の分離が明確な設計（各フォレストが自分のドメインに対してのみ権威を持つ）が最も事故が少なく、運用も簡単です。代替案は、どうしても削除できない事情があるときの“次善策”として捉えるのが安全です。
移行プロジェクトで起きがちな落とし穴
DNSが二重化して“どっちを引いているか分からない”状態になる
DNSサーバーが複数台あり、クライアントの参照先が統一されていないと、「AのDNSでは直ったがBのDNSでは直っていない」状態が発生します。特にAD統合ゾーンの削除・条件付きフォワーダーの複製設定は、環境差が出やすいポイントです。
キャッシュのせいで、修正後も失敗が続く
DNSはキャッシュが強力です。サーバー側のキャッシュ、クライアント側のキャッシュ、さらにアプリケーションの内部キャッシュが重なると、正しい設定に直したのに失敗が続いて見えることがあります。検証時は、参照しているDNSサーバーとキャッシュ状態を意識して確認してください。
内部DNSと外部公開DNSの“スプリットブレイン”を忘れる
efg.com はメールドメインとして外部にも存在する可能性が高く、外部公開DNS（インターネット向け）と内部AD DNS（社内向け）でレコードが異なるのは珍しくありません。内部に efg.com ゾーンを持つと、社内クライアントは基本的に外部公開DNSの efg.com を参照しなくなります。
そのため、社内ユーザーが参照する www.efg.com や portal.efg.com などがある場合、内部DNS側にも必要なレコードを用意しないと「社内だけWebが見えない」という別トラブルを引き起こします。移行の主目的はフォレスト信頼でも、周辺影響として必ずチェック対象に入れてください。
Exchangeの名前解決（Autodiscover等）を後回しにしてしまう
Accepted Domain の設定があるということは、すでに efg.com を“利用者が使うドメイン”として扱っている可能性が高いです。DNSを移行するだけで、Autodiscoverやクライアント接続の向き先が変わり、移行期間中の運用に影響が出ることがあります。
おすすめは、DNS移行を「フォレスト信頼のための作業」だけに閉じず、メールクライアントが参照する名前を棚卸しに含めて、切替タイミングと影響範囲を先に合意しておくことです。
実務向けの推奨設計：信頼・移行が進むDNSの形
クロスフォレスト移行を前提にしたDNS設計は、凝りすぎるほど複雑になり、移行の停滞要因になりがちです。基本に立ち返ると、うまくいく形は次の通りです。
- abc.comフォレスト：abc.com の権威ゾーンは保持。efg.com の権威ゾーンは保持しない。efg.com 宛は条件付きフォワーダーで新側へ。
- efg.comフォレスト：efg.com の権威ゾーンは保持。abc.com の権威ゾーンは保持しない。abc.com 宛は条件付きフォワーダーで旧側へ。
- 双方ともDNSは冗長化し、条件付きフォワーダーの転送先は複数台登録する。
- フォレスト信頼に必要なSRV（_msdcs配下）が確実に引けることを、信頼作成前にコマンドで検証する。
この構成は、設計が分かりやすく、障害時の切り分けも「どちらのフォレストに問題があるか」が見えやすいのが強みです。移行作業では“複雑さ”そのものがリスクになるため、DNSはなるべく素直な構造に寄せるのが結果的に成功率を上げます。
最終チェックリスト
- abc.com 側DNSに efg.com の権威ゾーンが残っていない（全DNSサーバーを確認）
- efg.com 側DNSに abc.com の権威ゾーンを作っていない
- 相互に 条件付きフォワーダーが設定済み（転送先DNSは冗長化）
- ネットワーク的に UDP/TCP 53 が疎通できる
- _ldap._tcp.dc._msdcs.abc.com / efg.com のSRVが双方から引ける
- Exchange/Autodiscoverなど、利用者影響のあるFQDNのレコードを新側へ移している
- 社内で利用する “公開ドメイン配下のWeb名” がある場合、内部DNS側のレコード整備も検討済み
まとめ：ゾーン競合を解消し、相互フォワードで信頼・移行を前に進める
「条件付きフォワーダーが作れない／効かない」の正体は、DNSの動作上とても典型的なゾーン競合です。特に今回のように、既存フォレストでメール運用の都合から移行先ドメインのゾーンを先に作ってしまっていると、フォレスト信頼の前提である名前解決が詰まりやすくなります。
対処の王道は、移行先ドメイン（efg.com）の権威は新フォレストへ集約し、旧フォレスト側は権威を捨てて条件付きフォワーダーで参照することです。これにより、フォレスト信頼の確立、DC探索、認証、移行ツールの動作が一気に安定します。削除が難しい場合も、スタブゾーン／セカンダリゾーンといった代替案を“設計として理解した上で”選べば、プロジェクトの停滞を防げます。
コメント