Windows Server 2012 R2のドメイン参加で「DNS名が存在しません」：_ldap._tcp.dc._msdcs（SRVレコード）エラーの原因と解決策

Windows Server 2012 R2で初めてActive Directory（AD DS）を構築し、同じサーバーにDNSとDHCPも入れたのに、クライアントPCが「DNS名が存在しません」でドメイン参加できない。多くの場合、原因は“AD用DNSに正しく問い合わせできていない”か“SRVレコードが登録されていない”のどちらかです。現場で最短復旧するための確認手順を、具体例つきで整理します。

起きている現象：インターネットは見えるのにドメイン参加だけ失敗する

今回の状況は、初期構築時に非常によく遭遇します。DHCPでIPアドレスは配布され、Web閲覧などもできているため「ネットワークは正常に見える」のに、ドメイン参加だけが失敗します。

見える症状	裏で起きている可能性	まず疑うべきポイント
DHCPでIPが取れている	IP配布は正常、ただしDNS配布が誤っていることがある	DHCPのOption 006（DNSサーバー）
Web閲覧・外部名前解決はできる	パブリックDNSに問い合わせているだけで、社内DNSを使っていない	クライアントの「優先DNS」がDCのIPか
ドメイン参加で「DNS名が存在しません」	ADが必要とするDNS SRVレコードが見つからない	_ldap._tcp.dc._msdcs.<ドメイン> のSRV

エラーメッセージの要点は、クライアントがDNSに対して次のような問い合わせを行い、答えが返ってこないことです。

_ldap._tcp.dc._msdcs.Folly.Office のSRVレコードが見つからない

原因の本質：Active Directoryは「DNS SRVレコード」でドメインコントローラーを探す

ドメイン参加やドメインログオンでは、クライアントはまず「このドメインのドメインコントローラー（DC）はどこ？」を探します。その探索に使われるのが、DNSのSRVレコードです。

特にドメイン参加時に重要なのが、次の問い合わせです。

• _ldap._tcp.dc._msdcs.<ドメイン名>（DCを探すためのSRV）
• _kerberos._tcp.<ドメイン名>（Kerberos関連）

つまり、クライアントが参照しているDNSが「社内のAD DNS（=DCのDNS）」ではなく、ルーターや8.8.8.8などの外部DNSになっていると、外部DNSには当然SRVレコードが存在しないため、“DNS名が存在しません”となります。

一方で、クライアントが正しく社内DNSを見ていても、DNSゾーンの作り方や動的更新の設定が原因で、そもそもSRVレコードがDNSに登録されていないケースもあります。次章から、復旧優先度の高い順に確認します。

最優先：クライアント／DCのDNS設定を正す（ここがズレると100%詰まる）

クライアントPCの「優先DNSサーバー」はDCのIPだけにする

ドメイン参加させたいクライアントPCは、優先DNSサーバーにDC（DNSサーバー）のIPアドレスだけを設定してください。混在が一番危険です。

端末	優先DNS（OK）	代替DNS（OK）	よくあるNG例
クライアントPC	192.168.1.16（DCのIP）	（2台目DCがある場合のみ）2台目DNS	8.8.8.8 / 1.1.1.1 / ルーターIPを混在
ドメインコントローラー（DC）	自分自身（192.168.1.16 または 127.0.0.1）	（2台目DCがある場合のみ）2台目DNS	優先DNSに外部DNSを設定

重要な考え方：クライアントが外部DNSを引いても、インターネットは解決できるので「ネットは普通に見える」状態になります。しかしADが必要とするSRVレコードは社内DNSにしかありません。ここで見に行く先がズレていると、何をしてもドメイン参加は成功しません。

DNS設定を変えたら、クライアント側でDNSキャッシュを消してから再試行すると切り分けが早くなります。

ipconfig /flushdns

「代替DNSにパブリックDNS」はなぜダメなのか

代替DNSは、優先DNSが応答しない場合に参照されます。ADの局面で代替DNSに外部DNSを入れると、タイミング次第でクライアントが外部DNSへ問い合わせてしまい、SRVレコードが無いので失敗します。しかも失敗の再現性が不安定になり、「さっきは動いたのに今はダメ」という沼に入りがちです。

どうしても冗長化したい場合は、2台目のDC兼DNSを用意し、代替DNSには2台目の内部DNSを設定するのが基本です。

外部名前解決が必要なら「DNSフォワーダー」を使う

「クライアントが外部DNSを使えないと、インターネット名前解決ができないのでは？」と心配になるかもしれませんが、やり方は逆です。

• クライアントは常に社内DNS（DC）を参照する
• 社内DNS（DC）が外部ドメインの解決をする必要がある場合、DNSフォワーダーで上位（ルーターやISP、パブリックDNS）へ転送する

これにより、クライアントはAD用レコードも外部サイトの名前解決も、すべて社内DNS経由で安定して解決できます。

DHCP配布のDNS設定を確認：Option 006が外部DNSになっていないか

「クライアントにDHCPでIPが正しく配られている」ときほど、DHCPが配っているDNS情報が盲点になります。特に次の2つは確認価値が高いです。

DHCPオプション	意味	正しい値の例	ズレていると起きやすい問題
006 DNS Servers	クライアントが参照するDNSサーバー	192.168.1.16（DC）	SRVレコードが引けずドメイン参加失敗
015 DNS Domain Name	接続固有のDNSサフィックス	Folly.Office（環境に合わせる）	短縮名解決や一部の探索が不安定

クライアント側では、次で実際に受け取っているDNSサーバーを確認できます。

ipconfig /all

ここで「DNSサーバー」欄がDCのIPではない、またはDCのIPと外部DNSが混在している場合は、まずDHCPを正してリース更新を行います。

ipconfig /release
ipconfig /renew
ipconfig /flushdns

DNSゾーンとSRVレコードの状態を確認する：_msdcs / _tcp / _udp が存在するか

DNS設定が正しいのにSRVレコードが引けない場合、次はDNSサーバー側にSRVレコードが登録されているかを確認します。Windows Server 2012 R2でDNSを導入しているなら、DNSマネージャーで以下を見ます。

• DNSマネージャー → フォワード ルックアップ ゾーン
• Folly.Office（ドメイン名のゾーン）があるか
• ゾーンの中に_sites / _tcp / _udpなどのフォルダー（レコード群）があるか
• 別ゾーンとして_msdcs.Folly.Officeが存在するか（環境により表示形態が異なる）

正常なAD DNSでは、概ね次のようなレコード群が見えます（表示名は環境により差があります）。

レコード／フォルダーの例	役割	これが無いとどうなるか
_msdcs	DC探索などで重要な領域（SRVがまとまる）	DCが見つからずドメイン参加・ログオンが不安定
_tcp	TCP系サービス（LDAP, Kerberos等）のSRV	LDAP/Kerberos探索に失敗
_udp	UDP系サービスのSRV	関連する探索が失敗する場合がある
_ldap._tcp.dc._msdcs.<ドメイン>	DCを見つけるためのSRVレコード	ドメイン参加で「DNS名が存在しません」

コマンドでSRVレコードを直接確認する（最短で事実確認できる）

クライアントまたはDCで、次の問い合わせが成功するかを見ます。

nslookup -type=SRV _ldap._tcp.dc._msdcs.folly.office

期待されるのは、SRVのターゲットとしてDC名（例：DC01.folly.office）が返ってくることです。もし「Non-existent domain」や「見つかりません」となるなら、DNSゾーン内にSRVレコードが無いか、クライアントが参照しているDNSが違うかのどちらかです。

同時に、クライアントが参照しているDNSサーバーが想定通りかも確認します。

nslookup
server

表示された「Default Server」がDCになっていない場合は、DNS設定（固定設定 or DHCP配布）に戻って修正します。

「_msdcsが無い／SRVが無い」場合の復旧パターン

質問のケースでは、DNSゾーン内に_msdcsや_sites等のフォルダーが作られておらず、結果としてSRVレコードが登録されていませんでした。ここは原因が2系統あります。

原因パターン	起こりがちな経緯	典型症状	基本対処
ゾーンを手動で先に作ってしまった	DC昇格前にFolly.Officeゾーンを作成	フォルダーが無い／SRVが無い	ゾーン再作成 or 自動再登録を実行
動的更新が無効／不整合	非AD統合ゾーン、更新拒否、権限問題	一部だけ登録されない	ゾーンの動的更新設定確認、再登録

復旧案A：DNSゾーンを作り直して「ADに自動生成」させる

最も分かりやすく、構成がシンプルな環境では効果が高い方法です。質問者が解決したのもこのアプローチです。

• DNSマネージャーで、該当のフォワードルックアップゾーン（例：Folly.Office）を確認
• 必要に応じてバックアップ（エクスポート）を取る
• ゾーンを削除し、AD DS/DNSの想定どおりに再作成（または昇格手順に沿って自動生成）
• 作成後、_msdcs / _tcp / _udpなどのSRV関連が生成されるか確認

注意点：DNSゾーン削除は、短時間でも名前解決に影響します。作業は利用者の少ない時間帯に行い、DHCP配布先がこのDNSだけである場合は特に慎重に進めてください。

復旧案B：dcdiag /fix と NetLogon再起動でSRVを再登録する

「ゾーン再作成は避けたい」「構成としては正しいはずだがSRVが欠けている」という場合は、DCにSRV登録をやり直させます。代表的な手順が以下です。

DC上で実行：

dcdiag /fix

続けて、NetLogonサービスを再起動（これでSRVレコードの再登録が走ります）。

net stop netlogon
net start netlogon

さらに確実にするなら、DNS登録を促します。

ipconfig /registerdns

実行後は、DNSマネージャーでSRVレコード（_msdcs配下）が生成されているか、または次のnslookupが通るかを確認します。

nslookup -type=SRV _ldap._tcp.dc._msdcs.folly.office

復旧案C：ゾーンの設定（動的更新）と権限を見直す

ゾーンが存在しても、動的更新が無効だとSRVレコードが増えません。DNSマネージャーでゾーンのプロパティを開き、次を確認します。

• ゾーンの種類：可能ならActive Directory統合
• 動的更新：可能ならセキュリティで保護された動的更新のみ（構築直後でも基本はこれ）
• ゾーンが複数存在して競合していないか（同名ゾーンの二重管理）

「インターネット名は引けるのにSRVが無い」という状況では、ゾーンそのものがAD向けに整っていないことが多いので、ここまで確認すると原因が見えやすくなります。

動作確認に使えるコマンド：失敗原因を短時間で絞る

ドメイン参加エラーは、手当たり次第に設定を触ると時間が溶けます。まずは事実（いま何が引けて何が引けないか）をコマンドで押さえるのが近道です。

コマンド	実行場所	確認ポイント	よくあるNG結果
ipconfig /all	クライアント	DNSサーバーがDCのIPのみか	ルーターIPや8.8.8.8が混在
ping 192.168.1.16	クライアント	DCへL3疎通できるか	到達不可（ネットワーク/ACL問題）
ping dc01	クライアント	ホスト名解決が社内DNSでできるか	名前解決不可（DNS参照先違い）
nslookup folly.office	クライアント	ドメイン名が社内DNSで引けるか	外部DNSに問い合わせて失敗
nslookup -type=SRV _ldap._tcp.dc._msdcs.folly.office	クライアント/DC	DC探索SRVが返るか	SRVが見つからない（今回の核心）
nltest /dsgetdc:folly.office	クライアント	ドメインコントローラーを発見できるか	DCが見つからない/エラー
dcdiag /test:dns	DC	DNS関連の診断結果	SRV登録やゾーン問題を指摘

特にnslookupでSRVが返るかと、nltestでDCが見つかるかの2つは、ドメイン参加に直結する検査です。ここが通るようになれば、ドメイン参加は成功に近づきます。

ドメイン参加手順のおさらい：正しい順番でやるとハマりにくい

DNSが正しく整った前提で、改めて王道の手順を押さえます。特に「参加作業の直前」にDNS設定が崩れていないかを確認するのがポイントです。

1. クライアントPCにローカル管理者でログオン
2. ネットワーク設定で、優先DNSサーバーにDCのIPを設定（DHCP運用でも一度確認）
3. 必要なら ipconfig /flushdns を実行
4. 「システムのプロパティ」→「コンピューター名」→「変更」→ドメインに Folly.Office を入力
5. ドメイン管理者の資格情報を入力
6. 再起動後、ドメインユーザーでログオン確認

追加の落とし穴：DNSが直っても再発しやすいポイント

今回のエラーはDNS起因が中心ですが、現場では「直したはずなのに翌日また不安定」というケースもあります。再発防止の観点で、次の点も一緒に整えると安定します。

DCが複数NIC／仮想環境のときは、DNS参照先が混線しやすい

• 未使用NICに外部DNSが残っている
• 仮想スイッチやNAT側のDNSが優先される
• アダプターの優先順やDNSサフィックスが想定外になっている

ipconfig /allの結果で、DNSサーバーが想定通りか、接続固有のDNSサフィックスが想定通りかを定期的に確認すると、早期に気づけます。

インターネット名前解決は「クライアントに外部DNS」ではなく「サーバーのフォワーダー」

クライアントに外部DNSを混在させる運用は、ドメイン参加だけでなく、将来のグループポリシー適用やログオン、ファイル共有アクセスの不安定化にもつながります。外部向け解決はDNSフォワーダーで吸収し、クライアントは社内DNS固定という形が、最もトラブルが少ないです。

ドメイン名が外部TLD（.office等）の場合は、社内DNSが常に優先される設計にする

.officeのように外部でも使われるTLDは、社内DNSが参照されない瞬間に外部解決へ流れやすくなります。社内では問題なくても、VPNや別セグメントなどネットワークが増えると差が出やすいので、将来拡張を見越すなら「社内DNSへ必ず向く」構成（DHCP/固定設定の統一、複数DNSの冗長化）を早めに固めておくと安心です。

再発防止の運用メモ：小規模でも効くチェックリスト

「一度直ったのに、数か月後にPC追加でまた詰まった」を避けるための運用ポイントです。

項目	推奨	理由
クライアントDNS	内部DNS（DC）のみ	SRV探索が安定し、ドメイン参加/ログオンがブレない
DNSフォワーダー	ルーター/ISP/パブリックDNSを設定	社内DNS経由で外部も解決でき、設定の一元化ができる
DHCP Option 006	内部DNSのみを配布	PC追加・入替時も自動で正しいDNSになる
定期点検	dcdiag /test:dns を実行	SRV登録不備やゾーン異常を早期発見できる
冗長化	可能なら2台目DC/DNS	DNS停止＝ドメイン停止を避けられる

まとめ：_ldap._tcp.dc._msdcs が見つからないときの最短ルート

• 本質は「AD用DNSが正しく構成されていない」または「クライアントがAD DNSを見ていない」こと
• 最初にやるべきは、クライアントとDCのDNS設定をDCのIPだけに統一すること
• 次に、DNSゾーンに_msdcs / _tcp / _udpなどが存在し、SRVが登録されているかを確認する
• SRVが無ければ、ゾーン再作成またはdcdiag /fix ＋ NetLogon再起動で再登録させる
• 最後に、nslookup（SRV）とnltestでDC探索が通ることを確認してからドメイン参加をやり直す