ドメインに参加した PC は、サインインやグループポリシーの取得のたびに、ドメインコントローラ（DC）と話す必要があります。ところが、ドメインに DC が何台もあるとき、PC はどの DC と話せばよいかを最初は知りません。そこで PC は、DNS に「このドメインの DC はどれ？」と問い合わせて DC を探します。このしくみを DC Locator（DC ロケーター）と呼びます。この記事では、DNS の SRV レコード、DC Locator の流れ、近くの DC を選ぶための「サイト」、DC が見つからないときの確認方法を説明します。
- PC が DNS の SRV レコードで DC を探すしくみ
- サイトとサブネットで、近くの DC が選ばれる流れ
- 「DC が見つからない」ときに、どこから確かめればよいか
なぜ PC は DC を探すのか
この記事では、次の構成で考えます。ドメインは corp.example.com で、東京本社に DC01 と DC02、大阪営業所に DC11 があります。PC01 は大阪営業所にある PC です。
PC は、ユーザーのサインイン（Kerberos のチケットをもらう）、グループポリシーの取得、コンピュータアカウントでの認証（セキュアチャネル）など、さまざまな場面で DC を使います。DC はどれも同じ AD のデータを持っているので、どの DC と話しても仕事はできます。ただし、大阪の PC が東京の DC とばかり話すと、拠点間の回線を余計に使い、応答も遅くなります。そのため、「動いている DC」の中から「近い DC」を選ぶことが大切です。
DC を探すのは、PC の Netlogon サービスです。Netlogon は、DC とのセキュアチャネルを作るサービスでもあります。セキュアチャネルについては「Netlogonとセキュアチャネルとは？」の記事で説明しています。
DNS の SRV レコード
DNS というと、「dc01.corp.example.com の IP アドレスは？」のように、名前から IP アドレスを調べるしくみを思い浮かべると思います。これは A レコードの役目です。PC が DC を探すときは、これとは別の SRV レコードを使います。SRV レコードは「このサービスを提供しているのは、どのサーバの何番ポートか」を答えるレコードです。
PC は DC の名前を知らなくても、「_ldap._tcp.dc._msdcs.corp.example.com」という決まった名前で問い合わせれば、corp.example.com の DC の一覧を受け取れます。名前の頭にある「_ldap」「_tcp」はサービスとプロトコル、「dc._msdcs」は「Microsoft の DC としてのレコード」という意味です。
SRV レコードを登録するのは DC 自身
SRV レコードは、管理者が手で作るものではありません。DC の Netlogon サービスが、自分の役割とサイトに合わせて DNS に登録します。DNS サーバ側で動的更新を受け付けていることが前提です。
主な SRV レコードは次のとおりです。〈ドメイン〉は corp.example.com、〈フォレスト〉はフォレストのルートドメインの名前、〈サイト〉はサイト名です。
| レコード | 何を探すときに使うか |
|---|---|
_ldap._tcp.dc._msdcs.〈ドメイン〉 | そのドメインの DC |
_ldap._tcp.〈サイト〉._sites.dc._msdcs.〈ドメイン〉 | そのサイトにいる DC |
_kerberos._tcp.dc._msdcs.〈ドメイン〉 | Kerberos の KDC として動く DC |
_ldap._tcp.gc._msdcs.〈フォレスト〉 | グローバルカタログ（GC） |
_ldap._tcp.pdc._msdcs.〈ドメイン〉 | PDC エミュレータの DC |
このほか、DC ごとの GUID を使った CNAME レコード（〈DC の GUID〉._msdcs.〈フォレスト〉）もあり、DC どうしの複製で相手を探すときに使います。
DC Locator の流れ
PC が DC を探す流れは、大きく3つの段階に分かれます。
| 段階 | 何が起きるか |
|---|---|
| ① DNS で探す | Netlogon が DNS に SRV レコードを問い合わせ、DC の候補の名前と IP アドレスを受け取る |
| ② LDAP ping | 候補の DC に、UDP 389 番で小さな LDAP の問い合わせ（LDAP ping）を送る。動いている DC は、ドメインの情報や PC のサイトの情報を返す |
| ③ 選んで覚える | いちばん早く答えた DC を使う。DC の情報はキャッシュしておき、次からは同じ DC を使う |
DNS にレコードがあっても、その DC が止まっていたら使えません。LDAP ping は「本当に答えられる DC か」を確かめるための手順です。また、同じ DC を使い続けることで、PC から見た AD の内容がぶれにくくなります。
サイト：近くの DC を選ぶしくみ
近い DC を選ぶために使うのが、AD の「サイト」です。サイトは、速い回線でつながったネットワークの範囲をまとめたもので、「AD サイトとサービス」で作ります。サイトにはサブネット（IP アドレスの範囲）を結び付けておきます。
DC は自分がどのサイトにいるかを知っていて、サイト用の SRV レコード（_ldap._tcp.Osaka._sites.dc._msdcs.corp.example.com など）も登録します。PC は、自分のサイトが分かっていれば、まずサイト用のレコードで同じサイトの DC を探します。
自分のサイトを DC に教わる
PC は、自分がどのサイトにいるかを自分では判断しません。LDAP ping を受けた DC が、PC の IP アドレスをサブネットと照らし合わせてサイトを調べ、答えといっしょに教えます。
近くない DC を使っている間は、PC は 15 分たつとキャッシュを捨て、もう一度近い DC を探します。大阪の DC11 が一時的に止まっていて東京の DC01 を使った場合でも、DC11 が戻れば、また DC11 を使うようになります。
DC がないサイトもあります。その場合は、いちばん近いサイトの DC が、そのサイトのためのサイト用レコードも登録します（自動サイトカバレッジ）。なお RODC（読み取り専用 DC）は、既定では自分のサイトのレコードだけを登録します。RODC については「ドメインコントローラの種類とは？」の記事で説明しています。
サブネットを登録し忘れると
新しい拠点を作ったときに、サブネットの登録を忘れることがあります。すると、その拠点の PC はどのサイトにも属さず、遠い DC を使うことがあります。
この状態は DC のシステムログに NETLOGON のイベント ID 5807 として記録されます。DC の netlogon.log の「NO_CLIENT_SITE:」の行を見ると、どの PC（名前と IP アドレス）がサイトなしでつないできたかが分かります。
DC が見つからないときの原因
ドメインへの参加で「AD DC に接続できない」というエラー（エラーコード 0x54b など）が出たり、PC のシステムログに NETLOGON のイベント ID 5719 が出たりするときは、DC Locator のどこかで止まっています。多いのは、PC の DNS サーバの設定です。
インターネットの DNS は corp.example.com の SRV レコードを知りません。社内の DNS とインターネットの DNS を並べて設定していると、問い合わせ先によって DC が見つかったり見つからなかったりして、原因が分かりにくくなります。ドメインに参加する PC の DNS サーバは、社内の DNS だけにします。社内の DNS がインターネットの名前も解決できるように、DNS サーバ側でフォワーダーを設定するのが一般的です。
確かめる順番は次のとおりです。
| 原因 | 直し方 |
|---|---|
| DNS の設定 | PC の DNS サーバを、AD のゾーンを持つ社内の DNS にする |
| SRV レコードがない | DNS の動的更新が許可されているかを確かめ、DC の Netlogon サービスを再起動して登録し直す。DC の A レコードは ipconfig /registerdns で登録し直す |
| 通信が止まっている | PC と DC の間のファイアウォールで、DNS（53番）と LDAP ping（UDP 389番）を許可する |
| サイトが違う | AD サイトとサービスで、PC のサブネットを正しいサイトに結び付ける |
DC を探すしくみには、DNS を使う方法のほかに、WINS やブロードキャスト（メールスロット）で NetBIOS 名のドメインを探す古い方法があります。Windows Server 2025 からは、この NetBIOS を使った探し方が既定で使えなくなりました（グループポリシーの「Block NetBIOS-based discovery for domain controller location」が既定で有効）。「CORP」のような短いドメイン名を指定された場合も、DNS のドメイン名に置き換えられれば DNS で探します。DNS の設定が正しくなっていることが、これまで以上に大切です。
確認に使うコマンド
PC（コマンドプロンプト）：DNS サーバの設定を表示する
ipconfig /all
PC（コマンドプロンプト）：ドメインの DC の SRV レコードを問い合わせる
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com
PC（PowerShell）：大阪サイトの DC の SRV レコードを問い合わせる
Resolve-DnsName -Name _ldap._tcp.Osaka._sites.dc._msdcs.corp.example.com -Type SRV
PC（コマンドプロンプト）：DC Locator で DC を探す（キャッシュを使わずに探し直す）
nltest /dsgetdc:corp.example.com /force
PC（コマンドプロンプト）：PC のサイトを表示する
nltest /dsgetsite
DC（コマンドプロンプト・管理者）：DC の DNS の状態を詳しく調べる
dcdiag /test:dns /v
DC（PowerShell・管理者）：Netlogon を再起動して SRV レコードを登録し直す
Restart-Service -Name Netlogon
nltest /dsgetdc の結果では、「DC:」の行が見つかった DC、「Dc Site Name」が DC のサイト、「Our Site Name」が PC のサイトです。2つのサイトが同じなら、近い DC を使えています。「Flags」の行には、その DC の役割（GC、KDC、PDC など）が並びます。
まとめ
| 項目 | ひとことで |
|---|---|
| DC Locator | PC の Netlogon が、DNS と LDAP ping で使う DC を決めるしくみ |
| SRV レコード | 「このサービスはどのサーバか」を答えるレコード。DC の Netlogon が登録する |
| LDAP ping | UDP 389 番で DC が動いているかを確かめ、PC のサイトも教わる |
| サイト | サブネットで決まる「場所」。同じサイトの DC が優先される |
| 見つからないとき | まず PC の DNS サーバの設定。次に SRV レコード、通信、サイトの順に確かめる |
サインインが遅い、グループポリシーが適用されない、ドメインに参加できない。こうしたトラブルの多くは、認証より手前の「DC を見つける」段階で起きています。DC Locator の流れを知っておくと、どこで止まっているかを順番に確かめられます。
- Locating domain controllers in Windows and Windows Server（Microsoft Learn）
- Troubleshoot domain controller location issues in Windows（Microsoft Learn）
- How to verify that SRV DNS records have been created for a domain controller（Microsoft Learn）
- Problems that can occur with many Domain Controllers in Active Directory integrated DNS zones（Microsoft Learn）
- How to optimize the location of a domain controller or global catalog that resides outside of a client’s site（Microsoft Learn）
- Directory Service Functions（Microsoft Learn）
- Domain Controller delayed response to LDAP or Kerberos requests（Netlogon 5807）（Microsoft Learn）
- Domain join error code 0x54b（Microsoft Learn）
- Error code 0xa8b: An attempt to resolve the DNS name of a DC in the domain being joined has failed（Microsoft Learn）
- Event ID 5719, Error 1311, or Error 1355 – Domain controller or domain not found（Microsoft Learn）
- RFC 2782：A DNS RR for specifying the location of services (DNS SRV)
コメント