DNSサーバーはなぜ必要なのか：基礎から分かるActive Directory再入門（6）

連載目次

Active Directoryのトラブルの元凶はDNS？

　“Active Directoryのトラブルの多くはDNS絡み”――。これは、Active Directory管理者の間で古くからいわれてきたことである。

　なぜ、Active Directoryでは名前解決サービスを提供する「DNS」（Domain Name System）サーバーが必要なのだろうか。その理由は、DNSサーバーが保持する「SRVレコード」の存在にある。

　SRVレコードは、組織内で利用するさまざまなサービスがどの場所で提供されているのか（提供されているサービスの位置情報）を表すためのレコードである。Active Directoryでは、ドメインコントローラーの場所を特定するためにSRVレコードが利用される（［参考記事］DNS Tips：SRVリソースレコードって何ですか？）。

　言い方を変えると、クライアントコンピューターがドメインコントローラーにアクセスする際、DNSサーバーのSRVレコードを参照できなければ、ドメインコントローラーを見つけることができないため、アクセスできないということになる。これが「Active Directoryで起こるトラブルの多くはDNS絡み」といわれる理由である。

　今回は、Active Directoryの運用管理やサポートに携わる方が、DNS絡みのトラブルに適切に対処できるように、DNSとActive Directoryの関係をあらためて確認しておきたい。

ドメインコントローラーの居場所はSRVレコードで特定

　Active DirectoryでDNSサーバーを利用する最大の理由は、クライアントがドメインコントローラーにアクセスするとき、どこにドメインコントローラーがあるかを確認するためである（図1）。

図1　クライアントがドメインコントローラーを見つけるまでの流れ

　Active Directoryでは、クライアントがドメインへ参加したり、サインインしたり、ドメイン内の各サーバーを利用したりする際などに、ドメインコントローラーにアクセスする。これらの通信が正しく行われるようにするために、クライアントはドメインコントローラーにアクセスする前に、最初にDNSサーバーに接続するようになっている。そして、DNSサーバーに接続すると、SRVレコードを利用してドメインコントローラーの場所を特定している。

　これは、ドメインコントローラーがデータベースをレプリケーション（複製）するために、他のドメインコントローラーにアクセスする場合にも同じである（［参考記事］ドメインコントローラーの複製とは）。

サイト内のドメインコントローラーを特定する

　Active Directoryのクライアントは、必ず近くのドメインコントローラーにアクセスしようとする。そして、近くのドメインコントローラーを見つける方法として、「サイト」を利用する。クライアントが自分と同じサイト内にあるドメインコントローラーを見つけるときには、やはりDNSサーバーのSRVレコードを利用する。実際に、DNSサーバーの中を見てみると、SRVレコードがサイトに分かれて保存されていることが分かる（画面1）。

画面1　DNSサーバーの「_sites」を展開すると、Tokyo、Osakaなどのサイトがあり、それぞれのサイトにSRVレコードが作られていることが分かる

インターネット向けのDNSサーバーとの関係

　そもそも、DNSサーバーはインターネット上にあるさまざまなサーバーの名前解決のために用意されるものであり、通常は自社内にインターネット向けのDNSサーバーを構築したり、サービスプロバイダーが提供するDNSサーバーを利用したりしているはずだ。

　一方、Active DirectoryのDNSサーバーは、ドメインコントローラーの居場所を特定するために特化したサーバーになる。

　DNSサーバーに格納されるインターネット向けの情報と、社内向けの情報は、セキュリティレベルがそれぞれ異なるので、同一サーバーに格納するべきではない。そのため、Active Directory環境ではインターネット向けと社内向け（Active Directory）で、別々のDNSサーバーを用意して運用することになるのだが、これでは二つのDNSサーバーの面倒を見ることになるため、運用が煩雑になる。そこで、一般にはDNSサーバーが搭載する「フォワーダー」機能を使って、運用の煩雑さを解決することになる。

　フォワーダーとは、クライアントからの問い合わせ（名前解決要求）を受け取ったDNSサーバーが答えが分からなかった場合、他のDNSサーバーに名前解決要求を丸投げする機能である（図2）。DNSサーバーはフォワーダーを使うことで、自分が頑張って何が何でも名前解決しようとするのではなく、分からないことは他人に聞くという潔さで、あらゆる名前解決要求に対応するのである。

図2　フォワーダーを使えば、両方のDNSサーバーから名前解決が受けられる

　こうして、インターネット向けのDNSサーバーと、Active DirectoryのDNSサーバーの両方にアクセスしなければならない場合でも、フォワーダー機能を使うことで、クライアントはどちらかのDNSサーバーにアクセスするだけで、二つのDNSサーバーから名前解決が受けられるようになる。

column【ダメなソリューション】二つのサーバーを参照するようにTCP/IPを設定する

　TCP/IP設定の画面を開くと、DNSサーバーアドレスを入力する欄が二つあることに気が付くだろう（「優先DNSサーバー」と「代替DNSサーバー」）。ここで、それぞれインターネット向けのDNSサーバー、Active Directory用DNSサーバーのアドレスを設定すれば、フォワーダーは必要ないのではと思うかもしれない。

　しかし、TCP/IP設定に二つのDNSサーバーを登録しても、同時にアクセスすることはなく、あくまでも「優先DNSサーバー」に登録したサーバーにアクセスできなかった場合に、「代替DNSサーバー」にアクセスするというだけなので注意してほしい（画面A）。

画面A　TCP/IPの設定には2つのDNSサーバー設定があるが、「代替DNSサーバー」は障害対応でしか使わない

インターネット向けとActive Directoryが同じ名前の場合の対処

　Active Directoryドメインには、さまざまな名前の付け方がある。一つは組織のドメイン名と同じ名前を、Active Directoryのドメイン名にする方法だ。名前を一つに集約できて、見た目の管理は簡単そうである。しかし、DNSの観点から言えば、一つだけ注意しなければならないことがある。それは、フォワーダーを使っても二つのDNSサーバーには同時にアクセスできないことだ。

　例えば、ドメイン名「example.com」を持つ組織が、Active Directoryのドメイン名も同じ「example.com」に設定したとしよう。組織のWebサイトやメールサーバーにアクセスするための情報を格納するDNSサーバー（外向けDNSサーバー）と、Active DirectoryのDNSサーバーを別々に用意して、Active DirectoryのDNSサーバーからは外向けDNSサーバーにフォワーダーを設定する。

　しかし、このフォワーダー設定では、組織内のクライアントコンピューターから外向けDNSサーバーの名前解決をすることはない。なぜなら、クライアントは「example.com」ドメインの名前解決をすでにActive DirectoryのDNSサーバーで行っており、Active DirectoryのDNSサーバーに保存されていない情報を探しに他の「example.com」ゾーンの情報を持つDNSサーバーにアクセスしても、そこで名前解決することはないからだ。

　そのため、組織のドメイン名とActive Directoryのドメイン名が同じ場合には、外向けのDNSサーバーに保存している情報と同じ情報を、Active DirectoryのDNSサーバーにも保存しておくことが最も現実的な運用となる。

ここまでに得た知識でDNSサーバーのトラブル解決にチャレンジ

　Active DirectoryのDNSサーバーは、クライアントからActive Directoryにアクセスする際に、その場所を確認するために使うと説明してきたが、実際どのような通信が発生するのかをここでまとめておこう（図3）。

図3　DNS関連のトラブルシューティングで見るべきチェックポイント

チェックポイント1

　まず、クライアントはドメインコントローラーの場所を確認するために、DNSサーバーにアクセスする。クライアントからDNSサーバーにアクセスするには、クライアントのTCP/IP設定で、DNSサーバーのIPアドレスが指定されていなければならない（図3のチェックポイント1）。

　また、IPv6が有効になっていたり、（二つのNICを搭載しているために）二つのネットワークにアクセスできるように構成されていることで参照するDNSサーバーが毎回異なっていたりなど、さまざまな理由で思い通りのDNSサーバーにアクセスできない場合にも注意しよう。

チェックポイント2

　クライアントの問題が解決し、無事DNSサーバーにアクセスできる状態になっていても、DNSサーバーに正しくレコードが登録されていなければドメインコントローラーの場所を特定することはできない。ということで、クライアントの次にチェックすべきは、DNSサーバーのレコードの設定になる（図3のチェックポイント2）。

　登録されているDNSサーバーのSRVレコードが正しいものであるかどうかは、目視で確認するのも一つの方法だ。だが、より簡単にトラブルシューティングを行うなら、SRVレコードを作り直すのもよいだろう。SRVレコードの作り直しは簡単で、ドメインコントローラー上でWindows PowerShellの「Restart-Service netlogon」コマンドレットを実行するだけである。

　なお、自動的に作成されたSRVレコードが正しいかどうかを確認したい場合には、あらかじめ正しい状態のSRVレコードの構成を保存しておき、それと比較してみるとよい。そのためにも、事前に以下の画面2のように、正常時のDNSサーバーのスクリーンショットを撮っておくことをお勧めする。

画面2　DNSサーバーの「_msdcs.＜ドメイン名＞」の部分と＜ドメイン名＞ゾーン配下の「_sites,_tcp,_udp,DomainDNSZones,ForestDNSZones」を展開して、それぞれの画面をキャプチャする

　ここまで、Active DirectoryにおけるDNSサーバーの必要性を見てきた。Active DirectoryのトラブルのほとんどはDNSが関係していると冒頭で説明したが、ここまで見てきたような仕組みでActive DirectoryのDNSサーバーが使われていることが分かれば、トラブルに遭遇しても、自分で問題の原因を推測し、問題を解決できるようになるだろう。