Active Directory サポートのための BIND (Berkeley Internet Name Domain) の構成
Bob Carver
オペレーティング システム
3 Leaf Solutions LLC
概要
このホワイト ペーパーでは、Microsoft Windows 2000 オペレーティング システムと Active Directory™ により、ドメイン ネーム システム (DNS) がどのように使用されるかを説明し、また Active Directory をサポートするために必要な条件を示します。Active Directory は、アカウント管理、セキュリティ、および管理作業を統合し、コンピュータ、サーバー、およびサービス (Web サーバー サービスなど) の一元管理を可能にします。Active Directory 自体の管理はスクリプトを使って自動化でき、サーバーやサーバー ファーム上でデータを簡単に移動または再配布できるようになります。また、セキュリティ ポリシーを用いコンピュータのセキュリティを自動的に強化したり、構成変更をコンピュータにすばやく展開するといったことが可能になります。Active Directory のこういった特長は、インフラストラクチャの規模に関係なく利用でき、システム管理者は、あまりコストをかけずに多くのオブジェクトを管理できます。
Microsoft は、Windows 2000 の DNS サーバーを使用して、Active Directory とすべての DNS 機能をサポートすることを推奨しています。現在、Microsoft 以外の DNS サーバーが多く使用されており、そのような環境では Microsoft の DNS サーバーへの移行に先立って Active Directory を実装することがあります。このホワイト ペーパーでは、Active Directory のための DNS の必要条件、サービス ロケータ レコード、DNS に保存される Active Directory レコード、および Active Directory のサポートに BIND (Berkeley Internet Name Domain) DNS サーバーを使用する場合の相互運用性に関する問題について説明します。また、BIND の実装例を示し、BIND を構成して Active Directory をサポートするように設定する手順と、BIND サーバー上のゾーン データベースに DNS レコードが正しく追加されているかどうかを確認する手順についても説明します。このホワイト ペーパーでは、DNS の基本的概念や DNS のインフラストラクチャ設計については述べません。
トピック
.gif "はじめに"){kind=icon}
はじめに
Windows 2000 の DNS について
Active Directory と DNS
Active Directory サポートのための BIND の構成
まとめ
詳細情報
はじめに
Windows 2000 Server のドメイン ネーム システム (DNS) サーバーは、IETF 規格に準拠した DNS サーバーです。この DNS サーバーは、Active Directory を完全にサポートしており、標準規格に準拠したほかの DNS サーバーと完全な相互運用が可能です。また、高い性能を持ち、インストールと構成が簡単です。各種の管理オプションは、ユーザーインターフェイスを使って設定できるほか、スクリプトからも設定可能です。このような利点があるので、Windows 2000 ネットワークと Active Directory のサポートには Windows 2000 DNS サーバーを使用することをお勧めします。現在、Microsoft 以外の DNS サーバーが多く使用されており、そのような環境では Microsoft の DNS サーバーへの移行に先立って Active Directory を実装することがあります。このホワイト ペーパーでは、Microsoft DNS サーバーへの移行前の作業を簡単に行えるよう、BIND (Berkeley Internet Name Domain) を構成して Active Directory をサポートするために必要な条件について述べます。
Active Directory には、管理にかかるコストの低減に役立つ機能とセキュリティを向上する機能が豊富に用意されています。システム管理者が Active Directory を実装するにあたっては、これらの機能を活用することがポイントになります。このホワイト ペーパーは、既存の BIND (Berkeley Internet Name Domain) サーバーを Active Directory のサポートに使用しようと計画している管理者を対象にしています。Active Directory と BIND の間の相互運用性に関する問題、BIND の構成、Active Directory の BIND サポートのテストと確認について説明します。
このホワイト ペーパーでは、DNS の知識がある読者を想定しています。Windows 2000 および Active Directory によって DNS がどのように使用されるか、どのようなレコードが Active Directory によって DNS 内に保存されるか、さらに、Active Directory のサポートに必要な最低限の条件について簡単に紹介します。このホワイト ペーパーでは、DNS の基本的概念については述べません。詳細は、「その他の参考文献」で紹介している文献を参照してください。
その他の参考文献
『Windows 2000 システム展開ガイド』の「Active Directory 構造の設計」の章
『DNS and BIND』(Cricket Liu 著、O'Reilly and Associates 刊、第 3 版、ISBN: 1-56592-512-2)
.gif "ページのトップへ"){kind=icon}
ページのトップへ
Windows 2000 の DNS について
ホスト名の解決
ほかのインターネット プロトコル (IP) ホストと同様に、Windows 2000 では、主に、インターネット名から IP アドレスへの解決 (ホスト名解決) と IP アドレスから完全修飾ドメイン名への解決 (逆引き参照) に DNS を使用します。
サービス ロケーション
DNS は、ログオン用のドメイン コントローラを含めたネットワーク上のサービスを Windows 2000 コンピュータから検索するときに使用される主要な名前解決方法です。Windows 2000 の DNS は、WINS サービスのサービス ロケーション機能の代わりに使用されます。以前のバージョンの Windows NT では、Microsoft による NetBIOS 名前サービスの実装である WINS を使用して、ドメイン コントローラやその他のネットワーク サービスを検索するようになっていました。Windows NT 3.5 や 3.51、Windows NT 4.0、Windows 95、および Windows 98 などの下位レベル クライアントでネットワーク サービスを検索するには、WINS サーバーが必要です。ネットワーク サービスとドメイン コントローラを DNS 内にアドバタイズするときには、サービス ロケータ (SRV) レコードが使用されます。
サービス ロケータ (SRV) レコード
RFC 2782 で規定されているサービス ロケータ (SRV) リソース レコードは、類似した TCP/IP ベースのサービスを提供している複数のサーバーを単一の DNS クエリ操作で検索できるようにします。これらのレコードに、既知のサーバー ポートとトランスポート プロトコルの種類のリストが維持されます。このリストでは、項目が DNS ドメイン名の優先度順に並んでいます。Windows 2000 クライアントで SRV レコードを使うと、たとえば、ポート 389 で LDAP (Lightweight Directory Access Protocol) を使用しているドメイン コントローラを検索することが可能です。
SRV リソース レコードには、以下のフィールドがあります。
service 目的のサービスのシンボリック名。RFC 1700 では、既知のサービスを表す汎用シンボリック名として、"_telnet" や "smtp" などの予約名が定義されています。既知のサービスの名前が RFC 1700 で定義されていない場合は、ローカル名またはユーザー定義の名前を代わりに使用できます。POP (Post Office Protocol) など、広く使用されているサービスでも、単一の汎用シンボリック名が割り当てられていないものがあります。このフィールドに示されているサービスに対して RFC 1700 で名前が定義されている場合、その名前以外は無効になります。ローカルな名前を使用できるのは、ローカルに定義されているサービスの場合だけです。
protocol トランスポート プロトコルの種類を示します。通常は、TCP か UDP のどちらかになります。ただし、これら以外でも、RFC 1700 に定義されている任意のトランスポート プロトコルを使用できます。
name このリソース レコードから参照する DNS ドメイン名。SRV リソース レコードは、検索やクエリを実行する目的では使用されないという点で、ほかの種類の DNS レコードとは異なっています。
priority target フィールドで指定されているホストの優先度を設定します。DNS クライアントは、SRV リソース レコードを照会するときに、ここで指定されている優先度の値が最も小さいホストのうち、最初の到達可能ホストにアクセスします。複数のターゲット ホストに同じ優先度値が割り当てられてる場合、アクセスが試行される順序はランダムになります。優先度の値の範囲は、0 ～ 65535 です。
weight target フィールドに複数のサーバーを指定した場合は、それらのサーバーを同じ優先度レベルに設定したうえで、このフィールドを使うと負荷を分散させることが可能です。同じ優先度の複数のターゲット サーバー ホストから、いずれか 1 つを選択するとき、この値を使って優先度の付加的レベルを設定できます。この付加的レベルにより、SRV クエリへの応答で使用するターゲット ホストの正確な順序 (選択バランス) を決定することができます。ゼロ以外の値を指定すると、その値の重みに比例して、同じ優先度の複数のサーバーが試行されます。値の範囲は、1 ～ 65535 です。負荷分散が必要でない場合は、このフィールドの値を "0" に設定すると、レコードが読みやすくなります。
port target ホスト上のサーバー ポートのうち、service フィールドに指定したサービスを提供するポート。ポート番号の範囲は 0 ～ 65535 です。ただし、多くの場合は、RFC 1700 で指定されている既知の割り当て済みサービス ポート番号を使用することになります。しかし、必要であれば、未割り当てのポートを使用することもできます。
target 要求されているサービスの種類を提供するホストの DNS ドメイン名を指定します。使用するホスト名のそれぞれに対応するホスト アドレス (A) リソース レコードが DNS 名前空間内に必要です。このフィールドに単一のピリオド (.) を指定すると、この SRV リソース レコードで指定されている要求対象のサービスがこの DNS ドメイン名では使用できないものとみなされます。
サービスロケータ (SRV) レコードの例
構文 : |
service.protocol.name |
ttl class SRV preference weight port target |
例 : |
_ldap._tcp.ms-dcs |
SRV 0 0 389 dc1.example.microsoft.com |
ページのトップへ
Active Directory と DNS
Active Directory をサポートするための DNS の必要条件
Active Directory のサポートに使用する DNS サーバーは、認証およびクエリの目的でドメイン コントローラを検索できるように SRV レコードをサポートしている必要があります。
Windows 2000 ドメインは、DNS ドメイン名 (nt.microsoft.com など) で表されます。各ドメイン コントローラは、標準の DNS 動的更新を使用して、自分自身を DNS に登録します。DNS サーバーが動的更新をサポートしていない場合は、これらのレコードを手動で追加することが可能です。各ドメイン コントローラは、1 つのホスト レコード (A レコード) と複数の SRV レコードを登録します。
たとえば、IP アドレス 4.2.2.3 の ad.mydom.com ドメインに dc1 というドメイン コントローラがあると仮定すると、このドメイン コントローラは DNS に以下のレコードを登録することになります。
dc1.ad.mydom.com. |
A |
4.2.2.3 |
_ldap._tcp.ad.mydom.com. |
SRV |
0 0 389 dc1.ad.mydom.com. |
_kerberos._tcp.ad.mydom.com. |
SRV |
0 0 88 dc1.ad.mydom.com. |
_ldap._tcp.dc._msdcs.ad.mydom.com. |
SRV |
0 0 389 dc1.ad.mydom.com. |
_kerberos._tcp.dc._msdcs.ad.mydom.com. |
SRV |
0 0 88 dc1.ad.mydom.com. |
同じドメイン内のほかのドメイン コントローラも、上記のようなレコードを DNS に登録することになります。
Microsoft は、RFC 2136 に規定されている動的更新をサポートしている DNS サーバーを Active Directory のサポートに使用することを推奨しています。DNS サーバーが動的更新をサポートしていなくても、Active Directory 自体は機能します。Active Directory ドメインをサポートしているゾーン データに Active Directory 関連のデータを手動で追加することも可能です。ただし、各ドメイン コントローラによって登録されるレコードの数が多いと、この処理にはかなり時間がかかることになります。ドメイン コントローラの昇格時には、NETLOGON.DNS という名前のファイルが %systemroot%\system32\config フォルダ内に作成されます。このファイルには、ドメイン コントローラから登録することになる DNS エントリがすべて格納されます。このファイルは、Active Directory DNS レコードを静的に入力するときに役立ちます。
Active Directory の必要条件をサポートしている BIND のバージョン
SRV レコード (RFC 2782) および動的 DNS (RFC 2136) は、BIND version 8.2.2 patch 7 以降で完全にサポートされています。
これらのバージョンでは、あくまで、Active Directory をサポートするための必要最小限の条件が満たされています。この推奨事項では、パフォーマンスやセキュリティに関する問題への対処として BIND の各バージョンに適用する必要のあるパッチやアップデートは考慮されていません。BIND のバージョン、パッチ、および BIND の実行に関する問題の詳細については、http://www.isc.org/（英語情報） を参照してください。
Active Directory DNS データの機能
ドメイン コントローラは、さまざまなレコードを登録します。これらのレコードによって、ドメイン コントローラから提供される各種サービスがアドバタイズされます。これらのサービスには、以下のようなサービスがあります。
認証サービス (Kerberos キー配布センター (KDC))。
LDAP サービスおよびグローバル カタログ サービス。Active Directory 内のオブジェクトに関する情報をクライアントがドメイン コントローラに照会できるようにします。
Active Directory サイト情報。クエリや認証要求の送信が可能なローカル ドメイン コントローラをクライアントが検索できるようにします。
たとえば、前述した各サンプル レコードの目的は、以下に示すとおりです。
dc1.ad.mydom.com. |
A |
4.2.2.3 |
ドメイン コントローラのホスト レコード。
_ldap._tcp.ad.mydom.com. |
SRV |
0 0 389 dc1.ad.mydom.com. |
クライアントが ad.mydom.com ドメイン内の LDAP サーバーを検索して、Active Directory 内のオブジェクトを検索するためのクエリを送信できるようにします。ad.mydom.com ドメイン内のすべての Windows NT ドメイン コントローラが、この名前を登録します。
_kerberos._tcp.ad.mydom.com. |
SRV |
0 0 88 dc1.ad.mydom.com. |
クライアントがドメインの Kerberos KDC を検索できるようにします。認証およびリソース アクセス用の Kerberos サービスを提供するすべてのドメイン コントローラが、この名前を登録します。ad.mydom.com ドメイン内で Kerberos KDC サービスを実行しているすべてのドメイン コントローラが、この名前を登録します。
_ldap._tcp.dc._msdcs.ad.mydom.com. |
SRV |
0 0 389 dc1.ad.mydom.com. |
クライアントが ad.mydom.com ドメイン内のドメイン コントローラを検索できるようにします。ad.mydom.com 内のすべての Windows NT ドメイン コントローラが、この名前を登録します。
_kerberos._tcp.dc._msdcs.ad.mydom.com. |
SRV |
0 0 88 dc1.ad.mydom.com. |
ad.mydom.com ドメインに対して Kerberos KDC を実行しているドメイン コントローラをクライアントが検索できるようにします。ad.mydom.com ドメイン内で Kerberos サービスを実行しているすべての Windows NT ドメイン コントローラが、この名前を登録します。
gc._msdcs.ad.mydom.com |
SRV |
0 0 3268 dc1.ad.mydom.com. |
クライアントが通常のレコード A 検索を通じて Active Directory フォレスト内の任意のグローバル カタログ サーバーを検索できるようにします。フォレスト内のグローバル カタログにより、このレコードが登録されます。
ドメイン コントローラは、その他の複数のレコードを DNS に登録します。Active Directory ドメイン コントローラによって登録されるレコードとそれらの目的の一覧については、Windows 2000 DNS ホワイト ペーパー を参照してください。
ページのトップへ
Active Directory サポートのための BIND の構成
前提事項
ここでは、UNIX オペレーティング システムおよび Linux オペレーティング システム、ファイル システムの操作方法、デーモンの基本的構成、デーモンの再起動手順、およびテキスト エディタの使用方法を既に習得している読者を想定しています。
Active Directory と BIND 8 の相互運用性に関する問題点
前に示したように、Active Directory レコードにはアンダースコア (_) が含まれます。ホスト名 (RFC 952 および 1123) とメール ドメイン (RFC 821) ではアンダースコアを使用できませんが、ドメイン名では使えます。ドメイン名にアンダースコアを使用でき、また Active Directory では多数の複雑なレコードが必要になるので、Active Directory データが既存の DNS データと競合する可能性をできるだけ低く抑えるため、レコードのドメイン名部分でアンダースコアが使用可能になっています。
BIND 8 の既定の動作では、アンダースコアが含まれているレコードは有効とみなされません。BIND 8.x では、check-names ディレクティブを使って、マスタ ファイルやネットワークからの応答に含まれるドメイン名の文字セットを制限するようになっています。したがって、BIND 8.x で Active Directory をサポートするには、check-names オプションを無効にする必要があります。
BIND 9
BIND 9x では、ドメイン名の文字セットに関する制限はなく、check-names オプションは実装されていません。
BIND のバージョンの判別
NSLookup ユーティリティを使うと、BIND DNS サーバー上で実行されている BIND のバージョンを判別できます。バージョンを確認するには、次のコマンドを入力します。
nslookup –q=txt –class=CHAOS version.bind.0
Active Directory サポートのための BIND の構成
Active Directory をサポートするよう、BIND を構成するには、サポート対象の Active Directory に固有の情報で named.conf (構成) ファイルを構成し、サポート対象ドメインのゾーン ファイルを作成して、NameD デーモンを再起動します。
NAMED.CONF の構成
named.conf ファイルは、通常は /etc ディレクトリ内に置かれています。このファイルには、BIND デーモンの構成パラメータが格納されているほか、BIND によるサポートとサービスを受けるすべての DNS ゾーンに関する構成情報が格納されます。
下記に、BIND のディレクティブのうち、Active Directory のサポートに関係するディレクティブを挙げます。
Options グローバル サーバー オプションを指定し、ほかのステートメントの既定値を設定します。
Directory サーバーの作業ディレクトリを設定します。構成ファイル内に非絶対パス名 (ゾーン データベース ファイルの名前など) が含まれている場合、それらのパス名は、このディレクトリへの相対パス名として扱われます。既定の設定では、このディレクトリに、ほとんどのサーバー出力ファイル (named.run など) が格納されます。作業ディレクトリを指定しなければ、既定の設定として "." が適用されます。これは、サーバーを起動したディレクトリになります。作業ディレクトリは、絶対パスで指定する必要があります。
Zone ゾーン名を指定します。IN で、インターネットのアドレスの種類を指定します。
Type ゾーンのプライマリ DSN サーバーか、セカンダリ DNS サーバーかを指定します。
File ゾーン ファイル (ゾーン データを格納するファイル) の名前を指定します。このファイルは、directory ディレクティブで指定したフォルダに保存されます。
Allow-update どのホストに対して、このゾーンのレコードの動的登録を許可するかを指定します。このディレクティブには、ホストの IP アドレスまたはホスト名のリストか、サブネット全体のリストをオプションとして指定します。エントリは、セミコロン (;) で区切ります。Active Directory のサポートに必要なホスト レコードと SRV レコードが登録されるように、すべてのドメイン コントローラに対してゾーンの更新を許可してください。ほかのクライアントやサーバーについても、必要であれば自動登録を許可できます。既定の設定は、自動登録が拒否する設定になります。このディレクティブを Options セクション内で指定すると、その設定がすべてのゾーンに対し、既定値として適用されます。ゾーンごとに設定することもできます。
Check-names このディレクティブを使うと、BIND 8 の名前チェック機能を無効にして、Active Directory で使用しているアンダースコア (_) の混じったドメイン名を BIND DNS サーバーに受け付けさせることができます。このディレクティブには、warn、fail、ignore の 3 つの設定があります。既定では、warn に設定されます。設定が warn または fail の場合、アンダースコアが含まれている更新およびクエリは拒否されます。BIND 8 で Active Directory をサポートするには、このディレクティブを ignore に設定する必要があります。
BIND には、このほかにもさまざまなディレクティブがありますが、このホワイト ペーパーでは説明しません。BIND 製品の詳細については、http://www.isc.org/products/BIND/（英語情報） を参照してください。
BIND 8 のゾーンエントリの構成
named.conf ファイル内のゾーン エントリの構成を以下に示します。
Options {
directory "<作業ディレクトリ名>";
};
Zone "<Active Directory ドメインのための DNS 名>" IN {
type master;
file "<この ゾーンのファイル名>";
allow-update { <アドレスのリスト>; };
check-names ignore;
};
BIND 8 のゾーンエントリ例
ここでは、"ad.mydom.com" という名前の Active Directory ドメインをサポートするゾーン エントリの例を示します。ゾーンの種類はマスタ (プライマリ) です。ゾーン データを格納するファイルは、"db.ad.mydom.com" という名前で、"/etc/namedb" ディレクトリに保存されます。IP アドレス 4.2.2.3 のコンピュータとホスト名 "dc2" のコンピュータに対し、ゾーンへの更新の送信を許可します。アンダースコアを含む要求およびデータをサーバーで処理できるように、check-names ディレクティブを ignore に設定しています。
メモ
"//" で始まるエントリは、サーバーによって処理されるディレクティブではなく、コメントです。
Options {
directory "/etc/namedb"; // 作業ディレクトリ
};
// Active Directory ドメイン ad.mydom.com のゾーン エントリ
Zone "ad.mydom.com" IN {
type master;
file "db.ad.mydom.com";
allow-update { 4.2.2.3; dc2.; };
check-names ignore;
};
BIND 9 のゾーンエントリ例
このファイルは、check-names ディレクティブがない点を除けば、BIND 8 の例と同じです。BIND 9 では、ドメイン名の文字セットに関する制限がなく、check-names オプションは実装されていません。
Options {
directory "/etc/namedb"; // 作業ディレクトリ
};
// Active Directory ドメイン ad.mydom.com のゾーン エントリ
Zone "ad.mydom.com" IN {
type master;
file "db.ad.mydom.com";
allow-update { 4.2.2.3; dc2.; };
};
BIND の構成の終了
directory ディレクティブで指定したディレクトリ内に Active Directory ゾーン サポート用のゾーン ファイルを作成し終えたら、NameD デーモンを再起動します。これにより、BIND サーバーが Active Directory™ ゾーンに対する更新を受信できるようになります。この後、ドメイン コントローラを構成し、BIND サーバーをプライマリ DNS サーバーとして設定します。
BIND DNS サーバーの使用のためのドメイン コントローラの構成
BIND サーバーを使用するよう、ドメイン コントローラ (または Windows 2000 以降の任意のクライアント) を構成するには、アクティブなネットワーク接続の TCP/IP プロパティで BIND サーバーの IP アドレスを優先 DNS サーバーとして指定します。
その手順は以下のとおりです。
[マイ ネットワーク] を右クリックし、[プロパティ] をクリックします。
アクティブなネットワーク接続を右クリックし、[プロパティ] をクリックします。
[インターネット プロトコル (TCP/IP)] を選択して、[プロパティ] をクリックします。
.gif "cfgbin01")
[優先 DNS サーバー] ボックスに BIND サーバーの IP アドレスを入力します。下の図は、BIND サーバーの IP アドレスが 4.2.2.15 の場合を示しています。
.gif "cfgbin02")
DNS レコードの強制登録
優先 DNS サーバーを構成し終えたら、すべての DNS レコードを、新しい優先 DNS サーバーに登録させることができます。以下の 2 通りの方法があります。
NETLOGON サービスを再起動する。 この操作は、コントロール パネルで [管理ツール] をダブルクリックし、[サービス] を選択すると実行できます。この操作を実行しても、現在ログオン中のユーザーは切断されませんが、サービスが停止している間、新しいユーザーが接続することはできなくなります。NETLOGON サービスを再起動すると、DNS ゾーン データベースが即時に更新されます。再起動が完了するまでの時間は、通常、1 分未満です。
コマンドプロンプトから IPCONFIG /REGISTERDNS を実行する。 これにより、すべての DNS レコードがローカル コンピュータから新しい優先 DNS サーバーに登録されます。ただし、IPCONFIG /REGISTERDNS を使用した場合は、レコードが即時には登録されません。登録内容が DNS ゾーン データベースに反映されるまでに、最大で 15 分かかります。
テストと確認
NSLookup ユーティリティを使うと、BIND サーバーが適切に構成されているかどうか、更新を受け付けるかどうか、Active Directory ドメインに対するクエリに応答するかどうかをテストできます。NSLookup で BIND サーバーをテストするには、以下の手順に従ってください。
DNS サーバー上で、NSLookup ユーティリティを対話モードで起動します。
「set type=all」と入力し、Enter キーを押します。これにより、すべての種類のレコードが処理対象になります。
「_ldap._tcp.dc._msdcs.domainname」と入力し、Enter キーを押します。ここで、domainname は、実際のドメイン名に置き換えます。先頭のアンダースコアを忘れずに入力してください。
NSLookup は、1 つまたは複数の SRV サービス ロケーション レコードを以下の形式で返します。
hostname.domainname internet address = ipaddress
ここで、hostname はドメイン コントローラのホスト名、domainname はドメイン コントローラの所属先のドメイン、ipaddress はドメイン コントローラの IP アドレスです。
ゾーンデータベースファイル内のデータの妥当性チェック
BIND サーバー上のゾーン データベース ファイルを編集することによっても、ゾーン データが追加されているかどうかを確認できます。ゾーンに関連するすべてのデータは、directory ディレクティブで指定した作業ディレクトリ内に保存されます。動的 DNS を通じて送信された更新は、ゾーン ファイルに即時に反映されないことに注意してください。BIND サーバーでは、動的更新を IXFR (Incremental Zone Transfer) ファイルに一時的に保存するようになっています。その後、数分以内に更新がゾーン データベース ファイルに追加されます。
この例を以下に示します。
directory ディレクティブで作業ディレクトリとして "/etc/namedb" が指定されており、ゾーン エントリで "db.ad.mydom.com" というファイルが指定されている場合、ゾーン データベース ファイルのパス名は "/etc/namedb/db.ad.mydom.com" となります。更新が受信されると、IXFR ファイルが作業ディレクトリ内に作成されます。このファイルは、ゾーン データベース ファイルと同じファイル名ですが、拡張子が ".ixfr" となります。ad.mydom.com ドメインの IXFR ファイルのパス名は、"/etc/namedb/db.ad.mydom.com.ixfr" となります。
ページのトップへ
まとめ
Microsoft は、Windows 2000 の DNS サーバーで Active Directory および Windows 2000 ネットワークをサポートすることを推奨しています。Windows 2000 Server の DNS サーバーは、IETF 規格に準拠した DNS サーバーです。Active Directory を完全にサポートしており、標準規格に準拠したほかの DNS サーバーとの完全な相互運用が可能です。しかし、管理者が既存の BIND DNS サーバーで Active Directory をサポートすることを考えているのであれば、そういった構成にも対応できます。
Active Directory サポートには、SRV レコード (RFC 2782) をサポートしている DNS サーバーを使用する必要があります。さらに、可能な限り、動的 DNS (RFC 2136) をサポートしている DNS サーバーを使用することをお勧めします。
BIND を適切に展開して Active Directory をサポートするには、BIND version 8.2.2 patch 7 以降を使用してください。named.conf ファイルを構成して、Active Directory ドメインの DNS 名を定義するゾーン ステートメントを追加し、ゾーンのデータベース ファイルのパスを指定する必要があります。BIND 8 の場合は、check-names ディレクティブを ignore に設定します。ドメイン コントローラが動的 DNS を通じて DNS データを登録できるようにするには、allow-update ディレクティブを構成します。
BIND サーバーを正しく構成し、NameD デーモンを再起動した後、Windows 2000 ドメイン コントローラ、サーバー、およびクライアントの TCP/IP プロパティで BIND DNS サーバーの IP アドレスを優先 DNS サーバーとして構成します。Netlogon サービスをどの Windows 2000 クライアント上で再起動しても、DNS レコードを BIND DNS サーバーに即時に強制登録することができます。
ページのトップへ
詳細情報
Windows 2000 の最新情報については、Microsoft Web サイト (https://www.microsoft.com/japan/windows2000/) を参照してください。
Windows 2000 DNS の詳細と DNS の基本的概念については、次の URL にある Windows 2000 DNS ホワイト ペーパーを参照してください。https://technet.microsoft.com/ja-jp/library/Cc985321"
Windows 2000 Server および Active Directory の詳細については、https://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/default.mspx を参照してください。
DNS で Active Directory をサポートするために必要な条件の詳細については、http://technet2.microsoft.com/WindowsServer/ja/library/b9d72f2b-1928-46d1-8123-52407f0c4cf31041.mspx?mfr=true を参照してください。
この文書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証いたしません。
この文書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証をいたしません。
適用し得るすべての著作権法を順守する責任はユーザーにあります。本書中のいかなる部分も、Microsoft の書面による許可なしには、いかなる目的のためであれ、いかなる形態、手段 (電子的、機械的、コピー機の使用、記録など) によっても複製、検索システムへの格納、または伝送してはなりません。ただしこれは、著作権法上のお客様の権利を制限するものではありません。
この文書の内容に関する特許、特許出願、商標、著作権、およびその他の知的財産は、Microsoft が所有します。Microsoft との書面によるライセンス契約に明記されていない限り、本書の提供が、以上の特許、商標、著作権、あるいはその他の知的財産権の利用を認めるものではありません。
© 2001 Microsoft Corporation.All rights reserved.Microsoft、Active Directory、Windows、および Windows NT は、米国およびその他の国における Microsoft Corporation の登録商標または商標です。
その他、記載されている会社名および製品名は、各所有者の商標である場合があります。
Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399 USA
ページのトップへ