連載
» 2014年08月07日 18時00分 UPDATE

基礎から分かるActive Directory再入門(6):DNSサーバーはなぜ必要なのか

Active Directoryの設計や構築だけでなく、運用保守でもたびたび登場するDNSサーバー。今回は、Active Directoryとともに使われるDNSサーバーを見ていこう。

[国井傑(MVP for Directory Services),株式会社ソフィアネットワーク]
「基礎から分かるActive Directory再入門」のインデックス

連載目次

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 図1 クライアントがドメインコントローラーを見つけるまでの流れ

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

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

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

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

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

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

マイクロソフトが期間限定公開中 Active Directoryのスキルをブラッシュアップしよう!

 クラウドの登場により、Active Directoryに求められる役割も変化しつつあります。

 クラウドに対応させるためのActive Directoryの設計ポイントとはどにあるのか? iOSやAndroidは、Active Directoryにどう絡むのか? Azure Active Directoryとは何者か? 生産性を高めるためのセキュリティを実現するには、どのようなインフラが必要か?

 今こそ、Active Directoryの役割を再学習し、古い知識をリセットしましょう!


筆者紹介

国井 傑(くにい すぐる)

株式会社ソフィアネットワーク取締役。1997年よりマイクロソフト認定トレーナーとして、Active DirectoryやActive Directoryフェデレーションサービス(ADFS)など、ID管理を中心としたトレーニングを提供している。2007年よりMicrosoft MVP for Directory Servicesを連続して受賞。なお、テストで作成するユーザーアカウントには必ずサッカー選手の名前が登場するほどのサッカー好き。


Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。