MENU

Windows Server 2019/2016 DNS条件付きフォワーダーを複数サーバーで自動同期する方法｜自動レプリケーション不可の理由とPowerShell配布

Windows Server

Windows Server 2019のDNSキャッシュサーバーを冗長化していると、条件付きフォワーダーの追加・変更を全台に反映する作業が地味に重くなります。本記事では「自動レプリケーションは可能か？」の結論と、ミスなく揃える現実的な運用（PowerShell配布／AD統合の選択肢）を整理します。

目次

結論：スタンドアロンDNSキャッシュサーバー間では「条件付きフォワーダー」の自動レプリケーションはできない

先に結論です。Windows Server 2019／2016のDNSサーバー（いわゆるキャッシュDNS、スタンドアロンDNS）を複数台並べても、条件付きフォワーダー（Conditional Forwarder）の設定を自動で同期（レプリケーション）する標準機能は用意されていません。

そのため、冗長構成のDNSキャッシュサーバーに条件付きフォワーダーを追加する場合は、次のどれかで「同じ結果になるように揃える」運用が必要です。

  • 全台に手動で同じ設定を入れる
  • PowerShellなどで同じ設定を配布して自動化する（現実的な推奨）
  • DNSがActive Directory統合（AD統合DNS）として動作できる構成なら、条件付きフォワーダーをADに保存してAD複製に乗せる

そもそも条件付きフォワーダーとは：通常のフォワーダーとの違い

「条件付きフォワーダー」と「通常のフォワーダー（既定のフォワーダー）」を混同すると設計がぶれます。簡単に整理しておきます。

項目条件付きフォワーダー（Conditional Forwarder）通常のフォワーダー（Forwarder）
適用範囲指定したドメイン（例：contoso.local）への問い合わせだけそれ以外も含む「外部宛ての問い合わせ全般」（設計による）
用途の例拠点間・社内外の別DNS（子会社/グループ会社/委託先）へ名前解決を委譲インターネット名前解決を上位DNSやプロキシ的DNSへ中継
設定対象ドメイン単位で複数定義できるサーバー全体で1セット（複数指定は可能）
冗長構成での注意点DNSサーバーごとに設定が必要。揃っていないと名前解決が揺れる同様に揃える必要があるが、条件付きの方が「追加/変更頻度が高い」ことが多い

条件付きフォワーダーは「特定の名前空間だけを別系統のDNSへ投げる」機能なので、企業ネットワークではとても便利です。一方で、冗長化したDNSキャッシュサーバーに同じ設定を揃えないと、問い合わせ先DNSが切り替わった瞬間に挙動が変わるため、運用が地味に難しくなります。

なぜ自動同期できないのか：保存先と複製メカニズムを整理

「DNSサーバーを2台にしたら、DNSの設定も勝手に同期されるはず」と思いがちですが、Windows DNSの複製は基本的にActive Directoryの複製（ADレプリケーション）に依存します。逆に言えば、ADの複製に乗っていない設定は、勝手には揃いません。

構成条件付きフォワーダーの保存先自動同期ポイント
スタンドアロンDNS（キャッシュDNS、非AD統合）各DNSサーバーのローカル設定不可サーバー単体の構成として保持されるため、他サーバーへ伝播しない
AD統合DNS（DNSがAD DSと統合され、ADへ保存）Active Directory（DNSアプリケーションパーティション等）可「ADに保存する」前提で、ADの複製で結果的に同期される
同一サーバー上のバックアップ/リストアバックアップファイル条件付き別サーバーへの自動配布ではなく、移行・復旧用途の話

つまり、質問の前提である「冗長構成のDNSキャッシュサーバー（非AD統合）」では、条件付きフォワーダーを“自動レプリケーション”する仕組みはありません。同じ設定を複数台へ配布して揃える、という発想に切り替えるのが現実解です。

設定が揃っていないと何が起きる？冗長DNSでの典型的なトラブル

条件付きフォワーダーは、クライアントが参照するDNSサーバーが切り替わるだけで挙動が変わります。例えばDHCPで「優先DNS／代替DNS」を配り、クライアントが状況によりどちらも参照する構成では、次のような症状が起きがちです。

  • あるクライアントは名前解決できるのに、別のクライアントは同じFQDNが引けない
  • 同じクライアントでも、時間帯やネットワーク状況で解決可否が揺れる
  • アプリケーション側では「断続的な接続失敗」「タイムアウト」として見え、原因特定が難しい

特に、拠点間VPNや閉域網で接続される相手先DNSに転送する場合は、片側のDNSだけ条件付きフォワーダーが未設定という状態が最悪です。利用者からすると「たまに落ちる」現象になり、ネットワーク・サーバー・アプリのどこが原因か判別しづらくなります。

対応策の全体像：現場で選ばれる3パターン

冗長DNSキャッシュサーバーで条件付きフォワーダーを揃える方法は、大きく3つです。まず比較表で押さえましょう。

方法運用コストミス耐性変更頻度が高い環境おすすめ度
手動で全台に設定高い（都度作業）低い（入れ忘れ・表記揺れ）不向き小規模なら可
PowerShell/自動化で配布（同じ設定を投入）中（最初に整備、以降は軽い）高い（再実行で揃う）向く推奨
AD統合DNSへ寄せてAD複製を使う構成変更が大きい高い（AD複製）向く条件が合えば強い

対応策：手動で同じ条件付きフォワーダーを設定する

最もシンプルなのは、DNSマネージャー（dnsmgmt.msc）で各サーバーに同じ条件付きフォワーダーを追加する方法です。台数が2台で、変更が年1回程度なら現実的です。

手動運用で最低限守りたいチェックリスト

  • 追加・変更した「ゾーン名（転送対象ドメイン名）」が全台で一致している
  • 転送先（マスターサーバー）のIPアドレスが全台で一致している（順番も揃えると比較が楽）
  • IPv4/IPv6を混在させる場合は、どちらを使うかの方針を決めておく
  • 変更履歴（いつ、誰が、何を、なぜ変更したか）を残す

手動は「最初は早い」反面、変更が積み重なると確実に破綻します。入れ忘れの検知もしづらいので、冗長DNSキャッシュサーバーを運用するなら、次の自動化を検討する価値が高いです。

対応策：PowerShellで条件付きフォワーダーを配布する（推奨）

スタンドアロンDNS同士で自動レプリケーションができないなら、“同じ定義”を各サーバーに適用し、結果として同一状態にするのが王道です。ポイントは「都度作業」ではなく、何度実行しても同じ結果になる（idempotent）ように作ることです。

前提（例）

  • DNSキャッシュサーバー：DNSCACHE01 / DNSCACHE02（Windows Server 2019）
  • 追加したい条件付きフォワーダー：contoso.local → 10.0.0.10, 10.0.0.11
  • 条件付きフォワーダーはADに保存しない（スタンドアロン運用）

基本コマンド例：1つの条件付きフォワーダーを追加する

まずは単発で追加する形です。質問の内容に近い形で示します。

# contoso.local を指定DNSへ転送する条件付きフォワーダーを追加
Add-DnsServerConditionalForwarderZone `
  -Name "contoso.local" `
  -MasterServers 10.0.0.10,10.0.0.11 `
  -ReplicationScope "None"

-ReplicationScope “None” は「Active Directoryに保存しない」という意味合いで、スタンドアロンDNSキャッシュサーバーではこの指定が基本になります。

定義ファイルを「正」にする：CSVで管理する例

条件付きフォワーダーが増えてくると、スクリプトに直書きは管理しづらくなります。そこで、定義をCSVにし「CSVが正、DNSは結果」という形にします。

# C:\Ops\conditional-forwarders.csv
ZoneName,MasterServers,Note
contoso.local,"10.0.0.10;10.0.0.11",Contoso向け
partner.example,"172.16.1.53;172.16.1.54",取引先向け

同期スクリプト例：存在確認→追加/更新して揃える

次のスクリプトは、CSVを読み込んで、条件付きフォワーダー（ZoneType=Forwarder）が無ければ追加、あれば転送先を更新します。何度実行しても状態が揃うため、運用で強い形になります。

# C:\Ops\Sync-ConditionalForwarders.ps1
[CmdletBinding()]
param(
    [Parameter(Mandatory=$false)]
    [string]$CsvPath = "C:\Ops\conditional-forwarders.csv"
)

# CSV読み込み
$defs = Import-Csv -Path $CsvPath

foreach ($def in $defs) {
    $zoneName = $def.ZoneName.Trim()
    $masters  = $def.MasterServers.Split(';') | ForEach-Object { $_.Trim() } | Where-Object { $_ -ne "" }

    if (-not $zoneName) { continue }
    if ($masters.Count -eq 0) { throw "MasterServersが空です: $zoneName" }

    # 既存確認（条件付きフォワーダーは ZoneType が Forwarder）
    $existing = Get-DnsServerZone -Name $zoneName -ErrorAction SilentlyContinue

    if (-not $existing) {
        Write-Host "ADD  : $zoneName => $($masters -join ',')"
        Add-DnsServerConditionalForwarderZone -Name $zoneName -MasterServers $masters -ReplicationScope "None" | Out-Null
        continue
    }

    # 既存がある場合：条件付きフォワーダー以外（プライマリ等）を誤って触らない
    if ($existing.ZoneType -ne "Forwarder") {
        Write-Warning "SKIP : $zoneName は条件付きフォワーダーではありません（ZoneType=$($existing.ZoneType)）"
        continue
    }

    # 設定差分を見て必要なら更新
    $currentMasters = @($existing.MasterServers) | ForEach-Object { $_.ToString() }

    $needUpdate = ($currentMasters.Count -ne $masters.Count) -or (@(Compare-Object -ReferenceObject $currentMasters -DifferenceObject $masters).Count -gt 0)

    if ($needUpdate) {
        Write-Host "UPDATE: $zoneName => $($masters -join ',')"
        Set-DnsServerConditionalForwarderZone -Name $zoneName -MasterServers $masters
    } else {
        Write-Host "OK   : $zoneName"
    }
}

ポイントは次のとおりです。

  • 「あるなら上書き、ないなら追加」に寄せて、手戻りをなくす
  • 誤ってプライマリゾーン等を更新しないようにZoneTypeをチェックする
  • 定義ファイル（CSV）を見れば、意図した条件付きフォワーダーが一目で分かる

複数DNSサーバーへ一括適用する方法

スクリプトができたら、次は「どう配るか」です。方法はいくつかあります。規模や権限設計に合わせて選びます。

配布方法特徴向く規模注意点
手動実行（RDP/コンソール）まず動かすなら最短小規模結局、人がやるので属人化しやすい
PowerShellリモート（Invoke-Command）管理端末から複数台へ一括実行できる小～中規模WinRM/権限/通信許可の整備が必要
GPOのスタートアップスクリプトサーバー起動時に自動で揃うドメイン環境実行ログの取り方と失敗時の検知が重要
タスクスケジューラ（定期実行）日次/時間単位でドリフトを戻せる小～大規模サービスアカウントの権限と監査を設計する
構成管理（DSC/Ansible/SCCM等）インフラ全体のあるべき姿に組み込める中～大規模導入・学習コストは高め

例えば、管理端末から2台へ一括適用する最小例は次のようになります。

$servers = @("DNSCACHE01","DNSCACHE02")
Invoke-Command -ComputerName $servers -FilePath "C:\Ops\Sync-ConditionalForwarders.ps1"

設定が正しく揃ったかを確認する（例）

適用後は「揃ったこと」を機械的に確認できると強いです。最低限、条件付きフォワーダー一覧と転送先を確認します。

# 条件付きフォワーダー（ZoneType=Forwarder）だけを表示
Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Forwarder" } |
  Select-Object ZoneName, MasterServers |
  Format-Table -AutoSize

疎通確認としては、転送対象ドメインの名前解決を実際に投げ、DNSCACHE01とDNSCACHE02で同じ結果になるかを確認します。

Resolve-DnsName "host1.contoso.local" -Server "DNSCACHE01"
Resolve-DnsName "host1.contoso.local" -Server "DNSCACHE02"

PowerShell運用を失敗させないコツ：現場で効く設計ポイント

条件付きフォワーダー配布を「自動化したのに結局トラブルが減らない」ケースは、だいたい運用設計に原因があります。よく効くポイントをまとめます。

「正」の置き場所を決める（ソースオブトゥルース）

  • CSV/JSONを共有フォルダに置く（アクセス制御・監査ログを残す）
  • Gitなどで定義ファイルをバージョン管理し、PRレビューで変更を通す
  • 「本番反映前にテスト環境で適用→確認」をルール化する

削除は慎重に（特に初期は“追加/更新のみ”にする）

「定義に無い条件付きフォワーダーを消す」機能は便利ですが、移行途中や一時的な検証用途が混ざっていると事故につながります。初期は追加/更新のみで回し、運用が落ち着いてから削除（ドリフト修正）を段階的に入れるのが安全です。

ログを残す（誰がいつ何を変えたか）

スクリプトの標準出力をファイルへ出し、結果を追えるようにします。例えばタスクスケジューラで実行する場合は、出力先をC:\Ops\Logsのように固定し、ローテーションも検討します。

変更時に最低限確認すべきポイント

確認項目理由簡易チェック例
ゾーン名の誤り（typo）一文字違いで別設定として追加される定義ファイルをレビュー、適用後の一覧を比較
転送先IPの誤り存在しないIPだとタイムアウトが増えるping/疎通、Resolve-DnsNameで応答確認
複数DNSで同一状態か冗長の意味が薄れるGet-DnsServerZoneの結果を突き合わせ
相手先DNSの冗長性転送先が単一だと単一障害点になるMasterServersを2台以上指定

補足：AD統合DNSなら条件付きフォワーダーをADに保存して複製できる

「自動レプリケーションが欲しい」という要件だけを見ると、AD統合DNSの考え方は強力です。条件付きフォワーダーを追加する際にActive Directoryに保存できる構成であれば、ADの複製によって複数のDNSサーバー（通常はDNS役割を持つドメインコントローラー）へ設定が行き渡ります。

ADに保存できる場合のイメージ

  • DNSサーバーがドメインコントローラー（またはAD統合DNSとして扱える構成）である
  • 条件付きフォワーダー作成時に「ADに保存して複製する」選択肢が使える
  • 複製スコープ（フォレスト全体／ドメイン内など）を設計できる

ただし、質問の前提どおり「DNSキャッシュサーバー（非AD統合）同士」で冗長化している場合、AD複製に乗せる方法は使えません。この場合は、前述のPowerShell配布が現実的な落としどころになります。

Windows Server 2016でも同じ？

はい、考え方は同じです。Windows Server 2016でも、スタンドアロンDNSサーバー同士で条件付きフォワーダーを自動同期する標準機能はありません。AD統合DNSとしてADに保存できる構成ならAD複製で同期できますが、非AD統合のDNSキャッシュサーバー間では「配布して揃える」運用になります。

よくある質問

ゾーン転送（Zone Transfer）で条件付きフォワーダーを複製できませんか？

一般的なプライマリ/セカンダリゾーンのような「ゾーン転送」の文脈とは別物です。条件付きフォワーダーは“特定ドメイン宛ての問い合わせをどこへ転送するか”というサーバー設定であり、スタンドアロンDNS間で勝手に伝播する仕組みとしては提供されていません。

DNSサーバーをWindows Failover Clusterで冗長化すれば同期の問題は消えますか？

DNS役割自体の冗長化・可用性設計は別途検討できますが、条件付きフォワーダーの「設定をどう管理するか」という論点は残ります。単に台数を増やしても自動で揃わない前提は変わらないため、構成管理（自動化）を合わせて設計するのが確実です。

PowerShellでの配布が怖いです。まず何から始めればいいですか？

最初は次の順番がおすすめです。

  1. 現状の条件付きフォワーダー一覧をPowerShellで取得し、CSVに落とす
  2. テスト環境で「追加/更新のみ」の同期スクリプトを作る
  3. 2台のDNSサーバーで同じ結果になることを確認してから本番に展開する

まとめ：自動レプリケーションがない前提で“自動化”するのが最短ルート

Windows Server 2019/2016のDNSキャッシュサーバーを冗長化しても、スタンドアロンDNS同士で条件付きフォワーダーを自動レプリケーションする仕組みはありません。だからこそ、運用では次のどちらかに寄せるのが現実的です。

  • 変更が少ないなら手動でも回せるが、チェックリストと記録は必須
  • 変更が増える・台数が増えるなら、PowerShellで定義を配布し、再実行で揃う運用にする

「自動同期できるか？」という問いに対しては否定が答えになりますが、実務では“自動化で同一状態にする”ことで、結果として同期と同等の品質を作れます。DNSは地味ですが、揺れると影響範囲が広い領域です。条件付きフォワーダーを追加するタイミングで、ぜひ運用の型まで一緒に整備しておくことをおすすめします。

Windows Server
DNS Active Directory PowerShell Windows Server 条件付きフォワーダー

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次