直前必修問題集 Windows 2000 Directory Services Administration : 第 2 章 ‐ DNS と Active Directory の統合

  • [アーティクル]

第 2 章 ‐ DNS と Active Directory の統合

この文書は株式会社 IDG ジャパンの協力により株式会社 IDG ジャパン発行の書籍「直前必修問題集 MCP/MCSE 試験番号 70-217 Windows 2000 Directory Services Administration」の一部を抜粋したものです。

トピック

DNS の概要 DNS の概要
DNS ネームスペース DNS ネームスペース
DNS 構造の計画 DNS 構造の計画
DNS ゾーンの概要 DNS ゾーンの概要
Microsoft DNS の計画 Microsoft DNS の計画
DNS サーバーの構成 DNS サーバーの構成
DNS サーバーの管理 DNS サーバーの管理
WINS と DHCP の連携 WINS と DHCP の連携
DNS のトラブルシューティング DNS のトラブルシューティング
復習問題 復習問題
復習問題の解答 復習問題の解答

試験トピックス

  • Active Directory 用の DNS のインストール、構成、およびトラブルシューティング

    • Active Directory DNS と非 Active Directory DNS の統合

    • 動的更新用のゾーンの構成

  • DNS の管理、監視、およびトラブルシューティング

    • DNS データの複製の管理

DNS の概要

DNS (Domain Name System) は、IP (Internet Protocol) アドレスをホスト名に名前解決するための TCP/IP 標準である。

TCP/IP は、複数のコンピュータが 1 つのネットワーク上で連携して実行するためのいくつかの技術の集合である。TCP/IP の主な長所として、ハードウェア、ソフトウェア、およびネットワークデバイスで幅広くサポートされていること、標準認定の手順が信頼できること、およびスケーラビリティに富んでいることが挙げられる。
IP アドレスは、単なる数字であり、TCP/IP ネットワーク上でコンピュータを一意に識別するのに使用される。IP アドレスは、4 つのオクテット (8 つのバイナリビット) から成る。各オクテットは、0 から 255 までの十進数で表わされる。小数点は、十進数を論理的に区切る。有効な IP アドレスの例を次に示す。

  • 128.45.23.17

  • 230.212.43.100

  • 10.1.1.1

DNS は、IETF (Internet Engineering Task Force) によって定義されたインターネット標準に基づいている。DNS は、名前と IP アドレスの対応を格納した分散データベースを使った階層的なネームシステムである。DNS 名は、IP アドレスよりも親しみやすく覚えやすい。また、DNS はスケーラビリティと信頼性に優れているので、インターネットで広く普及している。

Active Directory は、DNS を使用してサーバーやクライアントを識別する。したがって、Windows 2000 オペレーティングシステムには、DNS サーバーサービスが組み込まれている。また、DNS データベースの管理を簡素化するために、多くの最新技術 (一部は IETF 非公認の技術) も組み込まれている。

ページのトップへ ページのトップへ

DNS ネームスペース

DNS 名の分析

DNS は、フレンドリーネームでネットワークアドレスに解決する。DNS 名は、小数点で区切られた、英数字からなる文字列の形をしている。また、DNS 名のさまざまな部分は「 DNS ネームスペース」と呼ばれるものを形成する。 DNS ネームスペース内の各アドレスは一意である。有効な DNS 名の例を次に示す。

DNS 名の最左端の部分は、「ホスト名」といい、実際のコンピュータの名前を示す。残りの部分は、ドメイン名の一部で、コンピュータが存在するネットワークを一意に指定する。完全な DNS 名は、完全修飾ドメイン名 (FQDN：Full Qualified Domain Name) という。たとえば、FQDN が engineering.microsoft.com の場合、ホスト名は engineering である。

DNS 名には次の機能と制限がある。

  • 階層的である アドレスの最右端に示されたドメインは、上位のドメインである。左になるにつれ、実際のホスト (コンピュータ) に近づいていく。つまり、DNS 名を左から右に読むと、ホスト名からホストを含むコンテナ名へと移っていくことになる。

  • 大文字小文字を区別しない DNS 名は読みやすくするために大文字と小文字の混在形で表示されることがあるが、大文字と小文字は区別されない。

  • どのネットワーク内でも各 FQDN は一意でなければならない 同一のネットワーク上の 2 台のコンピュータが同一の FQDN を持つことはできない。この要件により、各コンピュータが一意に識別されることが保証される。

  • 使用できる文字 DNS 名の各部分には、英数字とダッシュのみを使用できる。

  • アドレスの最大長 DNS アドレスの最大長は 255 文字である。完全修飾名の各部分の最大長は 63 文字である。

有効な階層ドメイン名の例を図 2.1 に示す。

702171

図 2.1: DNS ネームスペースの例

ルート

フレンドリーネームを IP アドレスに解決するには必要条件がいくつかある。すべての DNS 名は、ルートという 1 つのアドレスから派生する。通常、ルートアドレスは名前がなく、DNS 内で「.」として表わされる。ルートサーバーは最近まで 9 台しかなかったが、インターネットの爆発的な成長後に台数が増加し、管理方針が変わった。トップレベルドメインがルートサーバーに登録されるようになった。

世界規模の多くの組織では、ドメイン名をルートから解決する必要がある。これがトップレベルドメインの用途である。インターネットでは、既存のトップレベルドメインがいくつか存在する。北米の一般的なトップレベルドメインを表 2.1 に示す。各ドメイン空間は、表に示す特定の種類のユーザーのために予約されている。

表 2.1 北米トップレベルドメイン名

トップレベルドメイン

対象ユーザー

.com

営利組織

.edu

教育機関

.gov

U.S.政府機関

.int

国際組織

.mil

U.S. 国防機関

.net

大きなネットワークプロバイダ (インターネットサービスプロバイダなど)

.org

非営利組織

これらのトップドメイン名に加え、トップレベルドメインには多くの国コードがある。各国コードはそれぞれの関係機関が管理している。たとえば、イギリス国内の DNS 名は、mycompany.co.uk のようになる。外国のドメイン名を登録したい場合は、外国のドメイン名サービスプロバイダに問い合わせる必要がある。

組織独自のドメイン名がインターネット上で解決できるようにするためには、グローバルトップレベル DNS サーバーにセカンドレベルドメイン名を登録するように要求する必要がある。いくつかの登録機関がこの役割を果たしている。

T I P
自分の組織のドメイン名の登録方法については、www.internic.net を参照するとよい。ここには、利用できる世界中の登録機関が一覧できる。

たとえば、Company1.com など、インターネットに登録された名前はセカンドレベルドメイン名である。しかし、組織内ではドメイン名はすべてこのセカンドレベルドメインのサブドメインである。さまざまなレベルの DNS ドメイン名から形成される階層構造を図 2.2 に示す。

702172

図 2.2: DNS 名の階層

DNS ネームスペース構成の主な検討事項は、インターネット上で名前解決を行うかどうかということである。行わない場合は、独自のドメイン名を作成することができる。ただし、この方法では、自分のサーバーをインターネットから直接にアクセスできるように設定することができない。一方、公的なインターネット機関を通じて mycompany.com というドメイン名を登録し sales.mycompany.com や engineering.mycompany.com などのドメイン名を使用することもできる。この場合は、ISP (Internet Service Provider) が管理する DNS サーバーに依存して外部の名前解決を行うことになる。

親ドメイン名と子ドメイン名

組織がドメイン名を登録したら、そのドメイン名を DNS サーバーに登録する必要がある。DNS サーバーは、組織独自に管理していることもあれば、ISP などのサードパーティが管理していることもある。どちらの場合でも、システム管理者とネットワーク管理者は、トップレベルドメイン名を使って DNS サーバーに名前を追加できる。

ドメイン名はそれぞれ DNS サーバーに「リソースレコード (RR)」として登録される必要がある。レコードには、ドメイン名と IP アドレスの対応が記録されている。登録されたコンピュータのいずれかにユーザーが (Web ブラウザなどで) アクセスしようとした場合、ドメイン名は該当する TCP/IP アドレスに解決される。
DNS サーバーは、名前解決に関連するさまざまな機能を実行する。DNS 名マッピングの要求を実行する機能もその 1 つである。要求されたホスト名に関する情報が DNS サーバーにある場合、要求を発行したクライアントに適切な情報を返す。一方、指定されたホスト名に関する情報が DNS サーバーになかった場合、ほかの DNS サーバーから情報を取得する必要がある。この場合、名前解決と呼ばれる処理が必要になる。指定されたホスト名に関する情報がない名前を解決するために、DNS サーバーはほかの DNS サーバーに照会する。

ページのトップへ ページのトップへ

DNS 構造の計画

DNS ルートドメイン名の選択

組織の DNS 構造の構築の第一歩には、トップレベルドメイン名の選択がある。もっとも一般的に使用されるトップレベルドメイン名は .CO.JP (営利組織の場合) である。通常、企業名に基づいたセカンドレベルドメイン名を予約する。しかし、現在は非常に多くのドメインが登録されているので、その名前を登録するのが難しいこともある。どの場合でも InterNIC (Internet Network Information Center) に問い合わせて使用できるドメイン名を確認できる (www.internic.net) 。良いドメイン名とは、覚えやすくて企業がすばやく連想されるような名前である。適切なドメイン名を選択するための一般的な指針としては次のものが挙げられる。

  • 企業の名前に似た名前を選択する。

  • 通常は変更されない名前を選ぶ。たとえば、部門名や製品名は時が経つと変更されることがあるが、企業名はそれに比べると変更されにくい。

  • 名前の登録と使用の前に企業の経営責任者の承認を必ず得る。

  • 企業の法務部門 (または法律事務所) に相談し、ドメイン名が使用されておらず、ドメイン名の商標が他社によって保有されていないことを確認する。

ドメイン名が決定したら、その登録作業は非常に簡単でオンライン上でも完了できる。登録作業を開始するには、rs.internic.net に接続し、新しいドメイン名の登録のリンクにジャンプする。公式な登録機関を選択し、指示された内容に従う。

コンピュータがインターネットにアクセスできるようにするには、世界中に登録されたドメイン名が必要となる。名前登録処理の一部として、ドメイン名のホストとなる DNS サーバーの技術情報を提供しなければならないことがある。独自の DNS サーバーがある場合は、IP アドレスを教えるだけでよい。DNS サーバーがない場合は、多くの商用 ISP からドメイン名サービスを受けることができる。企業ドメイン名による DNS 名の解決を図 2.3 に示す。

702173

図 2.3: ルートドメインの解決

内部名と外部名の選択

インターネットルートドメイン名は外部名であり、コンピュータをインターネット上で公的にアクセスできるようにするためのものである。これとは別に、内部ネットワーク用のドメイン名も必要なことがある。内部ドメイン名は、外部ドメイン名と同一の場合もあれば、異なる場合もある。内部名を管理する場合、独自の基準で名前を選択できる。一方、外部名はどれもインターネット名前登録機関に適切に登録する。異なる内部 DNS 名と外部 DNS 名を使用する例を図 2.4 に示す。

702174

図 2.4: 異なる内部 DNS 名と外部 DNS 名

ページのトップへ ページのトップへ

DNS ゾーンの概要

DNS ゾーンの目的と機能

分散ネットワーク環境で命名の正確性を保つには、1 台の DNS サーバーを特定のアドレスの集合のマスタデータベースに指定しなければならない。ホスト名と IP アドレスの対応の更新は、このサーバー上で行う。DNS サーバーが指定された DNS 名を解決できない場合は、情報を提供できるほかのサーバーを照会する。多くの異なる DNS サーバーが同一の情報を受け取らないようにするために、ゾーンが必要である。変更が行われると、この情報は最新のものではなくなる。したがって、1 台の DNS サーバーがドメイン名の特定のサブセットに関する絶対的な権限を有する役割を担う必要がある。

N O T E
DNS ゾーンと Active Directory ドメイン間の違いは重要である。どちらも階層名を使用して名前解決を必要とするが、DNS ゾーンと DNS ドメインとは直接には対応しない。

DNS ゾーンは、図 2.5 に示すようにドメイン全体に対応することもドメインの一部に対応することもある。

702175

図 2.5: DNS ドメインと DNS ゾーンの関係

DNS 名前解決

インターネットを使用する場合、DNS クエリーは非常に頻繁に発行される。たとえば、Web サイトへ行くためにリンクをクリックするたびに DNS クエリーが発行される。最も単純なシナリオでは、指定された DNS サーバーにクライアントコンピュータが DNS アドレスを要求する。DNS サーバーは、要求されたホスト名のIPアドレスの情報がある場合、情報をクライアントに返す。クライアントは、IP アドレスを使ってホストとの通信を開始する。このプロセスを図 2.6 に示す。

702176

図 2.6: 単純な DNS 名解決プロセス

一方、要求されたホストの情報が DNS サーバーにない場合、DNS サーバーは名前解決のためにほかの DNS サーバーにクエリーを発行する。第二の DNS サーバーが要求を満たさない場合、さらにほかの DNS サーバーにクエリーが発行される。このプロセスを、「再帰」という。再帰のプロセスでは、ホスト名が解決されるまで次々と DNS サーバーにクエリーが発行される。名前解決プロセスは、通常はトップレベル DNS サーバーへのクエリーで開始され、リソースに到達するまでドメイン階層を下がっていく。この時点で名前が解決できない場合、クライアントへエラーが返される。再帰のプロセスを図 2.7 に示す。通常、DNS サーバーにはルート DNS サーバーやトップレベル DNS サーバーの情報が保持され、この情報はサーバーの初期構成時に入力される。

702177

図 2.7: 再帰による DNS 名前解決

複数の DNS サーバーにクエリーを発行するようにクライアントを構成できる。このプロセスを「反復」という。通常、クライアントが DNS サーバーにクエリーを発行したが、再帰を使用できないと通知されたときに、反復が使用される。または、システム管理者が DNS サーバーで再帰を実行しないように構成することもできる。たとえば、名前解決要求をネットワーク上の1台の DNS サーバーに転送するようにすべての DNS サーバーを構成することができる。これにより、1 台の DNS サーバーにすべての DNS トラフィックが転送されるので、DNS 要求を処理しながら、ネットワークトラフィックが削減される。

反復プロセスでは、要求された情報がある場合は DNS サーバーが要求に応答する。情報がない場合は、エラーを返すか名前解決ができそうなほかの DNS サーバーをクライアントに通知する。反復では、名前要求の解決の最終責任はクライアントにある。
通常、検索順序を指定された複数の DNS サーバーを指定してクライアントが構成される。この機能は、イントラネット名とインターネット名を解決するのにそれぞれ別の DNS サーバーが必要な場合などに役に立つ。この方法では、正しいネームサーバーを見つける責任はクライアントにある。構成によっては、DNS 「フォワーダ」によりネットワークトラフィックを削減できる。DNS フォワーダは、名前解決に使用される DNS サーバーを正確に指定できる。たとえば、高速なネットワーク (LAN) 上に複数の DNS サーバーがある場合、ネットワーク上のほかの DNS サーバーから情報を取得できる DNS サーバーをいくつか決めておき、指定した DNS サーバーに DNS 情報を要求構成できる。DNS フォワーダの使用例を図 2.8 に示す。

702178

図 2.8: ネットワークトラフィックを削減する DNS フォワーダ

DNS サーバーのほかの機能として、情報をキャッシュすることができる。DNS クエリーのたびに再帰プロセスを繰り返すと世界中のサーバーに大きな負担がかかる。通常はトラフィックを少しでも減らすために、DNS サーバーはマップしたドメイン名の情報をローカルデータベースに保存する。同じホスト名やドメイン名に対する要求がまた発行されたら、通常はこのキャッシュされた情報が使用される。キャッシュされている情報が常に最新のものであるようにするために、キャッシュされた DNS レコードにはそれぞれ TTL (Time to Live) 値が割り当てられる。一般的な TTL 値は 3 日から 7 日で、この時間制限を超えるとキャッシュされた情報は使用されなくなる。次に情報が要求されたときには、再帰プロセス全体が繰り返される。

N O T E
DNS 名はプル方式で更新されるので、データベース更新に時間がかかる DNS サーバーもある。DNS エントリへの変更が必要な場合、インターネット上のすべてのネームサーバーで更新が完了するだけの時間を見積もる必要がある。通常は数日で完了するが、1 週間を超えることもある。

DNS の最も主要な機能は DNS 名から IP アドレスへのマッピングであるが、アプリケーションによっては正反対の機能が必要になることがある。つまり、IP アドレスから DNS 名への変換である。これは DNS サーバーの「逆引き参照ゾーン」によって処理される。逆引き参照ゾーンは特殊なインターネット特権アドレスから開始される。逆引き参照ゾーンを使うと、指定された TCP/IP アドレスのクエリーを DNS サーバーが解決できる。この逆引き参照ゾーンは、通常の「前方参照ゾーン」と同様にして構成される。

DNS ゾーンの権限の委任

ドメインにサブドメインを追加した場合、次の 2 つの方法が選択できる。第一に、既存の DNS サーバーが「親ドメインと子ドメイン」の権限をもって機能することができる。第二に、新たに DNS ゾーンを作成し、そのゾーンの権限をほかの DNS サーバーに委ねることもできる。特定のドメインの権限をほかの DNS サーバーに付与することを「委任」という。委任の構成方法を図 2.9 に示す。

702179

図 2.9: DNS 権限を複数の DNS サーバーに委任する

委任をする主な理由は、パフォーマンスと管理である。大規模なネットワークでは、複数の DNS サーバーを使用すると名前解決の負荷を分散できる。委任は、指定されたシステム管理者が特定の種類のレコードしか修正できないように設定することにより、セキュリティ管理にも役立つ。

DNS サーバーの役割

ドメインの権限を有する DNS サーバーを構成するときに問題となるのは、フォールトトレランスについてである。DNS 仕様では、1 台の DNS サーバーに障害が発生してもネットワークに問題が発生しないように 1 つのゾーンに複数の DNS サーバーを使用できるようになっている。

DNS サーバーは、分散階層型ネームシステムを維持するためにいくつかの異なる役割を担うことができる。

プライマリ DNS サーバー

DNS ゾーンには、「プライマリ DNS サーバー」が 1 台なければならない。プライマリ DNS サーバーは、DNS ゾーンのすべてのレコードの管理を受け持ち、DNS データベースのプライマリコピーを保持する。さらに、レコードの更新はすべてプライマリサーバー上で行われる。新しく DNS ドメインを作成するごとに、プライマリ DNS サーバーを作成または追加する。一方、子ドメインを作成する場合は、親ドメインのプライマリ DNS サーバーを使用できる。

セカンダリ DNS サーバー

「セカンダリ DNS サーバー」には、プライマリ DNS サーバーとまったく同一の情報のデータベースが保持され、DNS 要求の解決に使用できる。セカンダリ DNS サーバーの主な目的は、フォールトトレランスの確保である。つまり、プライマリ DNS サーバーが利用できない状態になっても、セカンダリ DNS サーバーを使って名前解決を続行できる。したがって、障害に備えて各ゾーンには 1 台以上のセカンダリ DNS サーバーを設置するのが一般的である。

セカンダリ DNS サーバーは、プライマリ DNS サーバーへ向かうトラフィックを分担するので、パフォーマンスの向上にも役立つ。セカンダリ DNS サーバーは、組織内で高速ネットワークアクセスのある範囲に設置される。これにより、DNS クエリーが低速な WAN 接続を通る必要がなくなる。
セカンダリ DNS サーバーを設置するのはよいが、あまりに多く設置しすぎると複製によるネットワークトラフィックが増える。したがって、セカンダリ DNS サーバーの計画時には、その長所と短所を常に慎重に検討する必要がある。

マスタ DNS サーバー

「マスタ DNS サーバー」は、プライマリ DNS サーバーとセカンダリ DNS サーバー間の DNS データの複製に使用される。通常、プライマリ DNS サーバーはマスタサーバーの役割も果たすが、パフォーマンス上の理由によりマスタサーバーの処理を切り離すこともできる。マスタ DNS サーバーは、DNS データベースへの変更をゾーン内のすべてのセカンダリ DNS サーバーに反映させる役目を持つ。

キャッシュ専用 DNS サーバー

「キャッシュ専用 DNS サーバー」は、クライアントの要求に応えて DNS 名をネットワークアドレスに解決する点でプライマリ DNS サーバーと同じ機能を果たす。違いは、キャッシュ専用 DNS サーバーは DNS ゾーンの権限を持たず、ゾーンファイルのコピーを保持しない点である。キャッシュ専用サーバーには、解決されたクエリーのマッピングだけが保持され、サーバーがシャットダウンされると情報はすべて失われる。したがって、キャッシュ専用 DNS サーバーはパフォーマンス上の理由によってのみ設置される。キャッシュ専用 DNS サーバーは、ほかのサイトの DNS サーバーに低速リンクで接続されているサイトなどで使用される。

ゾーン転送

ドメインコントローラや Active Directory と同様に、プライマリ DNS サーバーとセカンダリ DNS サーバー間で DNS ゾーン情報が一貫していることは重要である。これらのサーバーを同期するプロセスを「ゾーン転送」という。セカンダリ DNS サーバーが構成されると、セカンダリ DNS サーバーは最初にゾーン転送を実行し、プライマリ DNS サーバーのアドレスデータベースのコピーを取得する。このプロセスを全ゾーン転送 (AXFR) という。

初期の同期の後に情報を最新の状態に保つには、増分ゾーン転送 (IXFR) が実行される。増分ゾーン転送では、DNS ゾーンデータベースの変更部分だけがプライマリ DNS サーバーとセカンダリ DNS サーバー間で通信される。IXFR では、どのレコードが更新されたり追加されたりしたかをシリアル番号によって識別する方式が使用される。この方式により、複数の DNS サーバーで変更が行われても、最新の DNS レコードが常に使用されるようになる。
ゾーン転送は、次の状況で実行される。

  • ゾーン更新間隔が経過した。

  • マスタ DNS サーバーがセカンダリ DNS サーバーにゾーン変更を通知した。

  • ゾーンでセカンダリ DNS サーバーサービスが新しく開始された。

  • DNS ゾーン転送は、(システム管理者によって) セカンダリ DNS サーバーで手動で開始される。

ゾーン転送で重要なのは、セカンダリ DNS サーバーが常に実行を開始するということである。一般に、こういう複製をプル処理という。通常、ゾーン転送はセカンダリ DNS サーバーで更新間隔が過ぎたときに実行される。ゾーン転送の要求は「マスタサーバー」に送信され、マスタサーバーはセカンダリ DNS サーバーに変更を送信する。また、プライマリ DNS サーバーはマスタサーバーとして構成されるが、パフォーマンス上の理由によりマスタサーバーを分離することもできる。

プル複製の問題点の 1 つとして、セカンダリ DNS サーバーの情報が最新でないことがある。たとえば、今日に IXFR を実行して更新間隔が 3 日後に設定されていたとする。プライマリ DNS サーバーで変更を行うと、この変更は数日間セカンダリ DNS サーバーに反映されないことになる。この問題の回避方法として非常に短い更新間隔 (数時間など) を設定できる。しかし、このような設定は、不要なネットワークトラフィックと処理上のオーバーヘッドを増加させる。
リソースレコードを最新の状態にするときに起こる問題を解決するために、DNS 通知という機能が開発された。この方法は、プッシュ複製方式により、変更が起こったときにセカンダリ DNS サーバーに通知する。セカンダリ DNS サーバーは、DNS 通知メッセージを受け取るとすぐに IXFR 要求を発行する。DNS 通知によりセカンダリ DNS サーバーの情報を最新の状態にする例を図 2.10 に示す。この方法により、変更が起こったらすぐに互換 DNS サーバーが更新されるようになる。

7021710

図 2.10: DNS 通知によるセカンダリ DNS サーバーの更新

DNS リソースレコードの管理

表 2.2 は、DNS データベースで使用されるレコードの種類を示す。各レコードは、適切な種類のリソースが利用できるようにするために重要なものである。

表 2.2 DNS リソースレコードの種類

リソースレコードの種類

意味

説明

A

Address

ホスト名を IP アドレスにマップするのに使用される。1 つの IP アドレスをマップするのに、複数のアドレスレコード (A レコード) を使用できる。

CNAME

Canonical Name

(A レコードに加えて) ホストのエイリアスまたはニックネームとして使用される。

MX

Mail Exchanger

ドメインの SMTP (Simple Mail Transfer Protocol) メールサーバーのアドレスを指定する。

NS

Name Server

PTR

Pointer

逆引き参照処理に使用される。

RP

Responsible Person

DNS 情報の管理を担当する人員の情報を指定する。

SOA

Start of Authority

ゾーンの権限を有するサーバーを指定する。

SRV

Service

ホスト上で利用できるサーバーサービスを指定する。ドメインコントローラを識別するために Active Directory で使用される。SRV レコードの規格はまだ完成していない。

さらに、インターネットではいくつかの慣用表現がある。たとえば、mail、www、ftp、および news などのホスト名は、通常は E-mail、World Wide Web、ファイル転送プロトコル、および USENET ニュースの各サーバー用に予約されている。

ページのトップへ ページのトップへ

Microsoft DNS の計画

DNS ゾーンの計画

DNS サーバー設置の第一歩は、DNS ゾーンのサイズとレイアウトを決定することである。もっとも単純な構成は、1 つの Active Directory ドメインと 1 つの DNS ゾーンである。通常、この構成はシングルドメイン環境の要件を満たす。

一般に、複数のドメインを検討する場合は、DNS の計画時にいくつかの選択を行う必要がある。環境によっては、すべてのドメインにまたがる1つのゾーンを使用する場合もある。または、管理上やパフォーマンス上の理由から複数のゾーンを使用する場合もある。
選択した DNS ゾーン構成は、Active Directory 構成にはほとんど影響しない。つまり、どんな Active Directory 構成であっても、名前さえ正しく解決できれば、どんなゾーン構成も使用できる。DNS ゾーンが正常に動作することが Active Directory の動作には不可欠である。

ページのトップへ ページのトップへ

DNS サーバーの構成

DNS ゾーンの追加

DNS サービスをインストールしたら、自分の環境に合わせて DNS を構成する必要がある。適切に DNS を構成するのに最も重要なのは、計画である。これまでの説明で得られた情報に基づいて、Active Directory 環境に適した DNS ゾーンを構成する計画を慎重に検討しなければならない。

[DNS サーバーの構成] ウィザードを使用すれば、実際の構成手順は非常に簡単である。
ネットワーク環境で 1 台の DNS サーバーに複数のゾーンを管理させる必要がある場合、再び [DNS サーバーの構成] ウィザードを実行するか、利用可能なオプションを使用できる場合は、サーバー名を右クリックし、表示されたメニューから [新しいゾーン] をクリックする。

DNS ゾーンのプロパティ構成

DNS サーバーの前方参照ゾーンと逆引き参照ゾーンを正しく構成したら、[DNS] 管理ツールでゾーン名を右クリックし、表示されたメニューから [プロパティ] をクリックすることで、追加の構成を設定できる。前方参照ゾーンでは、次のタブと設定が利用できる。

[ 全般 ] タブ
[全般] タブでは、前方参照ゾーンのさまざまなオプションを設定できる。このタブ (図 2.11 参照) では、DNS サービスを一時停止できる。DNS サービスを一時停止すると、実行は続行されているが、クライアントはこのコンピュータの名前解決要求を完了できなくなる。第 2 のオプションは、ゾーンの種類の変更である。種類には、標準プライマリ、標準セカンダリ、および Active Directory 統合 (Active Directory がインストール済みの場合のみ) の 3 種がある。DNS ゾーンファイルの名前も指定できる。動的更新を有効にすると、リソースレコードの作成に関する保守管理の手間が省けて非常に便利である。さらに、このゾーンの [エイジング] プロパティを設定できる。

7021711

図 2.11: [全般] タブでのプロパティ設定

[SOA (Start of Authority)] タブ
[SOA (Start of Authrity)] タブには、DNS サーバーの権限 (図 2.12 参照) に関する情報を指定できる。[シリアル番号] ボックスは、セカンダリ DNS サーバーを更新するのにゾーン転送が必要かどうかを指定する。たとえば、セカンダリ DNS サーバーのシリアル番号が 7 でSOA (Start of Authority) シリアル番号が6の場合、そのセカンダリ DNS サーバーはゾーン転送を要求できる。[プライマリサーバー] ボックスには、ゾーンのプライマリ DNS サーバーを指定できる。[責任者] ボックスには、DNS サーバーのシステム管理者の連絡先情報を指定できる。[更新間隔] ボックスには、セカンダリゾーンの情報を確認する間隔を指定できる。時間を短くすると、正確性が増すがネットワークトラフィックが増える。[再試行間隔] ボックスには、ゾーン転送が要求される頻度を指定する。[期限] ボックスには、セカンダリ DNS サーバーがリソースレコードを期限切れにする前に更新情報を要求しなければならない期間を指定できる。[最小 TTL 値 (既定)] ボックスには、リソースレコードが最新の状態であるとみなされる期間が指定される。変更が多い環境の場合、TTL 値を低くすると、情報の正確性が保たれる。

7021712

図 2.12: [SOA (Start of Authority)] タブでのゾーンプロパティの設定

[ ネームサーバー ] タブ
[ネームサーバー] タブには、指定されたドメインの DNS サーバーの一覧が表示される。ネットワークの構成に応じて特定の DNS サーバーを追加できる。一般に、ネームサーバーの一覧にはゾーン内のプライマリネームサーバーとセカンダリネームサーバーが含まれる。

[WINS] タブ
[WINS] タブでは、WINS (Windows Internet Naming Service) 参照で DNS 名を解決できるようにするためのオプションを指定できる。

[ゾーンの転送] タブ
[ゾーンの転送] タブのオプションを使うと、ゾーンのプロパティに指定された前方参照ゾーンのセカンダリ DNS サーバーとして機能するサーバーを選択できる。デフォルトオプションでは、どのサーバーもゾーン転送を要求できるが、ゾーン転送要求を制限することもできる。制限するには、IP アドレスを指定するか、[ネームサーバー] タブに表示されているネームサーバーだけに制限することを指定する。ゾーン転送を制限すると、不正にアクセスしたユーザーが DNS データベース全体をコピーすることを避けられるので、セキュリティを改善できる。

DNS サーバーオプションの構成

DNS レコードデータベースは、古い情報を定期的に削除する処理がないと、古い情報でいっぱいになりがちである。DNS データベースの使用されていない古いエントリを削除する処理を清掃という。清掃では、システム管理者が一定の期間ごとに DNS レコードがリフレッシュされるように設定できる。DNS レコードが一定の期間リフレッシュされない場合、次の DNS クエリーによりそのレコードは更新される。デフォルトでは、DNS サーバーはまったくこの処理を行わないように設定されている。

[DNS] スナップインで清掃を実装するには、設定を適用したいサーバー名または DNS ゾーン名を右クリックし、表示されたメニューから [エイジング] をクリックする。たとえば、サーバー名を右クリックして [すべてのゾーンに対しエイジング / 清掃を設定する] を選択すると、指定したエージングと清掃の設定はこのサーバーが管理するすべての DNS ゾーンに適用される。図 2.13 に示すように、次の 2 つのオプションを指定できる。

  • 非更新間隔 DNS レコードが更新されるまでの最小時間を指定できる。高い値を指定すると、ネットワークトラフィックを削減できるが、古い情報がクライアントに返される可能性も高くなる。

  • 更新間隔 非更新間隔が経過した時点とリソースレコードが更新の対象になる時点の間の時間を指定できる。低い値を指定すると、情報が非常に正確になるが、ネットワークトラフィックが増える。

7021713

図 2.13: エイジングと清掃オプションの設定

[DNS] スナップインで DNS サーバーのプロパティにアクセスするには、サーバーの名前を右クリックし、表示されたメニューから [プロパティ] を選択する。次のオプションが利用できる。

[ インターフェイス ] タブ
複数のネットワークアダプタを装備したサーバーでは、その 1 つのインターフェイスだけで DNS サービスを実行したいことがある。デフォルトオプションではすべてのインターフェイスで DNS 要求が許可されるが、特定のアダプタにだけ処理を制限することができる。制限するには、[指定した IP アドレスのみ] オプション (図 2.14 参照) をクリックする。

7021714

図 2.14: DNS サーバーインターフェイスの選択

[ フォワーダ ] タブ
DNS フォワーダでは、DNS サーバーで解決できない DNS 要求をすべて指定されたコンピュータに転送するように構成できる。

[ 詳細 ] タブ
DNS サービスには、サーバー全体で DNS 再帰を無効にするなど、いくつかの詳細オプション (図2.15参照) がある。

[ ルートヒント ] タブ
インターネット上でドメイン名を解決するには、ローカル DNS サーバーがワールドワイドルートサーバーを識別できなければならない。デフォルトでは、いくつかの有効なルート IP アドレス (図 2.16 参照) で Microsoft の DNS サーバーが構成される。さらに、必要に応じてルートヒントを追加または修正できるが、構成情報を確認した上で行う必要がある。

7021715

図 2.15: DNS サーバーの詳細な構成オプション

7021716

図 2.16: DNS サーバーのデフォルトルートヒント

[ ログ ] タブ
さまざまな DNS 処理のログ収集は、DNS サービスの監視とトラブルシューティングに役立つ。このタブのプロパティでは、さまざまなイベントを選択できる。

[ 監視 ] タブ
[監視] タブは、DNS サービスが適正に動作していることをすばやく確認するのに役立つ。このタブでは、再帰要求や単純なクエリーを実行できる。両方の処理が成功すれば、DNS サーバーが正常に動作していると結論してもよい。

DNS リソースレコードの作成

DNS サーバーの主な機能は、保持されているさまざまなリソースレコードに基づいている。Active Directory のインストール処理では、Active Directory を使用するように DNS サーバーを自動構成するオプションが用意されている。表 2.3 のリソースレコードは、自動的に作成される。これらのレコードの種類は、SRV (Service) である。ドメイン識別子とドメインツリー識別子は、ローカルドメインコントローラの DNS ドメイン名に基づく。サイト識別子は、サイト構成に基づく。

表 2.3 デフォルトの Active Directory DNS リソースレコード

リソースレコード

説明

_ldap._tcp.Domain

ドメイン内のドメインコントローラを数える。

_ldap._tcp.Site.sites.Domain

特定のサイト内のドメインコントローラをクライアントが見つけられるようにする。

_ldap._tcp.pdc.ms-dcs.Domain

ドメイン内でWindows NTプライマリドメインコントローラ (PDC) として機能しているサーバーのアドレスを記録する。

_ldap._tcp.pdc.ms-dcs.DomainTree

ドメイン内のグローバルカタログサーバーを数える。

_ldap._tcp.Site.gc.ms-dcs.DomainTree

サイト構成に基づいてクライアントがグローバルカタログサーバーを見つけられるようにする。

_ldap._tcp.GUID.domains.ms-dcs.DomainTree

GUID (Global Unique IDentifier) により、コンピュータを識別するのに使用される。

_ldap._tcp.writable.ms-dcs.Domain

Active Directoryの修正可能なコピーを保持するドメインコントローラを数える。

_ldap._tcp.site.sites.writable.ms-dcs.Domain

サイトに基づくドメインコントローラを数える。

デフォルトの DNS レコードに加えて、ネットワーク上で特定のサーバーやクライアントを識別するために新しい DNS レコードを作成することもある。

ページのトップへ ページのトップへ

DNS サーバーの管理

DNS ゾーンでの自動更新の構成

DNS ゾーンの自動更新をできるようにすると、リソースレコードの管理作業が大幅に軽減される。

DNS ゾーン委任の作成

DNS サーバーを DNS ゾーンのプライマリサーバーとして構成すると、DNS サーバーは DNS ゾーン内のすべてのリソースの名前解決を実行する責任を負う。場合によっては、DNS ゾーンの一部の権限をほかの DNS サーバーに委任することがある。

DNS 複製の管理

DNS 複製の管理は、重要事項である。最適な設定を行わないと、発生する複製トラフィックが多すぎたり、または正反対の問題が起こったりする。つまり、更新の頻度が不十分になる。

DNS の相互運用性の管理

純粋な Windows 2000 環境では、Microsoft の DNS サービスのみを使用することになるだろう。一方、実際の場面 (特に大規模な環境では) では、Microsoft の DNS サービスをほかの DNS 実装と相互運用しなければならないことがある。一般的な UNIX での DNS 実装は、BIND (Berkeley Internet Name Domain) サービスである。Active Directory では、SRV レコードの使用が不可欠であり、オプションで DNS 動的更新をサポートしている。両方をサポートする BIND のバージョンはバージョン 8.2.1 以降である。Active Directory の DNS サーバーとして BIND サーバーを使用する場合は、バージョン 8.2.1 以降でなければならない。相互運用のためにさまざまな DNS サーバー設定を構成する前に、使用している DNS システムでどの機能がサポートされているかを確認する必要がある。

ページのトップへ ページのトップへ

WINS と DHCP の連携

DHCP の概要

TCP/IP の構成には、非常に大量の手作業が必要である。Windows 環境での TCP/IP クライアントで必要とされる情報の一部には、次のものがある。

  • TCP/IP アドレス

  • サブネットマスク

  • デフォルトゲートウェイ

  • DNS サーバー

  • DNS ドメイン名

  • WINS サーバー

さらに、ほかの TCP/IP サービスも設定する必要がある。たとえば、ネットワークで NTP (Network Time Protocol) を使用している場合、タイムサーバーアドレスの情報も送信されなければならない。小さなネットワークでさえ、これらの情報を管理するのは厄介な仕事であることはすぐにわかる。まして大きなネットワークであれば、適切な情報を設定するための技術的および管理上の問題は膨大なものになる。DHCP (Dynamic Host Configuration Protocol) は、これらの問題をいくぶん緩和する。DHCPでは、クライアントコンピュータが最初にネットワークに接続したときに、TCP/IP アドレス情報が自動的に割り当てられる。一般的な処理手順を次に示す。

  • クライアントコンピュータがネットワーク上で初期化される。ブートアップ処理中に、DHCP サーバーに情報を要求するブロードキャストが送信される。

  • DHCP サーバーが存在する場合は、要求を受信し有効な割り当てアドレスのデータベースから IP アドレスを生成する。要求を送信してきたクライアントに TCP/IP 情報のオファーを返信する。

  • クライアントはパケットを受信し、オファーを承認するという確認応答を DHCP サーバーに返信する。

  • DHCP サーバーは、確認応答をクライアントに送信してから IP スタックを修正する。DHCP サーバーは、アドレスがクライアントに割り当てられている間は重複して使用されることがないようにする。

DHCP プロセスの例を図 2.17 に示す。

7021717

図 2.17: DHCP リースの取得

複数の DHCP サーバーがネットワーク上にある場合は、単純にクライアントは最初に応答した DHCP サーバーから IP アドレスを受ける。大部分のネットワークで IP アドレスは有限なリソースなので、一般に DHCP サーバーはクライアントに割り当てる IP アドレスごとにリース期間を設定している。一般的なリース期間は、ラップトップコンピュータなどの携帯型ワークステーションのネットワークではおよそ 3 日から 5 日であり、固定された環境ではもっと長い期間になる。クライアントは、この期間中に IP アドレスリースを更新しなければならない。更新しない場合、リース期間終了後、ほかのクライアントが利用できるようになる。

クライアントに割り当てることができる TCP/IP アドレスプールを DHCP スコープという。スコープは、IP アドレスの範囲とサブネットマスクからなる。さらに、スコープオプションは、デフォルトゲートウェイ、DNS サーバー、および WINS サーバーなどのほかの TCP/IP パラメータを指定するのに使用できる。
DHCP サービスのフォールトトレランスを確保するには、同一のネットワーク上に複数の DHCP サーバーを設置するのが一般的である。しかし、重複した IP アドレスの割り当てに関する問題を避けるため、それぞれの DHCP サーバーのスコープは重ならないように構成される。

DHCP と DNS の統合

DHCP サービスは、自分のデータベースにすべての IP アドレスの割り当てを記録している。Windows 2000 の DNS 実装では、クライアントコンピュータの DNS エントリの管理作業を簡素化するために DHCP 情報からホストのアドレスレコード (A レコード) が自動作成される。Windows 2000 の動的更新が有効であれば、クライアントが A レコードを更新し、DHCP サーバーがクライアントの PTR レコードを更新する。しかし、DHCP 情報が DNS サーバーに送信される方法はクライアントごとに異なる。クライアントの種類に応じて、次の 2 種類の DHCP/DNS 統合がある。

Windows 2000 クライアント
Windows 2000 DHCP クライアントには、IP アドレスを受け取った直後に自動的に更新を動的 DNS サーバーに送信する機能がある。この方法では、新しいアドレスを登録する責任はクライアントにある。この方法では、DNS データベースの更新を行うかどうかをクライアントが指定できる。

Windows 2000 以前のバ ージョンのクライアント
Windows 95/98 と Windows NT 4.0 用の DHCP クライアントコードは、動的 DNS 更新をサポートしない。したがって、DHCP サーバーは独自に DNS の A レコードと PTR レコードを更新する必要がある。

クライアントの種類に応じた動的 DHCP/DNS 更新の 2 つの方法を図 2.18 に示す。

7021718

図 2.18: 動的 DHCP/DNS 更新

DHCP からの情報による DNS の動的更新を実装するには、[DHCP] 管理ツールでサーバー名を右クリックし、表示されたメニューから [プロパティ] をクリックする。[DNS] タブ (図 2.19 参照) が表示される。

7021719

図 2.19: DHCP 管理ツールによる DNS オプションの設定

[DNS] タブのオプションを次に示す。

  • DNS の DHCP クライアント情報を自動的に更新する このオプションでは、クライアントからの動的 DNS 更新を有効にできる。この選択は、Windows 2000クライアントにのみ適用される。システム管理者は次の2つのどちらかを選択できる。

    • DHCPクライアントから要求があったときのみ DNS を更新する。

    • DNS を常に更新する。

  • リース期限が切れたときに、前方参照 ( 名前からアドレス ) を廃棄する このオプションがチェックされると、リースが時間内に更新されない限りクライアントの DNS エントリが自動的に削除される。このオプションを使用すると、古いエントリが DNS データベースに残らないので便利である。

  • 動的更新をサポートしない DNS クライアントの更新を有 効にする Windows NT 4.0、Windows 95、または Windows 98 の DHCP クライアントを使用しており、動的 DNS 更新を使用する場合、このオプションを使用するとよい。このオプションが設定されると、新しい IP アドレスが割り当てられるたびに DNS データベースを更新する責任は DHCP サーバーにある。

WINS の概要

Windows NT 4.0 以降には TCP/IP がデフォルトの基本プロトコルであるが、Windows 2000 以前のバージョンでは NetBIOS プロトコルのみを使用している場合が多い。WINS は、クライアントが NetBIOS over TCP/IP プロトコルを使用してホスト名をネットワークアドレスに解決できるようにするサービスである。WINS を使用する主な利点は、WINS はほとんど自動的に構成され管理も自動で行われる点である。つまり、サーバーがクライアントのアドレスを認識するごとに、名前は自動的に WINS データベースに追加される。これにより、ネットワークのブラウジングが容易になる。大規模環境では、WINS にはいくつかの制約がある。第一に、多くのクライアントが WINS データベースに登録されると WINS のパフォーマンスは低下しはじめる。第二に、WINS データベースの複製機能は、ほかの方法 (DNS など) に比べて強力でない。

Windows 2000 と Active Directory により、WINS の必要はまったくなくなった。しかし、大部分のネットワークでは、ダウンレベルクライアント (Windows NT 4.0、Windows 95、および Windows 98 などのコンピュータ) 向けの下位互換性のためにまだWINSが必要である。したがって、Windows 2000 には WINS の改良版が用意されている。WINSと DNS という2種類の名前解決方式を管理しやすくするために、Windows 2000 ではホスト名が DNS サーバーのデータベースになかった場合に、WINS レコードへ自動的に問い合わせることができる。この処理は WINS 参照といい、サーバー側で実行され、クライアントの特別な構成は必要ない。

WINS と DNS の統合

自動更新処理を有効にするには、[DNS] 管理ツールで前方参照ゾーンの名前を右クリックし、表示されたメニューから [プロパティ] をクリックする。[WINS] タブで動的更新のオプション (図 2.20 参照) を設定する。

7021720

図 2.20: WINS 更新の設定

次のオプションを設定できる。

  • WINS 前方参照を使う このチェックボックスをオンにすると、DNS サーバーがホスト名要求を解決できなかった場合に 1 台以上の WINS サーバーに問い合わせるようになる。DNS サーバーは、DNS データベースに WINS レコードというレコード種類を新しく追加する。

  • このレコードを複製しない このオプションでは、WINS レコードがゾーン転送で送信されなくなる。したがって、WINS レコードはドメイン内のほかのセカンダリ DNS サーバーには送信されない。ネットワークで使用している DNS サーバーが Windows 2000 のものではなく、WINS レコードタイプがサポートされていない場合は、エラーを避けるためにこのオプションを使用する。

  • IP アドレス 名前解決で接続するサーバーの IP アドレスを指定できる。DNS データベースでの参照が失敗したら、ここで指定されたサーバーにホスト名情報が照会される。IP アドレスの順番は意味を持つ。つまり、一覧で上位にある WINS サーバーアドレスは、下位にあるアドレスよりも先に接続される。

これらのオプションを構成すると、DNS サーバーは自分のデータベースで名前解決ができなかった場合には、指定された WINS サーバーに自動的に問い合わせる。これにより WINS クライアントと DNS クライアントは、名前解決を正しく実行することができ、管理上の負荷も軽減される。

Windows 2000 DNS サーバーは、WINS 前方参照だけでなく、WINS 逆引き参照も実行できる。

ページのトップへ ページのトップへ

DNS のトラブルシューティング

クライアントのトラブルシューティング

DNS に関してクライアント側で最もよくある問題は、TCP/IP 構成の誤りである。たとえば、DNS サーバーの値やデフォルトゲートウェイが間違っていると、クライアントは DNS サーバーに接続できない。そうすると、DNS 名を使用してほかのコンピュータにも接続できなくなる。

ネットワークの障害の診断での基本的なトラブルシューティング手順の 1 つは、問題の原因がクライアントにあるのかサーバーにあるのかを確認することである。この最も一般的な方法は、ほかのクライアントで同じ問題が発生するかどうかをテストすることである。サブネット全体で DNS 名前解決に問題があれば、サーバーかネットワークデバイスが利用できなくなっているか構成が間違っている可能性が高い。一方、一部のクライアントだけに問題が発生しているならば、クライアントの構成が間違っている可能性が高い。

IPCONFIG の使用

多くの場合、クライアント構成の間違いによってコンピュータが DNS 名前解決ができなくなっていることがある。この典型的な症状としては、クライアントが相手のコンピュータの IP アドレスを使ってアクセスできるが、DNS 名を使うとアクセスできない場合である。この問題を解決するには、クライアントの TCP/IP 構成が正しいかを確認することである。Windows NT 4.0、Windows 98、または Windows 2000 では、次のコマンドで簡単に確認することができる (Windows 95 では、WINIPCFG コマンドを使用する) 。

IPCONFIG /ALL |More

このコマンドは、クライアントのネットワークアダプタごとに TCP/IP 構成情報を一覧表示する。

NOTE Microsoft のオペレーティングシステムによって、IPCONFIG ユーティリティのパラメータと出力は異なる。正確なシンタックスを知るには、「IPCONFIG /?」と入力する。

クライアントコンピュータで DHCP を使用している場合、IPCONFIG /RELEASE コマンドで現在の TCP/IP 情報を解放できる。その後に、IPCONFIG /RENEW コマンドで新しい IP アドレスリースを DHCP サーバーから取得できる。

Windows 2000 の IPCONFIG では、ほかに新しいコマンドラインスイッチもサポートされている。これらのスイッチを表 2.4 に示す。

表 2.4 Windows 2000 IPCONFIG コマンドラインスイッチ

スイッチ

説明

/flush DNS

ローカル DNS キャッシュ内のエントリをすべて消去する。名前が不正な IP アドレスに解決されてしまう場合に役立つ。

/register DNS

現在の DHCP リースをすべて新しくし、DNS サーバー情報を更新する。

/display DNS

現在のローカル DNS リゾルバキャッシュの内容を表示する。

/showclassid

現在の DHCP クラス ID を表示する。異なる種類のコンピュータで特定の DHCP 情報が必要な場合に使用する (たとえば、サーバーとワークステーションでは異なるクラスが使用されるなど) 。

/setclassid

現在のDHCPクラスIDを変更可能にする。
PINGの使用

DNS クライアントの構成を検証したら、次にネットワーク上でサーバーがアクセス可能かどうかを確認する必要がある。PING コマンドを使うと、これを簡単に実行できる。

DNS の問題を解決するには、コンピュータの TCP/IP アドレスに対して PING を実行することから始める。たとえば、「PING 172.16.25.33」と入力して実行すると、サーバーからの応答が返るはずである。応答が返らない場合は、サーバーがダウンしているかルータ障害などのネットワーク接続の不備が考えられる。応答が返った場合は、コンピュータ名で PING を実行する。たとえば、「PING server1.mycompany.com」のように入力し実行する。これが失敗した (が、IP アドレスの PING は成功した) 場合、名前解決サービスに何らかの問題がある。

NSLOOKUP の使用

ネットワーク上のネームサーバーの情報を探すと有益な場合がある。NSLOOKUP コマンドは、この目的で開発された。基本テストでは、引数を指定せずにコマンドを実行する。これにより、クライアントの現在の DNS サーバーの IP アドレスが表示される。NSLOOKUP が適正に動作するためには、PTR レコードがサーバーのデータベースになければならない。

NOTE NSLOOKUP コマンドは、Windows NT 4.0 と Windows 2000 のコンピュータでだけ利用できる。Windows 95/98 コンピュータにはこのコマンドは用意されていない。

NSLOOKUP コマンドは、名前解決パスの確認や再帰テストのための多くの機能をサポートしている。詳細については、NSLOOKUP コマンドのプロンプトで「HELP」と入力する。

DNS サーバーのトラブルシューティング

DNS サーバーの一般的な問題は、正確な名前解決が実行できなくなることである。DNS サーバーがインストールされている場合、トラブルシューティングは次の手順で行う。

DNS サービスが開始されていることを確認する
[DNS] 管理ツールで、DNS サーバーの状態をすばやく確認できる。

イベントビューアを調べる
DNS サーバーに断続的に問題が発生する場合やサービスが予期せず停止する場合は、Windows NT イベントログの情報を調査する。

DNS サーバーがクライアントからアクセスできることを確認する
クライアントと DNS サーバー間のネットワーク接続を簡単に検証するだけで、多くの障害の原因を取り除くことができる。最も簡単な方法は、ネットワークのブラウジングやクライアントへの接続や PING コマンドの使用などである。ただし、名前解決が正しく行われていない場合もクライアントに接続できないことに注意する。

NSLOOKUP の動作を検証する
NSLOOKUP コマンドには、再帰や WINS 参照など Microsoft の DNS の機能をテストする強力なオプションがいくつか用意されている。

DNS 構成を検証する
DNS サーバーから不正な結果や古い結果が返される場合、サーバーの設定を手動で変更するかレコードを削除しなければならないことがある。古いレコードが問題の原因であった場合は、ユーザーは (LAN またはインターネット上の) ほかの多くのコンピュータにはアクセスできるが、特定のコンピュータにだけアクセスできないことがある。

さらに、Microsoft のものではない DNS を使用している場合は、製品に付属しているドキュメントを参照する。DNS はインターネット標準ではあるが、DNS サーバーソフトウェアアプリケーションの詳細は製品によって大きく異なる。

DNS サーバーの監視

パフォーマンスを監視すると、現在のサーバーの負荷やリソース使用を確認し、必要なアップグレードの計画を立てることができる。DNS サービスのインストール後は、Windows 2000 システムモニタで DNS オブジェクトを選択できるようになる。DNS オブジェクトには、DNS サーバーのパフォーマンスと使用状況を監視するためのさまざまなカウンタが用意されている。

システムモニタを使用すると、次のイベントに関する統計情報を生成できる。

  • AXFR 要求 (全ゾーン転送要求)

  • IXFR 要求 (増分ゾーン転送要求)

  • DNS サーバーメモリ使用

  • 動的更新

  • DNS 通知イベント

  • 再帰的クエリー

  • TCP と UDP の統計

  • WINS 統計

  • ゾーン転送関連

これらの情報は、システムモニタの折れ線グラフの表示、ヒストグラムの表示、およびレポートの表示で簡単に分析できる。さらに、パフォーマンス統計がしきい値を超えると自動的に通知する警告機能も使用できる。最後に、パフォーマンスログと警告からの情報は、ログデータファイルに保存できる。

ページのトップへ ページのトップへ

復習問題

  1. DNS の障害のトラブルシューティングを行うのに使用できるツールは次のどれか。

    1. IPCONFIG

    2. NSLOOKUP

    3. PING

    4. 上のすべて

  2. ほかと連続したネームスペースを共有しないドメイン名は次のどれか。

    1. sales.mycompany.com

    2. marketing.mycompany.com

    3. workstation1.organization.com

    4. workstation1.mycompany.com

    5. 上のすべては同一のネームスペースにある

  3. DNS の構成が間違っているかもしれないのは、次のどのコマンドが失敗したときか。

    1. PING 127.0.0.1

    2. PING localhost

    3. PING server1.mycompany.com

    4. 上のどれでもない

  4. TCP/IP 情報をクライアントに自動的に割り当てるのは次のどれか。

    1. WINS

    2. DNS

    3. DHCP

    4. RRAS

  5. セカンダリ DNS サーバーがマスタ DNS サーバーからの更新情報を要求したときに行われる情報の転送はどれか。

    1. ゾーン転送

    2. 転送

    3. 再帰

    4. 反復

  6. マスタ DNS サーバーが、 DNS データベースに変更が加えられたことをセカンダリ DNS サーバーに通知するのに使用される方法はどれか。

    1. ゾーン転送

    2. フォワーダの使用

    3. 再帰

    4. 反復

    5. DNS 通知

  7. クライアントが最終的に TCP/IP アドレスを解決する責任がある方法は次のどれか。

    1. 再帰

    2. 反復

    3. ゾーン転送

    4. 動的 DNS 更新

  8. 再帰の処理では最終的に TCP/IP アドレスを解決する責任があるのは次のどれか。

    1. DNS サーバー

    2. クライアント

    3. A と B の両方

  9. リソースレコードの正しい種類ではないものは次のどれか。

    1. SRV

    2. PTR

    3. A

    4. MX

    5. PDC

  10. DNS データベースの動的更新に責任を持つように設定できるクライアントは次のどれか。

    1. Windows 95

    2. Windows 98

    3. Windows NT 4.0

    4. Windows 2000

    5. 上のすべて

  11. どの DNS ゾーンの権限も持たずにパフォーマンス上の目的のみで使用される DNS サーバーは次のどれか。

    1. マスタ DNS サーバー

    2. キャッシュ専用 DNS サーバー

    3. プライマリ DNS サーバー

    4. セカンダリ DNS サーバー

  12. DNS ゾーンの一部の権限をほかの DNS サーバーに割り当てる処理は次のどれか。

    1. ゾーン転送

    2. フォワーダの使用

    3. 委任

    4. 昇格

  13. Active Directory がドメインコントローラを検索するのに使用するリソースレコードの種類は次のどれか。

    1. SRV

    2. PTR

    3. A

    4. MX

    5. 上のどれでもない

  14. DNS サーバーの監視に使用できるツールは次のどれか。

    1. [イベントビューア] 管理ツール

    2. システムモニタ

    3. [DNS] 管理ツール

    4. 上のすべて

  15. アドレス server1.asia.mycompany.com のうちホスト名部分はどれか。

    1. asia.mycompany.com

    2. .com

    3. server1

    4. server1.asia.mycompany

  16. 1 つ以上の DNS サーバーでのすべての再帰検索を特定の DNS サーバーで行う処理方法は次のどれか。

    1. 再帰

    2. 反復

    3. DNS 通知

    4. フォワーダの使用

  17. ドメインが DNS サーバーの権限の対象であることを示すリソースレコードの種類は次のどれか。

    1. SRV

    2. PTR

    3. SOA

    4. MX

  18. Windows 2000 以前のバージョンと下位互換性を保証するこ とを主な目的としている名前解決方法は次のどれか。

    1. DNS

    2. DHCP

    3. WINS

    4. IPX/SPX

  19. DNS サービスを実行する必要のあるサーバー構成の正確な説明は次のどれか。

    1. すべてのドメインコントローラ

    2. サブネットで少なくとも 1 つのWindows 2000 サーバー

    3. Active Directory サイトごとの 1 つのドメインコントローラ

    4. 上のどれでもない

  20. フォールトト レランスを提供する DNS サーバーは次のどれか。

    1. キャッシュ専用 DNS サーバー

    2. セカンダリ DNS サーバー

    3. プライマリ DNS サーバー

    4. マスタ DNS サーバー

ページのトップへ ページのトップへ

復習問題の解答

  1. D

    ここに挙げられたツールはどれも TCP/IP 接続と名前解決に関する障害の診断に役立つ。

  2. C

    ネームスペース organization.com は、ネームスペース mycompany.com の一部ではない。

  3. C

    DNS の設定が間違っていると、サーバーの名前解決が失敗する。選択肢 A では IP アドレス (DNS に依存しない) が使用されており、選択肢Bではローカルホストの特殊なエイリアスが使用されている。

  4. C

    DHCP では、クライアントに TCP/IP アドレス情報が自動的に割り当てられる。

  5. A

    ゾーン転送は、マスタ DNS サーバーとセカンダリ DNS サーバー間で情報が転送される処理である。

  6. E

    DNS 通知は、DNS マスタデータベースの変更を互換 DNS サーバーに通知する。変更が通知されると、セカンダリ DNS サーバーはゾーン転送を要求する。

  7. B

    反復では、DNS サーバーは現在保持しているドメイン名をもとに最適な応答を返す。ただし、最終的に名前を解決するための応答はクライアントが行う。

  8. A

    再帰では、最初に再帰的クエリーをクライアントから受け取ったサーバーがクライアントに答えを返せるまで、その DNS サーバーがほかの DNS サーバーにクエリーを出し続ける。

  9. E

    そのほかの選択肢はすべて標準 DNS リソースレコードである。

  10. D

    Windows 2000 を使用すれば、クライアントが DNS に動的更新を送信する責任をもつようにも設定できる。レガシシステムのクライアントは、DNS 更新機能がないので、更新は Windows 2000 の DHCP サーバで処理される。

  11. B

    そのほかのサーバーの種類はすべて、特定の DNS ゾーンに関する情報を持つ。

  12. C

    委任は、パフォーマンスや管理上の理由により、ゾーンをより小さな単位に分割するのに使用される。

  13. A

    SRV レコードは、特定のドメインのドメインコントローラを探すのに Active Directory とクライアントコンピュータによって使用される。

  14. D

    挙げられた選択肢はすべて、DNS サービスのパフォーマンスや動作状況に関する情報を表示するのに使用できる。

  15. C

    ホスト名は、常に DNS 名の最左端部分である。

  16. D

    フォワーダを使用すると、すべての再帰的 DNS 要求が特定の DNS サーバーを通じて転送される。低速リンクのネットワークトラフィックを減らすのにしばしば使用される。

  17. C

    SOA レコードは、そのサーバーが特定のドメインの権限を有していることを示す。

  18. C

    Windows 2000 での WINS のサポートは、主に下位互換性を保証することを目的としている。

  19. D

    Active Directory が適正に動作するには DNS が必要である。すべてのドメインコントローラで DNS が必要というわけではない。ドメインコントローラを探すのに DNS は不可欠だがW2Kサーバー以外で実行してもよい。

  20. B

    セカンダリ DNS サーバーはゾーンデータベースのコピーを保持し、プライマリ DNS サーバーが利用できなくなったときに名前解決を実行できるようにする。

ページのトップへ ページのトップへ