ある洋菓子屋さんで、新年早々ケーキを買いに行ったら、
お年賀として、リンゴの花粉からできた蜂蜜というのをもらいました。
リンゴと蜂蜜を使って料理を作るなんて話をよく聞くので、
混ぜる手間が省けるじゃない、なんて思っていたのですが、
この蜂蜜は、単純にリンゴと蜂蜜を混ぜたものとは違う味がしました。
リンゴと蜂蜜が高度に統合されていて、
リンゴの花粉も適当なものではおいしいものにならないし、
ミツバチも適当な働きではおいしいものにならない、
と、グルメレポーターばりに唸ってしまいました。
Active DirectoryとDNSサーバーも高度に(？)統合されていて、
DNSサーバー無くしてActive Directoryは動きません。
しかもActive Directoryでトラブルになるときは、DNSが関係していることが結構多く、
DNSがどうやって名前解決しているか、知っておかないといけないなあ、なんて思わせることも多いです。
特に注意したいポイントを今日はひとつあげておきたいと思います。
それは、レプリケーションを行うとき、相手のドメインコントローラーのホスト名ではなく、
ドメイン コントローラーに割り当てられる、GUIDと呼ばれる特殊なIDを使う点です。
それでは、実際の通信の様子からActive Directoryレプリケーション時の名前解決の様子を確認してみます。
以下は実際にドメイン コントローラー間でレプリケーションを行った時の様子を
WireSharkでキャプチャしたものです。
ちなみに今回のケースでは、ドメイン名がexample.com、
ドメイン コントローラーのコンピューター名がws08dcとws08で、
ws08コンピューター(192.168.10.28)からws08dcコンピューター(192.168.10.27)へレプリケーションを実行しています。
(適当なコンピューター名とIPアドレスでごめんなさい)
最上段を見てみると、
No.2のパケットがドメイン コントローラーを見つけるためのクエリを実行しています。
ところが、ws08コンピューターはws08dcコンピューターを見つけるために
ws08dc.example.comのFQDNではなく、
90c18DA2-8474-(中略)._msdcs.example.comなどという特殊なIDから構成される
FQDNに対してクエリを実行していることがわかります。
そして、No.3のパケットでは以下の内容でクエリの結果がDNSサーバーから返されています。
中段のAnswers欄を見ると、
90c18DA2-8474-(中略)._msdcs.example.comという名前はCNAME(別名)であり、
ホントの名前はws08dc.example.comですよ、と回答していることがわかります。
画面には映っていませんが、同時にws08dc.example.comのIPアドレスも回答しているので、
このあと、No.4～のパケットでActive Directoryのレプリケーションが開始しています。
■ ■ ■
このようにActive Directoryがレプリケーションを行うときには、コンピューター名ではなく、
コンピューター名に対して設定されている別名
(今回で言うと90c18DA2-8474-(中略)._msdcs.example.comです)が使われています。
ですので、DNSサーバー側でも、Active Directory用のDNSゾーンのレコードとして、
コンピューター名を表すAレコードだけでなく、その別名であるCNAMEレコードも一緒に作っておかないと
レプリケーションエラーになってしまうのです。
(DNSサーバー管理ツールだと、_msdcs.example.comゾーンに作られるCNAMEレコードです)
DNSサーバーのレコードはipconfig /registerdnsコマンドやNetlogonサービスが起動するタイミングなどで
自動的に作成されるので、あまり意識することがないかもしれませんが、何かの拍子にレコードが削除されていたりすると、
レプリケーションが実行できないなどの大きなトラブルに見舞われますから、注意したいものですね。
細かい話をすると、Active DirectoryとDNSサーバーの関係を理解するには、
SRVレコードのことについても、おさえておかないといけないのですが、その話については
別の機会ということで。
■参考資料
DNSLintを使用してActive Directoryレプリケーションに関する問題のトラブルシューティングを行う方法
http://support.microsoft.com/kb/321046/ja
