ADのDNS設計と運用ガイド｜Active Directoryが依存するDNSの仕組みと現場の落とし穴

Active DirectoryはDNSと切り離せない関係にあります。
DNSを使ってDCを探し、認証し、ポリシーを配布します。

DNSが正しく機能していないと、ADの多くの機能が動きません。

本記事ではADとDNSの関係を整理し、現場でよくある設定ミスと確認方法を解説します。

RSATを使ったDNS管理については「RSATでADを遠隔管理する実務ガイド」を参照してください。

ADとDNSの関係

ADはDNSなしでは動かない

Active Directoryは、ドメイン内のDCやサービスの場所をDNSのSRVレコードを使って管理します。クライアントがドメインに参加したりログオンしたりするとき、最初にDNSに問い合わせてDCの場所を確認します。

SRVレコード（Service Record）
DNSに登録されるリソースレコードの一種。「このドメインでこのサービスを提供しているサーバーはどこか」を示す。ADはKerberos認証・LDAPサービス・グローバルカタログなどのDCを見つけるためにSRVレコードを使う。ADを構築すると自動的に登録される。

クライアントがドメインに参加する際の流れを見ると、DNSへの依存度が明確になります。

① クライアントが「nlab.local」のDCを探す
      ↓
② DNSにSRVレコードを問い合わせる
   （_ldap._tcp.nlab.local など）
      ↓
③ DNSがDCのIPアドレスを返す
      ↓
④ クライアントがDCに接続してドメイン参加・認証を実行する

この流れのどこかでDNSが機能しないと、クライアントはDCに到達できずドメイン参加も認証もできません。「ドメインに参加できない」というトラブルの多くはステップ①〜③で詰まっています。

ADが使う主要なDNSレコード

ADが自動的にDNSに登録する主要なレコードを整理します。

これらのレコードはAD DSのインストール時に自動登録されますが、DNS設定が誤っていると登録に失敗します。また何らかの原因で消えてしまうケースもあるため、定期的な確認が必要です。

DNS設計の基本

DNSサーバーはDCに統合する

AD環境では、DNSサーバーをDCに統合して運用するのが標準的な設計です。

ADに統合されたDNS（Active Directory Integrated DNS）
DNSゾーンのデータをADのデータベース（NTDS.dit）に保存する方式。通常のDNSでは別ファイルにゾーンデータを保存するが、AD統合DNSではADのレプリケーション機能を使って複数のDC間でDNSデータを自動同期できる。セキュリティ強化（セキュアな動的更新）とレプリケーションの簡素化がメリット。

AD環境でDNSを別サーバーで管理する設計は、管理が複雑になる上にトラブル発生時の原因切り分けも難しくなります。特別な理由がない限り、ADに統合されたDNSを使ってください。

クライアントのDNS設定

クライアントPCのDNS設定はドメインのDCのIPアドレスを向ける必要があります。これがAD環境で最もよく発生する設定ミスです。

✅ 正しい設定：
　優先DNSサーバー：192.168.56.10（DC01のIPアドレス）
　代替DNSサーバー：192.168.56.11（DC02のIPアドレス・冗長構成の場合）

❌ よくある誤り：
　優先DNSサーバー：8.8.8.8（Google DNS）
　代替DNSサーバー：1.1.1.1（Cloudflare DNS）

外部DNSを向けた状態では、nlab.localなどのプライベートドメイン名を解決できません。ドメイン参加はできても、ログオン時・GPO適用時・DC接続時に問題が発生します。

GPOでDNS設定を一括管理する場合は、DHCPオプション（006）でDNSサーバーアドレスを配布するのが一般的です。

GPOの設計と運用については「グループポリシー（GPO）設計入門」を参照してください。

DNSフォワーダーの設定

ADのDNSサーバーは社内ドメイン（nlab.local）の名前解決を担いますが、インターネット上のドメイン（google.comなど）は解決できません。インターネットへの名前解決はフォワーダーを使って外部DNSに転送します。

フォワーダー（Forwarder）
自分が解決できないDNSクエリを別のDNSサーバーに転送する設定。ADのDNSサーバーにフォワーダーとして外部DNS（プロバイダーのDNSやGoogle DNS等）を設定することで、社内DNSが解決できないインターネット上の名前を外部DNSに問い合わせられるようになる。

# 現在のフォワーダー設定を確認する（DC上で実行）
Get-DnsServerForwarder

# フォワーダーを設定する
Set-DnsServerForwarder -IPAddress "8.8.8.8", "8.8.4.4"

フォワーダーが設定されていないと、クライアントはインターネット上のドメインを解決できません。「社内のサーバーにはアクセスできるがインターネットに繋がらない」というトラブルはフォワーダーの設定漏れが原因であることが多いです。

運用で確認すべき設定

SRVレコードの存在確認

AD環境が正常に機能しているかを確認するには、SRVレコードが正しく登録されているかをチェックします。

# SRVレコードを確認する（クライアントまたはDC上で実行）
Resolve-DnsName -Name "_ldap._tcp.nlab.local" -Type SRV
Resolve-DnsName -Name "_kerberos._tcp.nlab.local" -Type SRV
Resolve-DnsName -Name "_gc._tcp.nlab.local" -Type SRV

正常な環境ではDCのホスト名とIPアドレスが返ってきます。エラーが返る場合はSRVレコードが登録されていない可能性があります。

SRVレコードが消えてしまった場合は、DC上でNetLogonサービスを再起動することで自動再登録されます。

# NetLogonサービスを再起動してSRVレコードを再登録する（DC上で実行）
Restart-Service Netlogon

逆引きゾーンの設定

逆引きゾーンはIPアドレスからホスト名を解決するための設定です。ADの動作に必須ではありませんが、イベントログの調査やネットワーク機器の管理で役立ちます。

逆引きゾーン（Reverse Lookup Zone）
IPアドレスからホスト名を解決するためのDNSゾーン。通常のDNS（正引き）がホスト名→IPアドレスを解決するのに対し、逆引きゾーンはIPアドレス→ホスト名を解決する。PTRレコードが登録される。

# 逆引きゾーンの確認（DC上で実行）
Get-DnsServerZone | Where-Object {$_.IsReverseLookupZone -eq $true}

# 逆引きゾーンを作成する（例：192.168.56.0/24の場合）
Add-DnsServerPrimaryZone -NetworkId "192.168.56.0/24" -ReplicationScope "Forest"

DNSログの有効化

DNSのクエリログを有効化しておくと、名前解決のトラブルシューティングやC2通信の検知に役立ちます。

# DNSデバッグログを有効化する（DC上で実行）
Set-DnsServerDiagnostics -All $true

# ログの保存パスを確認する
Get-DnsServerDiagnostics | Select-Object LogFilePath, MaxMBFileSize

ただしDNSデバッグログはI/Oに影響するため、通常運用では必要なカテゴリのみを有効化するか、トラブルシューティング時のみ有効化する運用を推奨します。

現場でよくある設定ミス

クライアントのDNSが外部DNSを向いている

「インターネットに繋がるようにしたい」という理由でクライアントのDNSを8.8.8.8などの外部DNSに設定するケースがあります。この状態ではnlab.localなどの社内ドメイン名を解決できないため、ドメインログオンやGPO適用・DCとの通信が断続的に失敗します。クライアントのDNSは必ずDCのIPアドレスを向けてください。インターネットへの名前解決はDCのDNSにフォワーダーを設定することで対処します。

DCのNICがDNSに自分自身を向いていない

DCのネットワーク設定で、DNSサーバーに自分自身のIPアドレス（127.0.0.1またはDC自身のIP）を設定していないケースがあります。DCが自分自身をDNSとして参照しないと、SRVレコードの登録やDCロケーターの動作に問題が発生します。DCのNICの優先DNSは127.0.0.1または自分自身のIPアドレスを設定してください。

# DCのNICのDNS設定を確認する（DC上で実行）
Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -notlike "*Loopback*"}

SRVレコードが消えている

DC再起動後やNetLogonサービスの問題でSRVレコードが削除されてしまうケースがあります。定期的にResolve-DnsNameコマンドでSRVレコードの存在を確認し、消えていればNetLogonサービスの再起動で再登録してください。DCを増設した際にSRVレコードが正しく登録されているかの確認も必須です。

逆引きゾーンが設定されていない

逆引きゾーンが設定されていないと、イベントログにIPアドレスしか記録されず調査が困難になります。またDCのリソースレコード登録時に警告が出続けます。必ず逆引きゾーンを作成し、PTRレコードが自動登録されるように設定してください。

チェックリスト

DNS設計の確認

• [ ] DNSサーバーがDCに統合されている（ADに統合されたDNS）
• [ ] クライアントのDNS設定がDCのIPアドレスを向いている
• [ ] DCのNICのDNSが自分自身のIPアドレスまたは127.0.0.1を向いている
• [ ] フォワーダーが設定されておりインターネットの名前解決ができる

SRVレコードの確認

• [ ] _ldap._tcp.ドメイン名のSRVレコードが存在する
• [ ] _kerberos._tcp.ドメイン名のSRVレコードが存在する
• [ ] _gc._tcp.ドメイン名のSRVレコードが存在する（グローバルカタログ）

ゾーンの確認

• [ ] 正引きゾーン（ドメイン名→IPアドレス）が正常に機能している
• [ ] 逆引きゾーン（IPアドレス→ドメイン名）が設定されている
• [ ] ゾーンのレプリケーション設定が「フォレスト全体」または「ドメイン全体」になっている

まとめ

クライアントPCのDNS設定がDCのIPアドレスを向いているか確認してください。

# クライアント上でDNS設定を確認する
Get-DnsClientServerAddress -AddressFamily IPv4 |
    Where-Object {$_.InterfaceAlias -notlike "*Loopback*"} |
    Select-Object InterfaceAlias, ServerAddresses

ServerAddressesにDCのIPアドレスが含まれていなければ、ADに関連するさまざまなトラブルの原因になります。

DNSはADの根幹インフラです。「ADが不安定」「ドメインに参加できない」「GPOが効かない」といったトラブルは、まずDNSを疑ってチェックリストを確認する習慣をつけてください。

DCの冗長化設計とDNSの関係については「ドメインコントローラーの冗長化設計｜DC障害で業務が止まらない構成の考え方」もあわせてご覧ください。

あわせてご覧ください

• RSATでADを遠隔管理する実務ガイド
• ドメインコントローラーの冗長化設計｜DC障害で業務が止まらない構成の考え方
• グループポリシー（GPO）設計入門
• Active Directoryとは？Windows認証基盤の仕組みと設計の基本

参考文献

• 参考：Active Directory Domain Services の概要（Microsoft Learn）
• 参考：DNS と Active Directory Domain Services（Microsoft Learn）