Active Directory（AD）のトラブルを調査していると、DNS設定を確認する場面が非常に多くあります。
「名前解決できているのだからDNSは問題ないのでは？」と思うこともありますが、Active DirectoryにおけるDNSは、単純にサーバー名をIPアドレスへ変換するだけの仕組みではありません。
Active Directory Domain Services（AD DS）はDNSを利用して、クライアントがドメインコントローラーを探したり、ドメインコントローラー同士が通信したりします。
そのためDNS設定に問題があると、ドメイン参加、ユーザーログオン、グループポリシー、Active Directoryレプリケーションなど、一見DNSとは関係なさそうなところまで影響する場合があります。
- Active DirectoryでDNSが重要なのはなぜ？
- クライアントはDNSを使ってドメインコントローラーを探す
- SRVレコードとは？
- SRVレコードをnslookupで確認する
- ドメイン参加でもDNSが使われる
- ユーザーログオンにもDNSが関係する
- ADレプリケーションでもDNSが重要
- クライアントに外部DNSを直接設定してはいけない？
- インターネットの名前解決はどうする？
- 優先DNSと代替DNSにも注意
- ドメインコントローラー自身のDNS設定も重要
- Active Directory統合DNSとは？
- まずipconfig /allを確認する
- DCのDNSをdcdiagで診断する
- レプリケーションも確認する
- ADトラブルでDNSを疑う主な症状
- Windows Server 2025ではDNSベースのDC Locatorがさらに重要
- まとめ
- 参考情報
Active DirectoryでDNSが重要なのはなぜ？
Active Directoryでは、クライアントPCが「ドメインコントローラーのIPアドレスを最初から知っている」という仕組みではありません。
DNSへ問い合わせて、利用可能なドメインコントローラーを探します。
Microsoftも、AD DSではDNS名前解決サービスを利用して、クライアントがドメインコントローラーを検索し、ディレクトリサービスをホストするドメインコントローラー同士が通信すると説明しています。
つまりDNSはActive Directoryを動かすための重要な基盤の一つです。
クライアントはDNSを使ってドメインコントローラーを探す
ドメイン参加済みWindows PCへユーザーがログオンするとき、PCは認証を行ってくれるドメインコントローラーを探す必要があります。
この処理ではDC Locatorと呼ばれる仕組みが使われます。
DC LocatorはDNSに登録されているSRVレコードなどを利用して、利用可能なドメインコントローラーを検索します。
例えばLDAPサービスを提供するドメインコントローラーを探す場合、次のようなSRVレコードが利用されます。
_ldap._tcp.<ドメイン名>MicrosoftのDC Locator資料でも、NetlogonサービスがDNSのSRVレコードとAレコードを問い合わせてドメインコントローラーを検索する仕組みが説明されています。
SRVレコードとは？
通常のDNSのAレコードは、ホスト名とIPv4アドレスを対応させます。
dc01.example.local → 192.168.1.10一方SRVレコードは、「どのサーバーが特定のサービスを提供しているか」を検索するためのDNSレコードです。
Active Directoryでは、ドメインコントローラーがさまざまなSRVレコードをDNSへ登録します。
例えば、
- LDAPを提供するDC
- Kerberosを提供するDC
- Global Catalog
- Active DirectoryサイトごとのDC
などを探すためにDNSが利用されます。
SRVレコードをnslookupで確認する
クライアントからDCを検索できるか確認するときは、nslookupを利用できます。
例えば次のように確認します。
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.localexample.localの部分は実際のActive Directoryドメイン名へ置き換えます。
正常であれば、該当するドメインコントローラーのSRVレコードが返されます。
ドメイン参加でもDNSが使われる
Windows PCをActive Directoryドメインへ参加させる場合もDNSが重要です。
クライアントはDNSのSRVレコードを問い合わせて、参加するドメインのドメインコントローラーを検索します。
そのため、クライアントPCのDNS設定が間違っていると、
- ドメインが見つからない
- ドメインコントローラーへ接続できない
- ドメイン参加に失敗する
といった症状につながる場合があります。
ユーザーログオンにもDNSが関係する
ドメインユーザーがWindowsへログオンするときにも、クライアントは適切なドメインコントローラーを検索します。
DNSが正常に動作していないとDC Locatorが適切なDCを発見できず、認証処理へ影響する可能性があります。
「インターネットは見られるからDNSは正常」とは限りません。
GoogleやMicrosoftなど外部サイトの名前解決ができても、Active Directory用のSRVレコードを検索できなければAD環境としては問題があります。
ADレプリケーションでもDNSが重要
DNSを利用するのはクライアントだけではありません。
ドメインコントローラーもDNSを利用して他のドメインコントローラーを検索します。
Microsoftは、ドメインコントローラーもDNSを使って他のDCを検索し、レプリケーションなどの処理を行うと説明しています。
そのためDNSの問題によって、Active Directoryレプリケーションエラーへつながる場合もあります。
クライアントに外部DNSを直接設定してはいけない？
Active Directory環境で注意したいのが、ドメイン参加PCやメンバーサーバーのDNS設定です。
例えば次のような外部DNSをクライアントへ直接指定したくなることがあります。
8.8.8.8
1.1.1.1
ISPのDNSサーバーしかし、これらのDNSサーバーは通常、社内Active DirectoryドメインのSRVレコードを持っていません。
Microsoftも、Windows ServerのドメインメンバーではActive DirectoryドメインのDNSゾーンをホストするDNSサーバーをDNSクライアントとして設定することを推奨しています。
また、ドメインコントローラーやメンバーサーバーのDNSクライアント設定をISPのDNSサーバーへ向けないよう案内しています。
インターネットの名前解決はどうする？
では、AD用DNSだけを指定した場合、インターネットの名前解決はどうするのでしょうか。
一般的には、クライアントはActive Directory用の内部DNSサーバーを利用し、内部DNSサーバーから外部DNSへ問い合わせを転送します。
クライアントPC
↓
Active Directory用DNS
↓
DNSフォワーダー
↓
外部DNS
↓
インターネットこうすることで、クライアントはAD用のDNSレコードとインターネット上の名前の両方を解決できます。
優先DNSと代替DNSにも注意
Active Directory環境では、
優先DNS ：社内DNS
代替DNS ：8.8.8.8のような設定も避けた方がよいでしょう。
「社内DNSが使えなければGoogle DNSを使えばインターネットだけでも利用できる」と考えたくなりますが、外部DNSへ切り替わったクライアントはActive Directory用のDNSレコードを正しく検索できません。
DNSを冗長化するなら、Active Directoryドメインのゾーンを正しく解決できる複数の内部DNSサーバーを指定する構成を検討します。
ドメインコントローラー自身のDNS設定も重要
クライアントだけでなく、ドメインコントローラー自身のDNSクライアント設定も重要です。
MicrosoftはDNSを実行するドメインコントローラーについて、環境やDC追加時の状態に応じたDNSクライアント設定を案内しています。
特に追加DCを構築するときは、Active Directoryレプリケーションが正常になる前から自己参照だけにしてしまうと、DNS Islandと呼ばれる問題につながる可能性があります。
そのため「DCなら必ず自分自身だけをDNSに設定すればよい」と単純に考えない方がよいでしょう。
Active Directory統合DNSとは？
Windows Serverでは、DNSゾーンをActive Directoryへ統合できます。
Active Directory統合DNSを利用すると、DNSゾーンの情報をAD DSに保存し、Active Directoryレプリケーションの仕組みを利用してDNS情報を複数のDNSサーバーへ複製できます。
Microsoftは既存DNSへAD DSを統合する場合、DNS Serverサービスを各DCへインストールする構成を推奨しており、DNSサーバーの1台が利用できない場合の耐障害性を高められます。
まずipconfig /allを確認する
Active Directory関連のトラブルを調査するとき、まず確認しておきたいのがDNSクライアント設定です。
ipconfig /allここで、
- IPアドレス
- サブネットマスク
- デフォルトゲートウェイ
- DNSサーバー
- DNSサフィックス
などを確認します。
特にDNSサーバーが意図したActive Directory用DNSになっているかを確認します。
DCのDNSをdcdiagで診断する
ドメインコントローラー側では、dcdiagを使ってDNS関連の診断を行えます。
dcdiag /test:dnsDNSクライアント設定、登録状態、名前解決など、Active DirectoryとDNSに関する問題を調査するときの手掛かりになります。
レプリケーションも確認する
DNSに問題が疑われる場合でも、Active Directoryレプリケーションの状態も確認しておくとよいでしょう。
repadmin /replsummaryレプリケーションエラーが発生していないかを確認できます。
repadminの基本的な見方については、以下の記事でも解説しています。
ADトラブルでDNSを疑う主な症状
例えば次のような症状がある場合、DNS設定やDNSレコードも確認してみます。
- ドメイン参加できない
- ドメインログオンに時間がかかる
- グループポリシーが適用されない
- ドメインコントローラーが見つからない
- ADレプリケーションでエラーになる
- 特定サイトでは遠隔地のDCへ接続する
もちろん原因が必ずDNSとは限りませんが、Active DirectoryではDNSが多くの処理の基盤になっているため、重要な確認項目になります。
Windows Server 2025ではDNSベースのDC Locatorがさらに重要
Windows Server 2025ではDC Locatorの動作にも変更があります。
Microsoftによると、Windows Server 2025以降のDC LocatorではNetBIOS形式によるDC検索を許可しない動作が導入されています。
現在のActive Directory環境では、DNSベースのDC LocatorがどのようにDCを検索しているか理解しておくことが重要です。
まとめ
Active DirectoryにおけるDNSは、単なるホスト名からIPアドレスへの名前解決だけではありません。
DNSは、
- ドメイン参加
- ドメインコントローラーの検索
- ユーザーログオン
- Kerberos認証に必要なサービスの検索
- Global Catalogの検索
- Active Directoryサイトに応じたDC検索
- DC同士の通信やレプリケーション
など、多くのActive Directory処理に関係します。
AD関連のトラブルが発生した場合は、エラーになっている機能だけを見るのではなく、「クライアントやDCが正しいDNSを参照しているか」「必要なSRVレコードを検索できるか」も確認することが重要です。
コメント