検証用のフォレストに、ドメインをもう一つ足しました。フォレスト名は ad.local。一度目は子ドメインの sub.ad.local を、二度目はまったく別の名前の ebisuda.com を、同じフォレストへ入れます。どちらもウィザードの選択肢を一つ変えただけで、昇格そのものは成功しました。
ところが二度目のほうだけ、昇格が終わってもドメインコントローラー同士の複製が失敗しました。診断コマンドを流すと「ドメインのドメインコントローラーが見つからない」「レプリケーションに失敗した」というエラーが並びます。アカウントも権限も、ネットワークの疎通も問題ありません。足りなかったのは DNS上のつながりだけでした。
この記事では、Active DirectoryがDNSを何のために使っているのかを、DNSマネージャーに実際に出てくるものから整理します。そのうえで、なぜ一つ目のドメインは何も考えずに動き、二つ目は動かなかったのかを説明し、ADの調子がおかしいときにDNSのどこから確かめるかを判断基準としてまとめます。
ADのドメイン名は、そのままDNSのゾーン名になる
ドメインコントローラーでDNSマネージャーを開くと、前方参照ゾーンに ad.local があります。Active Directoryのドメイン名とDNSのゾーン名が一致しているのは偶然ではありません。ADのドメインは、DNSの名前空間の上に作られています。
ゾーンの中には、ドメインに参加しているサーバーやPCのAレコードが並びます。DC01.ad.local、DC02.ad.local、メンバーサーバーの名前。ここまでは普通のDNSと変わりません。
普通のDNSと違うのは、その下にあるアンダースコアで始まるフォルダーです。_msdcs、_sites、_tcp、_udp、そして DomainDnsZones と ForestDnsZones。この部分が、ADがDNSを「名前を引く道具」以上のものとして使っている証拠です。
SRVレコードは、ドメインコントローラーの居場所台帳
_msdcs の下をたどっていくと、dc、_sites、サイト名（既定では Default-First-Site-Name）、_tcp と進み、その中に _ldap や _kerberos という名前のレコードがあります。これがSRVレコードです。
SRVレコードに書かれているのは、「このサービスを提供しているのはどのサーバーで、何番のポートで受け付けているか」です。つまりADは、どのサイトに、どのドメインコントローラーがいて、LDAPやKerberosをどこで提供しているかをDNSに書き込んでいます。重みと優先度も持てるので、どれを優先して使うか、同じ重みで分散するかも表せます。
クライアントやメンバーサーバーは、ドメインコントローラーの名前を最初から知っているわけではありません。DNSに「このドメインでLDAPを提供しているのは誰か」と問い合わせ、返ってきたSRVレコードからドメインコントローラーを見つけます。ADのDNSは、名前解決のためというよりドメインコントローラーの居場所台帳として働いている、と捉えると全体が見通しやすくなります。
同じ場所には役割ごとの台帳もあります。gc はグローバルカタログサーバー、pdc はPDCエミュレーターの役割を持つドメインコントローラーです。PDCエミュレーターのレコードに1台しか載っていないのは、その役割を持つのが1台だけだからです。どこに何が書いてあるかを全部覚える必要はありません。「役割ごとに、担当しているドメインコントローラーがDNSに載っている」と分かっていれば、たどって確かめられます。
実際にDNSマネージャーでフォルダーを開きながらSRVレコードをたどる様子は、Part 3の動画の2分あたりから（無料）で見られます。アンダースコアの付いた階層は文章で読むと迷路のようですが、画面で一度開いてみると構造がすぐ頭に入ります。
ADに統合されたゾーンは、ADの複製に乗って配られる
ゾーン ad.local のプロパティを開くと、種類が「Active Directory統合」になっています。ゾーンのデータがADのデータベースの中に格納され、ユーザーやグループと同じADの複製でほかのドメインコントローラーへ配られる、という意味です。DNSのゾーン転送の仕組みを別に組む必要はありません。
このとき重要なのがレプリケーションの範囲です。プロパティから次のように選べます。
| 範囲 | 何に向いているか |
|---|---|
| このフォレスト内のドメインコントローラーで実行しているすべてのDNSサーバー | フォレスト全体で必要な情報 |
| このドメイン内のドメインコントローラーで実行しているすべてのDNSサーバー | そのドメインの中だけで必要な情報 |
| このドメイン内のすべてのドメインコントローラー（Windows 2000互換） | 古い環境との互換性のため |
ADのインストール時には、DNS用のアプリケーションディレクトリパーティションとして、フォレスト全体用の ForestDnsZones と、ドメインごとの DomainDnsZones が作られます。範囲の選択肢は、このどちらに入れるかの選択です。
範囲はゾーンの性質で決まります。ad.local のゾーンに入っているのは ad.local ドメインのレコードなので、範囲は「このドメインのすべてのDNSサーバー」です。子ドメインを作ると sub.ad.local のゾーンができ、こちらも範囲は子ドメインの中だけになります。
_msdcs だけは、フォレストのどこにでも無いといけない
前方参照ゾーンには、ad.local とは別に _msdcs.ad.local という独立したゾーンがあります。フォレスト名に結び付いたゾーンで、レプリケーションの範囲は「このフォレストのすべてのDNSサーバー」です。
このゾーンには、フォレスト全体で使う居場所の情報が入っています。代表がドメインコントローラーごとのGUIDからホスト名を引くためのCNAMEレコードと、グローバルカタログのレコードです。Microsoftのドキュメントでも、ADはこのフォレスト全体のロケーターレコードを使って、複製相手同士が互いを見つけ、クライアントがグローバルカタログを見つけると説明されています。
だから、このゾーンは子ドメインのDNSサーバーにも存在しなければなりません。どこかのドメインのDNSからこれが見えなくなると、そのドメインのドメインコントローラーは複製相手を見つけられなくなります。ADを動かすうえで、いちばん失ってはいけないゾーンだと言ってよいでしょう。
Windows 2000 Serverのころ、この情報はドメインのゾーンの中のサブドメインとして置かれていて、切り出してフォレスト全体に複製する設計を手で組むのが良い設計だとされていました。現在のWindows Serverでは、新しいフォレストを作ると最初からこの形に切り出されます。古い環境から引き継いだドメインでは、この形になっていないこともあるので、_msdcs が独立したゾーンになっているか、範囲がフォレスト全体かを一度確認しておく価値があります。
子ドメインは動き、ツリードメインは動かなかった理由
冒頭の話に戻ります。既存のフォレストに新しいドメインを足すとき、ウィザードでは「子ドメイン」と「ツリードメイン」を選べます。
- 子ドメイン：
sub.ad.localのように、親の名前の下に続く名前にする - ツリードメイン：
ebisuda.comのように、親とDNS上のつながりがない名前にする
名前だけ見るとまったく無関係に見えるドメインが、実は同じフォレストに属しており、信頼関係も結ばれている、という構成が作れます。名前から所属を判断せず、フォレストとドメインの関係を画面で確かめる必要があるのはこのためです。
子ドメインを作ったとき、ウィザードは親の ad.local のゾーンに sub の委任を自動で作りました。「sub.ad.local のことは、この新しいドメインコントローラーに聞いてください」という案内です。DNSの委任を作る設定は、子ドメインの場合はチェックを外せない状態になっていました。親子の名前関係がある以上、作らない理由がないからです。この委任のおかげで、親側からも子側の名前が引け、DNSのつながりが最初からできていました。
ツリードメインではこうなりません。ebisuda.com を委任すべき親ゾーンは、このフォレストのDNSにはないからです。ウィザードも「権限のある親ゾーンが見つからないため委任を作成できなかった」という趣旨の警告を出します。既存のDNSと統合するなら親ゾーンで手動で委任を作ること、そうでなければ何もしなくてよいこと、とも書かれています。
警告を読んで先へ進むと、昇格は成功します。しかしこの時点で、ad.local 側のDNSサーバーは ebisuda.com の名前を引く手段を持っていません。新しいドメインコントローラー側は、フォワーダーの設定で ad.local 側へ問い合わせを流せたので、下から上への名前解決はできていました。上から下へ、つまり既存のドメインから新しいドメインの名前が引けない。片方向だけのつながりです。
結果として、新しいドメインコントローラーのDNSにはフォレスト全体のはずの _msdcs.ad.local が届かず、診断コマンドは複製の失敗とドメインコントローラーが見つからないというエラーを返しました。アカウントや権限の問題に見えるエラーでも、根にあるのは名前解決です。
直し方：名前解決を双方向にしてから、複製を待つ
このときは、条件付きフォワーダーで直しました。「ebisuda.com についての問い合わせは、新しいドメインコントローラー（そのドメインのDNSサーバー）に聞く」という条件付きフォワーダーを作り、Active Directoryに格納して、フォレスト内のすべてのDNSサーバーへ複製する設定にします。1台ずつ手で設定しなくても、ADの複製で全部のDNSサーバーへ配られます。
条件付きフォワーダーが行き渡り、双方向に名前が引けるようになると、止まっていた複製が進み始め、新しいドメインコントローラーのDNSにも _msdcs.ad.local のゾーンが現れました。診断コマンドを流し直すと、レプリケーションのテストは合格に変わっていました。
直し方は条件付きフォワーダーだけではありません。スタブゾーンやセカンダリゾーンを置く、既存のDNS基盤側で委任を作るといった方法もあります。どれを選ぶかは組織のDNS全体の設計次第です。ただ、どの方法を選んでも目標は同じで、フォレスト内のどのDNSサーバーからも、すべてのドメインの名前と _msdcs が引ける状態にすることです。
複製が失敗する状態から、条件付きフォワーダーを作って直るまでは、Part 3の動画の31分あたりから（無料）で一続きに見られます。途中で予想と違う画面が出て、原因を探りながら直していく様子がそのまま入っているので、本番で同じ状況になったときの切り分けの順番の参考になります。
ADの調子がおかしいときに、DNSで確かめる順番
ここまでの話を、困ったときの判断基準にまとめます。ADのトラブルに見えるもののかなりの部分は、名前解決の問題です。権限やアカウントを疑う前に、次の順で確かめます。
| 確かめること | 見る場所・方法 | 引けなかったら疑うこと |
|---|---|---|
| クライアントやサーバーが、ADのDNSを参照しているか | ネットワーク設定のDNSサーバー | 参照先がADと無関係なDNSになっている |
| ドメインコントローラーのSRVレコードが引けるか | nslookup -type=SRV _ldap._tcp.dc._msdcs.<ドメイン名> |
DNSへの登録ができていない、ゾーンが違う |
_msdcs.<フォレスト名> がどのDNSサーバーにもあるか |
DNSマネージャーの前方参照ゾーン | レプリケーションの範囲がフォレスト全体になっていない、複製が届いていない |
| 別のドメインの名前が双方向に引けるか | 双方のDNSサーバーから nslookup |
委任や条件付きフォワーダーが無い、片方向だけになっている |
| 複製が成功しているか | dcdiag や repadmin /replsummary |
ここで失敗が出たら、上の4つに戻る |
新しいドメインを足す前にも、同じ問いが使えます。子ドメインなら委任がウィザードで作られます。ツリードメインにするなら、フォレストのどこからでも新しいドメインの名前が引ける経路を、昇格の前に決めておく。ウィザードの警告は「何もしなくてよい」とも読めますが、それは既存のDNS基盤と統合しない場合の話で、フォレスト内の名前解決まで面倒を見てくれるわけではありません。
なお、この記事の素材の動画は2022年に収録したもので、ウィザードの画面や既定値は最新のWindows Serverでは細部が異なる場合があります。SRVレコードで居場所を示し、ADの複製でゾーンを配るという仕組みそのものは変わっていません。
まとめ
- ADのドメイン名はDNSのゾーン名になり、ドメインコントローラーは自分の居場所と役割をSRVレコードとしてDNSに書き込む
- クライアントも、ほかのドメインコントローラーも、DNSを引いてドメインコントローラーを見つける。ADのDNSは居場所台帳である
- ゾーンはADの複製で配られる。ドメインのゾーンはドメインの中へ、
_msdcs.<フォレスト名>はフォレスト全体へ届かなければならない - 子ドメインは委任が自動で作られるが、ツリードメインは名前解決の経路を自分で用意しないと、昇格は成功しても複製が止まる
- ADの調子がおかしいときは、権限を疑う前に、SRVレコードと
_msdcsが引けるか、名前解決が双方向かを確かめる
DNSの上で見つけ合ったドメインコントローラーが、実際に何をどの範囲へ複製しているのか。ドメイン・構成・スキーマのパーティションがどこまで配られるのか、変更がどの順番で伝わり、削除がどう扱われるのか。この記事で「複製が止まった」と書いた部分の中身は、Part 7「複製ロジック」（メンバー限定）で、複数のドメインコントローラーの画面を行き来しながら扱っています。名前解決が通ったあとに複製が正しく回っているかを自分で判断できるようになるには、この仕組みを一度図と画面で追っておくのが近道です。
