Windows Server 2012 R2 に DNS サーバーの役割を追加したのに、DNS マネージャーの「正引き参照ゾーン（Forward Lookup Zones）」が空のまま、_msdcs やローカルドメイン名のゾーンも見当たらない――。この状態は、構成によっては“正常な初期状態”です。この記事では、空の理由を整理しつつ、必要な場合に何を作るべきか、具体的な設定手順まで迷わない形で解説します。
まず結論：正引き参照ゾーンが空でも「異常」とは限らない
Windows Server 2012 R2 で DNS 役割を追加した直後、DNS マネージャーの「正引き参照ゾーン」が空なのは珍しくありません。理由はシンプルで、DNS サーバーは役割を入れただけでは自動で“社内ドメイン用のゾーン”を作らないからです。
この状態の DNS は、ざっくり言うと次のどちらかです。
- キャッシュ専用（Caching-only）DNS：自分ではゾーン（権威情報）を持たず、問い合わせを転送・再帰解決して結果をキャッシュする
- 権威 DNS（Authoritative DNS）：自分が管理するゾーンを持ち、A レコードなどの回答を自分で返す
DNS 役割を入れただけの初期状態は、基本的にキャッシュ専用 DNS に近い動きになります。したがって「正引き参照ゾーンが空＝まだ権威ゾーンを作っていない」だけ、というケースが多いです。
_msdcs が出てこない理由：Active Directory 連携 DNS の要素だから
_msdcs が自動で作られる（見える）代表的な場面は、Active Directory Domain Services（AD DS）を構成し、DNS を AD と統合して運用しているときです。
AD 環境では、クライアントがドメインコントローラー（DC）を見つけたり、レプリケーション関連の参照をしたりするために、DNS の SRV レコードなどが大量に使われます。そのため、AD 統合 DNS を構成すると、ドメイン名のゾーンや _msdcs に関連する領域（ゾーン）が自動的に作成・更新されます。
| 項目 | スタンドアロン DNS（AD なし） | AD 統合 DNS（ドメインコントローラー） |
|---|---|---|
| 正引き参照ゾーンの初期状態 | 空のことがある（正常） | ドメイン用ゾーンが自動作成されることが多い |
_msdcs | 出てこない（正常） | 表示・利用される（自動生成／更新される） |
| 主な役割 | 外部問い合わせの再帰解決、社内ゾーンを手動運用 | AD クライアントのドメイン参加、ログオン、DC 探索を DNS が支える |
| 動的更新 | 必要に応じて（管理方針次第） | セキュア動的更新が基本（推奨） |
つまり、AD DS を入れていない単体 DNS サーバーで _msdcs が見当たらないのは正常です。逆に、AD を本気で構築する予定があるのに _msdcs が無い／ゾーンが自動生成されない場合は、DNS の役割追加だけで止まっていて、ドメインコントローラーへの昇格（プロモーション）まで完了していない可能性を疑うべきです。
まずは状況を切り分ける：あなたの DNS サーバーは何をしたいサーバーか
「空のままでいいのか」「自分でゾーンを作るべきか」は、目的で決まります。最初にここを明確にすると迷いが消えます。
| 目的 | 正引き参照ゾーンは必要？ | 推奨する対応 | _msdcs は？ |
|---|---|---|---|
| インターネット閲覧など外部宛の名前解決だけしたい（社内ドメインなし） | 不要なことが多い | 空のままでも OK。フォワーダー設定を整える | 不要／出ないのが普通 |
社内向けに example.local などの内部名を解決したい | 必要 | プライマリ ゾーンを手動作成し、A/CNAME などを登録 | AD なしなら不要 |
| Active Directory ドメインを運用したい（DC を立てたい） | 必要（自動生成されやすい） | AD DS + DNS（AD 統合）を構成。セキュア動的更新 | 必要（自動で扱われる） |
| 既に別サーバーに AD/DNS があり、このサーバーは補助にしたい | ケース次第 | セカンダリ ゾーン／スタブ ゾーン／条件付きフォワーダーを検討 | 基本は既存 AD 側で管理 |
「空のままでOK」なケース：外部向け名前解決だけが目的のとき
Web サーバーやアプリサーバーとして運用していて、社内向けの独自ドメイン（例：example.local）をこの DNS で管理する必要がないなら、正引き参照ゾーンが空でも運用上の問題は起きません。
この場合に重要なのは、ゾーン作成ではなく名前解決の経路です。Windows DNS は、外部宛の名前解決を次のどちらかで行います。
- フォワーダー（Forwarders）：上位 DNS（社内の上位 DNS、ルータ、ISP の DNS、クラウド DNS など）に転送
- ルート ヒント（Root Hints）：インターネットのルート DNS からたどって再帰解決
安定しやすいのはフォワーダー
実務では、サーバーが外部に直接ルートから問い合わせできないネットワーク（プロキシや FW 制限など）も多く、ルート ヒントだけだと失敗することがあります。迷ったら、まずはフォワーダーを設定しておくのが無難です。
| 方式 | メリット | デメリット／注意点 | 向いている環境 |
|---|---|---|---|
| フォワーダー | 経路が単純で安定しやすい。社内ポリシー（フィルタリング等）も適用しやすい | フォワーダーが落ちると影響が出るため、複数設定が望ましい | 企業ネットワーク、閉域網、制限の多い環境 |
| ルート ヒント | 外部 DNS に依存しない（理論上は自己完結） | FW 制限や UDP/TCP 53 の制御で失敗しやすいことがある | インターネットへ制限なく出られる環境 |
フォワーダー設定手順（Windows Server 2012 R2）
- DNS マネージャーを開く
- 左ペインでサーバー名を右クリック →「プロパティ」
- 「フォワーダー」タブ →「編集」
- 上位 DNS の IP を追加（例：社内の上位 DNS、ISP の DNS、ルータの DNS）
- 可能なら 2 台以上登録し、冗長化する
上位 DNS が社内にあるならそれが最優先です。社内上位が無い場合は、ネットワーク設計に合わせて ISP の DNS などを使います（セキュリティポリシーがある場合はその方針に従ってください）。
「ゾーンを手動で作る」べきケース：内部向けの名前解決をこの DNS が担当するとき
社内のサーバー名やアプリ名を、独自のドメイン名で解決したい場合（例：intra.example.local、app01.example.local など）は、DNS サーバーを権威 DNSとして動かす必要があります。そのために行うのが、正引き参照ゾーンの作成です。
手動で作るのは「ドメインのゾーン」であり、_msdcs を無理に作ることではない
AD が無い環境で内部名解決をしたいだけなら、作るのは example.local（または社内で決めた名前）などのゾーンです。_msdcs は AD の仕組み（DC 探索やレプリケーションなど）に紐づくため、AD を使わないのに _msdcs だけを手作業で作っても意味が薄いどころか、後々の移行時に混乱の元になりがちです。
正引き参照ゾーン（プライマリ ゾーン）作成手順
- DNS マネージャーを開く
- 「正引き参照ゾーン」を右クリック →「新しいゾーン」
- 「プライマリ ゾーン」を選択
※このサーバーがドメインコントローラーでない場合、「Active Directory にゾーンを格納する」は選べません（スタンドアロン運用ならプライマリで正解です）。 - ゾーン名（例：
example.local、corp.exampleなど）を入力 - 動的更新の設定を選択
- 手動管理でよい →「動的更新を許可しない」
- DHCP 連携などで自動登録したい →「非セキュアとセキュア」
※AD 統合ではないため「セキュアのみ」は通常使えません。自動更新を許可する場合は、更新元の管理（DHCP の設定、ファイアウォール、権限）を慎重に行ってください。
- ウィザードを完了
レコード登録：まずは A レコードと CNAME から
ゾーンを作っただけでは、名前解決の中身が空なので答えられません。最低限、次のレコードを登録していきます。
| レコード種別 | 用途 | 例 | 実務でのポイント |
|---|---|---|---|
| A レコード | ホスト名 → IPv4 アドレス | app01 → 10.0.0.21 | まずこれが基本。サーバー固定 IP とセットで管理する |
| AAAA レコード | ホスト名 → IPv6 アドレス | app01 → 2001:db8::21 | IPv6 を使う環境のみ。使わないなら無理に作らない |
| CNAME | 別名 → 正式名 | intra → app01 | サーバー更改時に実体名を変えず、別名だけ差し替える運用が楽 |
| MX | メール配送先 | example.local → mail01 | 社内メールサーバーを扱う場合のみ |
登録手順は次の通りです。
- 作成したゾーン（例：
example.local）を開く - 右クリック →「新しいホスト（A または AAAA）」
- 「名前」と「IP アドレス」を入力して追加
- 必要に応じて「新しい別名（CNAME）」で別名を追加
逆引き参照ゾーンは必要？
逆引き参照ゾーン（Reverse Lookup Zones）は、必須ではありませんが、サーバー運用では作っておくと便利です。ログ解析や監査、メール関連の検証、トラブルシュート（IP から名前を辿る）で効きます。
| 項目 | 逆引き参照ゾーンなし | 逆引き参照ゾーンあり |
|---|---|---|
| 名前 → IP（正引き） | 可能 | 可能 |
| IP → 名前（逆引き） | できない／外部に頼る | できる（PTR レコード） |
| 運用上のメリット | 最低限の構成で済む | 調査・監視・ログ可読性が上がる |
作成する場合は「逆引き参照ゾーン」→「新しいゾーン」→ ネットワーク ID（例：10.0.0.0/24 なら 10.0.0）を指定し、PTR レコードを登録します。A レコード作成時に「関連付けられた PTR レコードを作成する」にチェックしておくと管理が楽です。
「本当は AD を構築したい」ケース：DNS 役割追加だけでは AD 用ゾーンは生まれない
もし目的が「ドメイン参加させたい」「グループポリシーを使いたい」「認証を AD に寄せたい」であれば、DNS のゾーンが自動で増えるのはAD DS の構成が完了した後です。
よくある勘違いとして、次の順序の途中で止まってしまうケースがあります。
- DNS 役割を追加した（ここで止まる）
- AD DS 役割を追加する
- サーバーをドメインコントローラーに昇格する（プロモーション）
- AD 統合 DNS としてゾーンやレコードが整う
つまり、DNS だけ入れた状態で _msdcs を探しても出てこないのは自然です。AD 用のゾーンや SRV レコードは、AD DS のセットアップ（新規フォレスト作成／既存ドメイン参加／DC 追加）に連動して作られていきます。
_msdcs を「手作業で作成」するのは推奨しない
「表示されないなら新しいゾーンで _msdcs を作ればいいのでは？」と思いがちですが、AD がない状態で形だけ作っても、DC locator に必要な SRV レコード群や、AD と整合した更新が自動で回るわけではありません。AD を使うなら、設計（ドメイン名、DNS 構成、冗長化、運用手順）を固めた上で、AD DS のウィザードに任せて自動生成させるのが結果的に安全です。
動作確認：DNS が答えているかをコマンドで検証する
DNS は GUI の見た目よりも、実際に問い合わせた結果がすべてです。ゾーン作成後やフォワーダー設定後は、最低限ここまで確認しておくと安心です。
nslookup（最小の確認）
nslookup
> server 127.0.0.1
> www.microsoft.com
> app01.example.local
server 127.0.0.1で「自分自身の DNS サービス」へ問い合わせを固定できます- 外部名（例：
www.microsoft.com）が引けるなら、フォワーダー／ルートヒント経由の解決が動いている可能性が高いです - 内部名（例：
app01.example.local）が引けるなら、正引きゾーン＋レコードが効いています
Resolve-DnsName（PowerShell で記録に残しやすい）
Resolve-DnsName app01.example.local
Resolve-DnsName www.microsoft.com
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.example.local
最後の SRV の例は、AD を構成した環境で使う典型的な確認です。AD がない環境では当然失敗して構いません（その失敗自体が「まだ AD 用 DNS ではない」ことの確認になります）。
よくある落とし穴：ゾーンを作っても名前解決が安定しない原因
正引き参照ゾーンを作ったのにクライアントが解決できない、外部が引けない、という場合は、DNS のレコード以外に原因があることが多いです。現場で遭遇しやすいポイントをまとめます。
| 症状 | よくある原因 | 確認・対処の方向性 |
|---|---|---|
| クライアントから内部名が引けない | クライアントの DNS 設定が別の DNS を向いている | クライアントの IPv4 DNS をこの DNS サーバーに向ける（DHCP 配布含む） |
| この DNS サーバー自身が外部名を引けない | フォワーダー未設定／FW が 53 番をブロック／ルートヒント経路が不可 | フォワーダー設定、FW/UTM の許可、名前解決経路の整理 |
| 内部ゾーンを作ったら、一部の外部サイトに行けなくなった | パブリックと同名のゾーンを内部に作成し、必要なレコードが不足（スプリット DNS の不完全） | 同名ゾーン運用は設計が必要。内部で必要なレコードを揃えるか、名前設計を見直す |
| 名前解決が遅い | フォワーダーが遠い／死んでいる／タイムアウトが多い | フォワーダーを複数設定、死活監視、近い上位 DNS の利用 |
| ドメイン参加やログオンが不安定 | AD 環境なのに DNS が AD と整合していない（SRV 不足など） | AD 統合 DNS の構成確認、DC の DNS 設定見直し、SRV レコード確認 |
DNS サーバー自身の NIC の DNS 設定にも注意
Windows Server が DNS サーバーとして動く場合、サーバー自身のネットワーク設定（優先 DNS）も意外と重要です。
- この DNS が内部ゾーンの権威なら：優先 DNS を自分自身（自サーバーの IP）にするのが基本
- 冗長 DNS があるなら：代替 DNS にもう 1 台の DNS を設定（同一環境内）
- 「代替 DNS に外部 DNS」を安易に入れると：内部名が引けないタイミングが出たり、AD 環境では障害要因になったりすることがあります
目的が「外部解決のみ」のキャッシュ用途なら設計の自由度は高いですが、AD を絡めるなら DNS 設定は慎重に統一した方が安全です。
既に社内に DNS/AD がある場合：このサーバーをどう位置づけるか
「このサーバーに DNS 役割を入れたけど、本当は社内に上位 DNS（あるいは DC）がいる」という構成も多いです。その場合、正引き参照ゾーンをこのサーバーにベタベタ作るより、目的に応じて次の選択肢を検討すると運用が楽になります。
| 選択肢 | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| 条件付きフォワーダー | 特定ドメインだけ指定 DNS に転送 | 社内ドメインは社内 DNS に任せ、外部は別経路にしたい | 転送先の冗長化を忘れない |
| セカンダリ ゾーン | マスターのゾーンを複製して保持 | 読み取り専用で分散したい、応答を近くしたい | ゾーン転送の設計・許可が必要 |
| スタブ ゾーン | 委任情報など最小限だけ保持 | 大規模環境で参照経路を整理したい | 設計難度はやや高い |
「ただの単体 DNS」として使うのか、「社内 DNS 階層の一部」として使うのかで、最適解が変わります。逆に言えば、用途が決まれば “正引き参照ゾーンが空かどうか” は問題の本質ではなくなります。
まとめ：空でも正常。必要なら“目的に沿って”作る
- DNS 役割を追加した直後に「正引き参照ゾーン」が空でも、スタンドアロン DNS では正常なことがある
_msdcsは主にActive Directory（AD）連携の DNS（AD 統合 DNS）で扱われる領域で、AD DS が無ければ出てこないのが普通- 社内向けに名前解決をさせたいなら、正引きゾーン（プライマリ ゾーン）を手動で作成し、A/CNAME などを登録する
- 内部ゾーンが不要なら、空のままでも問題ない。外部解決はフォワーダーやルートヒントで行える（実務ではフォワーダーが安定しやすい）
- 「本当は AD を構築したい」なら、DNS 役割追加だけで止めず、AD DS 構成（DC 昇格）まで完了させる
コメント