DNS インフラストラクチャの概要

このシナリオでは、Microsoft® Windows® 2000 ベースのドメイン ネーム システム (DNS) サーバーを導入した方法を紹介します。使用した DNS 設計では、Active Directory をサポートしていて、BIND (Berkeley Internet Name Domain) のさまざまなバージョンを組み入れ、内部の名前空間と外部の名前空間を含めています。

トピック

目的
設計のロジック
信頼性と可用性
Active Directory のサポート
フォレスト全体のロケータ リソース レコードの配布
異なる名前空間の名前解決
Active Directory の信頼関係のサポート
相互運用性
異なる DNS サフィックスと Active Directory ドメイン名の使用
その他の参考資料

目的

Reskit 社は、以下の目的を達成し、さまざまな面から総所有コストを減少させる構成で Windows 2000 ベースのドメイン ネーム システム (DNS) サーバーを導入しました。たとえば、BIND の古いバージョンに対する相互運用を可能にする構成や、企業のセキュリティを強化し、信頼性を向上させる構成を適用しました。

このシナリオの目的は以下のとおりです。

• Windows 2000 に付属するディレクトリ サービスである Active Directory・をサポートし、DNS を使用して Active Directory を利用します。ドメイン コントローラに DNS をインストールする場合、Active Directory 統合ゾーンを使用できます。Active Directory 統合ゾーンは、セキュリティで保護された動的更新によるセキュリティの向上と、マルチマスタ複製による信頼性の向上および管理作業の簡素化を実現します。

• ドメイン コントローラと DNS サーバーの可用性を保証することによって、信頼性の高いソリューションを提供します。

• BIND 4.9.3 ベースの DNS サーバーで DNS インフラストラクチャ内の一部の DNS 名を管理している場合に、Active Directory をサポートします。BIND 4.9.3 単独では、Active Directory をサポートできません。したがって、それを補うために Windows 2000 ベースの DNS サーバーを使用します。これによって、既存のソフトウェアへの投資を無駄にしなくても済みます。

• BIND 8.2.1 ベースの DNS サーバーで社内の一部の DNS 名を管理している場合に、Active Directory をサポートします。BIND 8.2.1 は、Active Directory をサポートできません。

• 社内のクライアントで、社内の名前空間内の名前、協力企業の名前空間内の名前、およびインターネットの名前を解決できるようにします。

次の「設計のロジック」では、このシナリオのインフラストラクチャで上記の目的をどのようにして達成したか説明します。

設計のロジック

このシナリオでは、Resource Kit Corporation および Supplier (仕入先企業) によって作成された DNS 名前空間を紹介します。つまり、Supplier の名前空間と、Resource Kit Corporation の Reskit 部門、Avionics 部門、および Acquired 部門の名前空間を示すことになります。また、現実の設定を想定したインターネット環境を構築します。さらに、このシナリオにおける設計面での決定事項について説明します。

注意
一般的に "名前空間" という用語は、外部インターネットの名前空間または企業内のプライベートな名前空間のいずれかを意味します。このシナリオでは、"名前空間" を企業部門の名前空間の意味としても使用しています。

このシナリオでは、DNS インフラストラクチャを確立する際に、以下の要因に関する設計面の決定を行いました。

• 信頼性と可用性

• Active Directory のサポート

• フォレスト全体のロケータ リソース レコードの配布

• 異なる名前空間の名前解決

• Active Directory の信頼関係のサポート

• 相互運用性

• 異なる DNS サフィックスと Active Directory ドメイン名の使用

信頼性と可用性

導入実験シナリオのネットワーク図では、各ゾーンで管理を担当する DNS サーバーを少なくとも 2 台示しました。最善の慣行に従ってフォールト トレランス性と負荷分散性を向上させるために、1 つのゾーン当たり少なくとも 2 台の DNS サーバーに管理を担当させる必要があります。シングル ポイント障害を回避するために、冗長なネーム サーバーをできる限り広範に分散します。LAN 環境では、各ネーム サーバーを個別のサブネットに配置します。WAN 環境の場合は、各ネーム サーバーを異なるネットワークに配置します。各ネットワークで少なくとも 1 台のネーム サーバーを直接利用できるような配置が望ましいでしょう。これによって、ルーターでシングル ポイント障害が発生する恐れがなくなります。

導入実験シナリオのネットワーク図では、1 つのドメイン当たり少なくとも 2 台のドメイン コントローラを示しました。最善の慣行に従う場合、1 つのドメイン当たり少なくとも 2 台のドメイン コントローラを使用する必要があります。これによって、1 台のドメイン コントローラが利用不可能になっても、コンピュータは引き続きドメインに関する情報のアクセスおよび更新を行うことができます。多数のユーザーが存在する場合は、さらにフォールト トレランス性および負荷分散性を高めるために、3 台以上のドメイン コントローラを使用した方がよい場合もあります。このシナリオでは多数のユーザーを想定しているので、複数のドメイン コントローラを使用します。

必要なドメイン コントローラの台数を決定する方法について詳しくは、『Microsoft Windows 2000 Server リソースキット 1 導入ガイド』の「第 9 章 Active Directory 構造の設計」を参照してください。また、Active Directory Sizer を使用すれば、組織のプロファイル、ドメイン情報、およびサイト トポロジに基づいて必要なドメイン コントローラの台数を推定できます。Active Directory Sizer をダウンロードするには、『Adsizer.exe: Active Directory Sizer』 にアクセスしてください。

最善の慣行に従えば、稼動中の DNS サーバーに常に接続できるように、各コンピュータで少なくとも 2 台の DNS サーバーを使用する構成が必要です。この構成では、コンピュータと同じサイトの DNS サーバーを最初に指定するようにします。

たとえば、このシナリオでは以下の DNS サーバーを使用するようにクライアント W2P.noam.reskit.com を構成しました。

• SEA-NA-DC-01.noam.reskit.com。クライアントと同じサイトにあるので、このサーバーを選択します。

• SEA-NA-DC-02.noam.reskit.com。クライアントと同じサイトにあるので、このサーバーを選択します。

• SEA-RK-DC-01.reskit.com。SEA-NA-DC-01.noam.reskit.com および SEA-NA-DC-02.noam.reskit.com が使用不能になった場合に備えて、このサーバーを選択します。このような場合でも SEA-RK-DC-01.reskit.com は、ドメイン内のゾーン noam.reskit.com 以外のゾーンに関する情報を引き続き検索できます。

  注意
  DNS サーバーのインストールされたコンピュータを構成していて、そのコンピュータをフォレスト ルート ドメインの代替ドメイン コントローラに昇格させる場合、コンピュータの優先 DNS サーバーまたは代替 DNS サーバーにローカル DNS サーバーを指定しないでください。フォレスト ルート ドメイン内のすべてのドメイン コントローラが自身を優先 DNS サーバーまたは代替 DNS サーバーに指定している場合、そのドメイン コントローラで自身のグローバル一意識別子 (GUID) を含む CNAME リソース レコードを複製できません。

Active Directory のサポート

Active Directory をサポートするには DNS が必要です。Active Directory ドメインの名前として、DNS 名が使用されます。また Active Directory では、DNS を使用して位置を決定します。これによって、各コンピュータでドメイン コントローラの位置の特定が可能になります。したがってこのシナリオでは、Active Directory のドメイン構造を考慮しながら、DNS 構造を設計しました。図 1 は、Active Directory のドメイン構造を示しています。

図 1: 図 1: Active Directory

各 Active Directory ドメインには、同じ名前を持った DNS ゾーンがあります。Active Directory 統合ゾーンを使用すれば、フォールト トレランス性と安全性が向上します。Active Directory ドメイン内で、すべての Active Directory 統合ゾーンがすべてのドメイン コントローラ間で複製されます。このようなドメイン コントローラ上で動作するすべての DNS サーバーが、ゾーンのプライマリ サーバーとして機能し、動的更新を受け取ることができます。

図 2 は、Active Directory ドメイン構造に対応する DNS ゾーンを示しています。この図では、内部のゾーンのみを表示しています。外部のゾーン reskit01-ext.com、avionics01-ext.com、acquired01-ext.com、および supplier01-int.com は含まれていません。

図 2: Active Directory のドメイン名に対応するゾーン

Active Directory ドメイン構造を構築する前に、既に DNS インフラストラクチャが存在していました。したがって DNS インフラストラクチャには、図 2 で示したゾーン以外にも多くのゾーンが含まれています。Resource Kit Corporation および Supplier では、以下の 4 つの名前空間を導入しています。

• 外部名前空間。擬似的なインターネットと、インターネット上で可視の DNS ゾーンが含まれます。

• Resource Kit Corporation の Acquired 部門の内部名前空間。Active Directory フォレスト acquired01-int.com をサポートします。

• Resource Kit Corporation の Reskit 部門の内部名前空間。Active Directory フォレスト reskit.com (ドメイン reskit.com、noam.reskit.com、eu.reskit.com、avionics01-int.com、および seville.avionics01-int.com を含みます) をサポートします。

• Supplier の内部名前空間。Active Directory フォレスト partner.suppplier01-int.com をサポートします。

フォレスト全体のロケータ リソース レコードの配布

フォレスト内の各ドメイン コントローラでは、2 セットのロケータ リソース レコードを登録します。第 1 のセットはドメイン固有のレコードであり、末尾に ドメイン名 (たとえばreskit.com) が付きます。第 2 のセットはフォレスト全体のレコードであり、末尾に_msdcs.フォレスト名 (たとえば _msdcs.reskit.com) が付きます 。フォレスト全体で一般的に使用されるロケータ リソース レコードはすべて、サブドメイン _msdcs.フォレスト名に置かれます。

フォレスト全体のロケータ リソース レコードは、フォレスト内のあらゆる部分のクライアントおよびドメイン コントローラによって使用されます。たとえば、グローバル カタログ ロケータ レコードや、複製パートナーを特定する目的で複製システムによって使用されるレコードは、フォレスト全体のレコードです。

クライアントで同じサイト内のグローバル カタログ サーバーを特定するには、グローバル カタログに対応するフォレスト全体のロケータ リソース レコードを探索できることが必要です。同様に、任意の 2 台のドメイン コントローラ間で (同じドメイン内の 2 台のドメイン コントローラの場合であっても)、相互に複製処理を実行するには、そのドメイン コントローラでフォレスト全体のロケータ レコードを探索できなければなりません。このためにほとんどの場合で、すべてのサイト内のすべての DNS サーバーからフォレスト全体のロケータ レコードを利用できるようにしておくことが最善の慣行になります。

一般的に言えば、各サイトで 1 台の DNS サーバーにゾーン _msdcs.フォレスト名 を複製するだけでは十分ではありません。DNS サーバーがゾーン _msdcs.フォレスト名 のローカル コピーを持たない場合、そのゾーン内の名前を調べるために再帰的な DNS 探索処理を使用する必要があります。DNS サーバーで再帰的な探索を実行する場合、名前空間のルートを管理する DNS サーバー (DNS ルート サーバー) に照会して下位方向に対象のレコードが見つかるまで DNS 委任処理を進めます。サイト内に DNS ルート サーバーが存在せず、ほかのサイトへの接続がダウンしている場合、DNS サーバーで再帰的な探索処理を実行できません。したがって、同じサイト内のすべての DNS サーバーが _msdcs.フォレスト名 の管理を担当していない限り、_msdcs.フォレスト名 を管理する DNS サーバーを検索できない恐れがあります。

Active Directory ドメイン内のすべてのサイト内のすべての DNS サーバーでフォレスト全体のロケータ レコードを利用できるように、Active Directory 統合ゾーン _msdcs.reskit.com をゾーン reskit.com から委任して SEA-RK-DC-01.reskit.com 上でホストし 、フォレスト内の大半の DNS サーバー上にゾーン _msdcs.reskit.com のセカンダリ コピーを作成します。ゾーン _msdcs.reskit.com のセカンダリ コピーを以下のサーバーに追加します。

• VAN-NA-DC-01.noam.reskit.com

• VAN-NA-DC-02.noam.reskit.com

• BOS-NA-DC-01.noam.reskit.com

• BOS-NA-DC-02.noam.reskit.com

• MIL-EU-DNS-01.eu.reskit.com

• MIL-EU-DNS-02.eu.reskit.com

• SEA-AV-DC-01.avionics01-int.com

• SEA-AV-DC-02.avionics01-int.com

• SEV-SV-DC-01.seville.avionics01-int.com

• SEV-SV-DC-02.seville.avionics01-int.com

以下のサーバーにはゾーン _msdcs.reskit.com のセカンダリ コピーを追加しません。

1. SEA-RK-DC-02.reskit.com。SEA-RK-DC-01.reskit.com と同じドメインにあるので、ゾーン Active Directory 統合ゾーンのコピーをホストしています。

2. SEA-NA-DC-01.noam.reskit.com および SEA-NA-DC-02.noam.reskit.com。同じサイト内のほかの DNS サーバーにゾーンについて照会できます。SEA-RK-DC-01.reskit.com および SEA-RK-DC-02.reskit.com に対する照会が可能です。

3. BIND 4.9.3 ベースの DNS サーバー SEA-AV-DNS-01.avionics01-int.com。このサーバーではサービス (SRV) リソース レコードをサポートできません。SRV リソース レコードであるフォレスト全体のロケータ レコードも存在します。

4. Windows NT 4.0 ベースのドメイン Atlanta 内の Microsoft® Windows NT® Version 4.0 ベースの DNS サーバー。このドメイン内のサーバーでは、Active Directory 内のドメイン コントローラを特定する必要がありません。

図 3 に、ゾーン _msdcs.reskit.com と管理を担当するサーバーの論理的な図を示します。

図 3: _msdcs.reskit.com ゾーンの配布先の論理的な図

図 4 に、ゾーン _msdcs.reskit.com と管理を担当するサーバーの物理的な図を示します。

図 4: _msdcs.reskit.com ゾーンの名前の配布先と管理を担当するサーバーの物理的な図

負荷分散性を高めるために、すべての管理サーバーの NS レコードをゾーン _msdcs.reskit.com に追加できます。しかし、すべてのサーバーのネーム サーバー (NS) レコードを追加すると、WAN リンクを経由するトラフィックが増大します。WAN トラフィックを最小限に抑えながら、任意のクライアントのためにゾーンの名前に対するクエリを引き続き解決できるようにするには、2 台のサーバー SEA-RK-DC-01.reskit.com および SEA-RK-DC-02.reskit.com の NS レコードのみを追加します。この 2 台のサーバーは、任意のサイト内のクライアントのために、ゾーン _msdcs.reskit.com 内の名前に対するクエリを以下のように正しく解決できます。

• クライアントから _msdcs.reskit.com ゾーンの管理を担当する優先サーバーまたは代替サーバーが照会されると、照会されたサーバーはローカル データを使用してそのクエリを解決します。照会されたサーバーは、この 2 台のサーバーが NS リソース レコードの一覧に含まれるかどうかにかかわらず、クエリを解決できます。

• クライアントから _msdcs.reskit.com ゾーンを管理しない (上記の 2 台のサーバーとは異なるサイト内にある) 優先サーバーまたは代替サーバーが照会された場合、照会されたサーバーは再帰的な探索処理を使用して上記の 2 台のサーバーに問い合わせることでクエリを解決します。

最善の慣行に従えば、ゾーン転送を制限し、ゾーンのセカンダリ コピーをホストするサーバーにのみゾーン転送の要求を許容する必要があります。これによって、ネットワーク内で未承認のゾーン転送が実行される危険性を回避できます。

フォレスト全体のロケータ リソース レコードの配布について詳しくは、『Microsoft Windows 2000 Server リソースキット 1 導入ガイド』の「第 9 章 Active Directory 構造の設計」の「9.3 フォレスト計画の作成」を参照してください。

異なる名前空間の名前解決

組織をインターネットから見えるようにするには、組織で "外部名前空間" (インターネット上の任意のユーザーからアクセスできる公開された名前空間) を持つことが必要です。また、インターネットの名前管理機関によって組織に DNS ドメインが割り当てられていて、DNS ドメインの管理を担当する DNS サーバーに対する委任が親 DNS ゾーンに含まれていることを確認する必要があります。しかし多くの組織では、ネットワークへの悪意のあるアクセスを阻止するために、"内部名前空間" を用意しています。内部名前空間は、組織内のユーザーだけが見ることのできるプライベートな名前空間であり、これによって未承認のユーザーがネットワーク内のコンピュータの名前と IP アドレスを把握することができなくなります。

組織で内部名前空間と外部名前空間の両方を持つことを計画している場合、管理者は内部のクライアントで両方の名前空間の名前を解決できるように DNS サーバーを構成する必要があります。

このシナリオのインフラストラクチャには、外部名前空間と内部名前空間の両方が含まれています。このシナリオで使用しているのは、サンプルのインターネット名前空間と、Supplier の内部名前空間および外部名前空間、そして Resource Kit Corporation の Acquired、Avionics、および Reskit の各部門の内部名前空間と外部名前空間です。以降の節では、内部名前空間について簡単に説明します。

Reskit 部門の内部名前空間
Reskit 部門の内部名前空間では、すべてのクライアントでプロキシ サーバーを使用するように構成します。このプロキシ サーバーは、Microsoft Internet Security and Acceleration (ISA) Server を実行するサーバーであり、境界ネットワーク内の公開で使用可能なインターネット サーバーと企業内のネットワーク間で、保護されたファイアウォールとして機能します。この構成では、内部名前空間でプライベート ルートを持つことが可能です。DNS サーバー SEA-RK-DC-01.reskit.com および SEA-RK-DC-02.reskit.com は、内部名前空間のルート ゾーンの Active Directory 統合コピーを持ちます。DNS サーバー SEA-AV-DNS-01.avionics01-int.com および SEA-AV-DNS-02.avionics01-int.com は、同じルート ゾーンのセカンダリ コピーを持ちます。内部名前空間内のその他のすべての DNS サーバーでは、そのルート サーバー リストとして SEA-RK-DC-01.reskit.com、SEA-RK-DC-02.reskit.com、SEA-AV-DNS-01.avionics01-int.com、および SEA-AV-DNS-02.avionics01-int.com を指定しています。

ルート サーバーとして構成されたサーバーは、クエリをほかのサーバーに転送できません。しかし、Reskit 部門の内部名前空間内のクライアントは、自身の部門の内部名前空間内の DNS 名の解決に加えて、Acquired 部門および Supplier の内部名前空間内のコンピュータ名を探索できることが必要です。このために、Reskit 部門の内部名前空間のルート ゾーンから、ゾーン acquired01-int.com および supplier01-int.com をこれらのゾーンの管理を担当するサーバーに委任します。

クライアントはまた、インターネット名前空間内のコンピュータの名前を探索できることが必要です。SEA-RK-DC-01.reskit.com はルート サーバーであるので、SEA-RK-DC-01.reskit.com からインターネットにクエリを転送することはできません。したがって、各クライアントで名前の除外一覧を構成する必要があります。クライアントは、この除外一覧を使用して、内部ネットワーク宛て、またはインターネット宛てのいずれのクエリであるか判断します。その後クライアントが、ISA サーバーの動作するサーバー SEA-RKE-ISA-01.reskit01-ext.com にインターネット クエリを転送し、この SA サーバーの動作するサーバーがインターネット上のサーバー SEA-RKE-DC-01.reskit01-ext.com へさらにクエリを転送します。

図 5 は、クライアントから各種類のクエリがどのように転送されるかを示しています。

図 5: Reskit 名前空間内のクエリ

Supplier の内部名前空間
Supplier の名前空間では、すべてのクライアントでプロキシ サーバーを使用するように構成します。このプロキシ サーバーは、ISA Server を実行するサーバーであり、境界ネットワーク内の公開で使用可能なインターネット サーバーと企業内のネットワーク間で、保護されたファイアウォールとして機能します。この構成では、内部名前空間でプライベート ルートを持つことが可能です。DNS サーバー SJC-SP-DNS-01.supplier01-int.com および SJC-SP-DNS-02.supplier01-int.com は、名前空間のルート ゾーンの Active Directory 統合コピーを持ちます。すべてのクライアントで、その名前空間内の位置にかかわらず、この 2 台のサーバーをルート サーバーとして構成します。

プライベート ルートとして構成されたサーバーは、クエリをほかのサーバーに転送できません。しかし、Supplier の内部名前空間内のクライアントは、自身の部門の内部名前空間内の DNS 名の解決に加えて、Resource Kit Corporation の Acquired 部門および Reskit 部門の内部名前空間内のコンピュータ名を探索できることが必要です。このために、内部名前空間のルート ゾーンから、ゾーン reskit.com および acquired01-int.com をこれらのゾーンの管理を担当するサーバーに委任します。ゾーン reskit.com の管理を担当するサーバーは、SEA-RK-DC-01.reskit.com および SEA-RK-DC-01.reskit.com です。ゾーン acquired01-int.com の管理を担当するサーバーは、HKG-AC-DC-01.acquired01-int.com、HKG-AC-DC-02.acquired01-int.com、TOY-AC-DC-01.acquired01-int.com、および TOY-AC-DC-02.acquired01-int.com です。

クライアントはまた、インターネット名前空間内のコンピュータの名前を探索できることが必要です。supplier01-int.com にはプライベート ルート ゾーンが存在するので、SJC-SP-DC-01.supplier01-int.com からインターネットにクエリを転送することはできません。したがって各クライアントで、ISA Server の動作するサーバー SJC-SPE-ISA-01.supplier01-ext.com にインターネット クエリを転送するように構成します。さらにこの ISA サーバーの動作するサーバーでは、クエリがインターネット上のサーバー SJC-SPE-DC-01.supplier01-ext.com に転送されます。

図 6 は、クライアントから各種類のクエリがどのように転送されるかを示しています。

図 6: Supplier 名前空間内のクエリ

Acquired 部門の内部名前空間
Acquired 部門の名前空間内のクライアントでは、プロキシ サーバーを使用するように構成しません。したがって、名前空間内にプライベート ルートを持つことができません。このため、DNS サーバー HKG-AC-DC-01.acquired01-int.com はクエリをインターネットに転送する必要があります。

Acquired 部門の名前空間内のクライアントは、自身の部門の内部名前空間内の DNS 名の解決に加えて、Supplier の内部名前空間、および Resource Kit Corporation の Reskit 部門および Avionics 部門の内部名前空間内のコンピュータ名を探索できることが必要です。また Resource Kit Corporation および Supplier の内部名前空間はインターネットから見えないので、Acquired 部門の名前空間内のクライアントがクエリを直接インターネットに転送することはできません。したがって、サーバー HKG-AC-DC-01.acquired01-int.com、HKG-AC-DC-02.acquired01-int.com、TOY-AC-DC-01.acquired01-int.com、および TOY-AC-DC-02.acquired01-int.com はすべて、ゾーン reskit.com、avionics01-int.com、および supplier01-int.com のセカンダリ コピーを持ちます。

注意
Acquired 部門の内部名前空間内のすべての DNS サーバーで ゾーン reskit.com、avionics01-int.com、および supplier01-int.com のセカンダリ コピーをホストする必要はありません。ゾーン acquired01-int.com を管理するサーバーにクエリを転送する名前空間内のどの DNS サーバーでも、ゾーン reskit.com、avionics01-int.com、および supplier01-int.com のセカンダリ コピーをホストする必要はありません。

クライアントはまた、インターネット名前空間内のコンピュータの名前を探索できることが必要です。インターネット上の DNS サーバー SEA-RKE-DC-01.reskit01-ext.com にクエリを転送するようにサーバー HKG-AC-DC-01.acquired01-int.com、HKG-AC-DC-02.acquired01-int.com、TOY-AC-DC-01.acquired01-int.com、および TOY-AC-DC-02.acquired01-int.com を構成します。

図 7 は、クライアントから各種類のクエリがどのように転送されるかを示しています。

図 7: Acquired 部門の名前空間内のクエリ

内部名前空間と外部名前空間を設計する場合に考慮すべき問題について詳しくは、『Microsoft Windows 2000 Server リソースキット 6 TCP/IPガイド』の「第 6 章 Windows 2000 DNS」の「6.10 インターネットアクセスの注意点 」 (英語) を参照してください。

Active Directory の信頼関係のサポート

このシナリオでは、3 つの別個のフォレスト acquired01-int.com、reskit.com、および supplier01-int.com 内で相互に通信することの必要なコンピュータが存在します。フォレスト reskit.com 内の Active Directory ドメインは、ドメイン acquired01-int.com に対して外部信頼関係を持ちます。その他のドメイン コントローラに対して信頼関係を設定するには、信頼の設定元のドメイン コントローラで信頼を設定する対象になるドメイン内のドメイン コントローラに照会できることが必要です。ドメイン コントローラは、自身をアドバタイズするために、1 つ以上の DNS ゾーンでドメイン コントローラ ロケータ リソース レコードを登録します。したがって、信頼の設定元のドメイン コントローラは、適切な DNS ゾーンに対して照会できることが必要です。

たとえば、Resource Kit Corporation の内部名前空間にはプライベート ルートが存在します。ドメイン コントローラ SEA-RK-DC-01.reskit.com でドメイン コントローラ HKG-AC-DC-01.acquired01-int.com に対する信頼を確立するために、Resource Kit Corporation の内部名前空間のルート ゾーンにゾーン acquired01-int.com の委任を追加します。

ドメイン コントローラ SEA-RK-DC-01.reskit01-int.com で Active Directory ドメイン acquired01-int.com のドメイン コントローラに対して信頼を確立する必要がある場合、優先 DNS サーバーに照会します (図 8 を参照)。この例の優先 DNS サーバーは、同一コンピュータ上の DNS サーバー サービスです。その後、優先 DNS サーバーは、acquired01-int.com を管理するサーバーの名前と IP アドレスのリストを含む委任から HKG-AC-DC-01.acquired01-int.com を特定し、DNS サーバー HKG-AC-DC-01.acquired01-int.com を照会して適切なドメイン コントローラ ロケータ リソース レコードを見つけます。

図 8: acquired01-int.com 内のドメイン コントローラ ロケータ リソース レコードに対するクエリ

ルート ヒント内のリストに、SEA-RK-DC-01.reskit01-int.com を含む DNS サーバーであれば名前空間内のどの DNS サーバーでも、通常の DNS 解決処理によってゾーン acquired01-int.com に対する委任を特定できます。したがって、ドメイン内のその他のドメイン コントローラでも信頼を確立することができます。

名前空間にプライベート ルートがない場合、いくつかの DNS サーバーにロケータ リソース レコードを含むゾーンのセカンダリ コピーが存在することが必要です。たとえば、名前空間 acquired01-int.com にはプライベート ルートが存在しません。コンピュータ HKG-AC-DC-01.acquired01-int.com で SEA-RK-DC-01.reskit01-int.com を特定するために、DNS サーバー HKG-AC-DC-01.acquired01-int.com にゾーン reskit.com のセカンダリ コピーを追加します。HKG-AC-DC-01.acquired01-int.com で信頼関係を確立する必要がある場合、その DNS サーバーを照会して適切なドメイン コントローラ ロケータ リソース レコードを特定します (図 9 を参照)。この例の優先 DNS サーバーは、同一コンピュータ上に存在します。

Acquired 部門の内部名前空間内で HKG-AC-DC-01.acquired01-int.com にクエリを転送するどの DNS サーバーも、Reskit 部門の内部名前空間内の名前を照会できます。したがって、ドメイン内のその他のドメイン コントローラでも信頼関係を確立できます。

図 9: reskit.com 内のドメイン コントローラ ロケータ リソース レコードに対するクエリ

相互運用性

Resource Kit Corporation において Windows 2000 ベースの DNS サーバーおよびドメイン コントローラの導入時に、既存のネットワークに既に 1 台の Windows NT 4.0 ベースの DNS サーバー、1 台の BIND 8.2.1 ベースの DNS サーバー、および 2 台の BIND 4.9.3 ベースの DNS サーバーが存在していました。このシナリオでは、各バージョンの DNS を組み入れることができる DNS インフラストラクチャを設計しました。

Windows NT 4.0 ベースの DNS サーバー
Resource Kit Corporation では Active Directory の導入時に、1 つのドメインを Windows NT 4.0 ドメインとして残しておきました。Windows NT 4.0 ベースのサーバー ATL-AT-PDC-01.atlanta.noam.reskit.com は、ゾーン atlanta.noam.reskit.com を管理する DNS サーバーです。親ゾーン noam.reskit.com を管理する DNS サーバーはすべて、Windows 2000 を実行しています。この構成では相互運用性について考慮すべき問題は存在しません。

BIND 8.2.1 ベースの DNS サーバー
Resource Kit Corporation で Active Directory を導入する前は、BIND 8.2.1 ベースの DNS サーバー MIL-EU-DNS-01.eu.reskit.com および MIL-EU-DNS-02.eu.reskit.com がゾーン eu.reskit.com をホストしていました。管理者は、これらのサーバーを Windows 2000 ベースの DNS サーバーに置き換えないことにしました。BIND 8.2.1 では、動的更新と、サービス (SRV) リソース レコードがサポートされるため、BIND 8.2.1 を使用して Active Directory をサポートできます。ただし、IETF インターネット ドラフト "GSS Algorithm for TSIG (GSS-TSIG)" に定義された、セキュリティで保護された動的更新はサポートされません。このため管理者は、セキュリティで保護された動的更新に備えたゾーンの構成を適用できません。

BIND 8.2.1 では、古い RFC 952 に従って、既定の設定で下線文字 (_) を含むホスト名が禁止されます。しかし、このシナリオのドメイン コントローラ ロケータ ゾーンには、下線文字を使用するホスト リソース レコードが含まれます。したがって、BIND 設定ファイル内で名前チェック機能を無効にしました。

この構成で、BIND 8.2.1 ベースの DNS サーバー MIL-EU-DNS-01.eu.reskit.com および MIL-EU-DNS-02.eu.reskit.com は、Active Directory ドメイン eu.reskit.com と同じ名前を持つ DNS ゾーンをホストします (図 10 を参照)。Windows 2000 ベースのドメイン コントローラ MIL-EU-DC-01.eu.reskit.com および MIL-EU-DC-02.eu.reskit.com には、DNS がインストールされていません。その代わりにこれらのドメイン コントローラは、自身のドメイン コントローラ ロケータ リソース レコードを、BIND サーバーによってホストされたゾーンに登録しています。

図 10: BIND 8.2.1 の構成

BIND 4.9.3 ベースの DNS サーバー
Reskit 部門で Active Directory を導入する前は、BIND 4.9.3 ベースの DNS サーバー SEA-AV-DNS-01.avionics01-int.com および SEA-AV-DNS-02.avionics01-int.com がゾーン avionics01-int.com を管理していました。

同様に、Supplier で Active Directory を導入する前は、BIND 4.9.3 ベースの DNS サーバー SJC-SP-DNS-01.supplier01-int.com および SJC-SP-DNS-02.supplier01-int.com がゾーン supplier01-int.com を管理していました。

両方の企業で、BIND 4.9.3 ベースの DNS サーバーの機能を維持しながら、Active Directory を導入する必要がありました。BIND 4.9.3 ベースの DNS サーバーでは動的更新とサービス (SRV) リソース レコードがサポートされないため、BIND 4.9.3 ベースの DNS サーバーを使用して Active Directory をサポートできません。

Resource Kit Corporation では "名前のオーバーラップ" を使用する必要がありました。つまり、既存の DNS ゾーンについて、Active Directory ドメインと同じ名前を使用することが必要でした。管理者が Windows 2000 の導入準備を進めるために avionics01-int.com ゾーンに追加した委任のリストでは、Windows 2000 ベースの DNS サーバー SEA-AV-DC-01.avionics01-int.com を以下のゾーンを管理するサーバーとして指定しています。

• _msdcs.avionics01-int.com

• _sites.avionics01-int.com

• _tcp.avionics01-int.com

• _udp.avionics01-int.com

これらのゾーンには、ドメイン コントローラ ロケータ リソース レコード (Active Directory をサポートするために必要です) が使用されています。

図 11 に、この構成を示します。

図 11: 名前をオーバーラップさせた BIND 4.9.3 の構成

この構成について詳しくは、シナリオ『名前のオーバーラップによる、既存の DNS インフラストラクチャへの Active Directory 名前空間の統合』を参照してください。

Supplier では、既存の DNS ゾーンにオーバーラップする Active Directory 名を使用することは避けたいと考えています。管理者は、Windows 2000 の導入準備を進めるために、BIND 4.9.3 ベースの DNS サーバー上で、既存の DNS ゾーン supplier01-int.com からの委任を作成します。この委任のリストには、新しいゾーン partner.supplier01-int.com を管理する DNS サーバーとして Windows 2000 ベースの DNS サーバーを含めます。次に管理者は、Active Directory ドメイン partner.supplier01-int.com を作成します。ゾーン partner.supplier01-int.com は Active Directory 統合ゾーンであり、SRV リソース レコードと、ドメイン コントローラの位置の決定に必要なその他のリソース レコードを含んでいます。

図 12 に、この構成を示します。

図 12: 名前をオーバーラップさせない BIND 4.9.3 の構成

この構成について詳しくは、シナリオ『名前のオーバーラップによらない、既存の DNS インフラストラクチャへの Active Directory 名前空間の統合』を参照してください。

この節でこれまで取り上げてきたトピックについて詳しくは、『Microsoft Windows 2000 Server リソースキット 6 TCP/IPガイド』の「第 6 章 Windows 2000 DNS」の「6.9 ほかの DNS サーバーとの相互運用性 」 (英語) を参照してください。

異なる DNS サフィックスと Active Directory ドメイン名の使用

ドメイン noam.reskit.com の Boston サイト内の管理者は、既定で割り当てられる名前とは異なる認識名を各コンピュータで使用したいと考えています。したがって管理者は、これらのコンピュータが Active Directory ドメイン Noam.reskit.com に参加している場合でも、boston.noam.reskit.com 用に個別のゾーンを作成します。そして、ドメイン内の大半のコンピュータでプライマリ DNS サフィックス boston.noam.reskit.com を構成します。

あるグループ内のコンピュータのサフィックスを変更するには、まずグループ内のコンピュータに目的のサフィックスを割り当てることができるようにアクセス許可を変更します。次に、グループ ポリシー オブジェクトを適用する必要があります。

注意
このようなアクセス許可の変更を行った場合、サービス妨害攻撃 (DoS: denial of service attack) に対してコンピュータが脆弱になります。ここで求められるアクセス許可の変更によって、ドメインのメンバであるコンピュータで、自身のコンピュータ アカウント内の DNSHostName 属性 (したがってサービス プリンシパル名属性) に任意の値を設定できるようになります。悪意のあるユーザーが、あるコンピュータ アカウントの DNSHostName 属性を変更し、別のコンピュータ アカウントの DNSHostName 属性と同じになるように仕掛けた場合、両方のコンピュータの Kerberos 認証が失敗します。Kerberos 認証が失敗すると、この 2 台のコンピュータのリソースに対してユーザーとコンピュータがアクセスできなくなります。この問題は、ドメイン コントローラを含むあらゆる種類のコンピュータに影響します。最悪の場合、悪意のあるユーザーがサービス妨害攻撃を仕掛けることで、ドメイン コントローラによるユーザーとコンピュータの認証を不可能にすることもできます。

その他の参考資料

Windows 2000 リソース キット
DNS について詳しくは、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第5章 DNS入門」および「第 6 章 Windows 2000 DNS 」 (英語) を参照してください。

Active Directory の詳細については、『Microsoft Windows 2000 Server リソースキット 3 分散システムガイド 上』の「第 1 章 Active Directoryの論理構造」と『Microsoft Windows 2000 Server リソースキット 1 導入ガイド』の「第 9 章 Active Directory構造の設計」を参照してください。

Windows 2000 Server オンライン ドキュメント

• DNS について詳しくは、Windows 2000 Server ヘルプの「ネットワーク」の「DNS」 を参照してください。

• Active Directory について詳しくは、Windows 2000 Server ヘルプの「Active Directory」を参照してください。

ツール

• Active Directory Sizer

  Active Directory Sizer を使用すると、Active Directory を導入するために必要なハードウェアを、その組織のプロファイル、ドメイン情報、およびサイト トポロジに基づいて見積もることができます。Active Directory Sizer にユーザーが値を入力すると、その値と内部の計算方式に基づいて、次の数の見積もりが求められます。

  • 各サイトの各ドメインごとのドメイン コントローラ

  • 各サイトの各ドメインごとのグローバル カタログ サーバー

  • コンピュータごとの CPU と CPU の種類

  • Active Directory のデータ記憶域として必要なディスク

  さらに Active Directory Sizer では、次の値のおよその見積もりも求められます。

  • 必要なメモリの容量

  • ネットワーク帯域幅の使用状況

  • ドメイン データベースのサイズ

  • グローバル カタログ データベースのサイズ

  • サイト間の複製に必要な帯域幅

• Netdiag

  Netdiag は、ネットワーク クライアントの状態を確認し、それが機能しているかどうかを特定する一連のテストを実行することによって、ネットワーク機能の問題と接続の問題を分離できるユーティリティです。Netdiag について詳しくは、Windows 2000 Support Tools のヘルプを参照してください。Windows 2000 Support Tools および Support Tools ヘルプをインストールし、使用する方法については、Windows 2000 オペレーティング システム CD-ROM の \Support\Tools フォルダ内のファイル Sreadme.doc (英語) を参照してください。

  コマンド プロンプトから DNS 構成を実行するには、Dnscmd.exe ツールを使用します。

• Dnscmd.exe

  コマンドライン ツール Dnscmd.exe を使用すれば、DNS サーバーを構成できます。Dnscmd.exe について詳しくは、Windows 2000 Support Tools のヘルプを参照してください。Windows 2000 Support Tools および Support Tools ヘルプをインストール、使用する方法については、Windows 2000 オペレーティング システム CD-ROM の \Support\Tools フォルダ内のファイル Sreadme.doc (英語) を参照してください。

ホワイト ペーパー
DNS について詳しくは、『Windows 2000 DNS』を参照してください。

Microsoft 以外からリリースされているドキュメント
BIND についてさらに詳しく調べたい方は、『DNS and BIND』, 3rd ed., by Paul Albitz and Cricket Liu, 1998, Sebastopoilly & Associates をご覧ください。

導入実験の詳細と協力企業について

導入実験、および導入実験に提供されたハードウェアに関する情報については、『導入実験のハードウェア仕様』を参照してください。

リソース キット導入実験シナリオの凡例

Microsoft Windows 2000 リソース キット導入実験シナリオのネットワーク図で使用されている略語や記号について詳しくは、『導入実験シナリオの凡例』を参照してください。

リソース キット導入実験のネットワーク図

ネットワークの設計、ネットワーク ルーティング設計、ドメイン ネーム システム (DNS) 設計、および Active Directory 階層の高水準の編成については、『導入実験のネットワーク図』を参照してください。

関連資料

• Windows 2000 Server リソース キット 購入ページ

• Windows 2000 Professional リソース キット 購入ページ

• Windows 2000 リソース キットの詳細については、こちらを参照してください。

注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。