Active Directory サポートのための BIND (Berkeley Internet Name Domain) の構成

[アーティクル]
12/02/2012

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 のインフラストラクチャ設計については述べません。

トピック

はじめに
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 DNS ホワイトペーパー
『Windows 2000 システム展開ガイド』の「Active Directory 構造の設計」の章
Active Directory ホワイトペーパー
『DNS and BIND』(Cricket Liu 著、O'Reilly and Associates 刊、第 3 版、ISBN: 1-56592-512-2)

ページのトップへ

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 SRV 10 0 389 dc2.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.

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)] を選択して、[プロパティ] をクリックします。
[優先 DNS サーバー] ボックスに BIND サーバーの IP アドレスを入力します。下の図は、BIND サーバーの IP アドレスが 4.2.2.15 の場合を示しています。

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 との書面によるライセンス契約に明記されていない限り、本書の提供が、以上の特許、商標、著作権、あるいはその他の知的財産権の利用を認めるものではありません。

その他、記載されている会社名および製品名は、各所有者の商標である場合があります。

Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399 USA

ページのトップへ

次の方法で共有

Active Directory サポートのための BIND (Berkeley Internet Name Domain) の構成

トピック

はじめに

その他の参考文献

Windows 2000 の DNS について

ホスト名の解決

サービスロケーション

サービスロケータ (SRV) レコード

Active Directory と DNS

Active Directory をサポートするための DNS の必要条件

Active Directory DNS データの機能

Active Directory サポートのための BIND の構成

前提事項

Active Directory と BIND 8 の相互運用性に関する問題点

Active Directory サポートのための BIND の構成

BIND DNS サーバーの使用のためのドメインコントローラの構成

テストと確認

まとめ

詳細情報

その他のリソース

次の方法で共有

Active Directory サポートのための BIND (Berkeley Internet Name Domain) の構成

トピック

はじめに

その他の参考文献

Windows 2000 の DNS について

ホスト名の解決

サービス ロケーション

サービス ロケータ (SRV) レコード

Active Directory と DNS

Active Directory をサポートするための DNS の必要条件

Active Directory DNS データの機能

Active Directory サポートのための BIND の構成

前提事項

Active Directory と BIND 8 の相互運用性に関する問題点

Active Directory サポートのための BIND の構成

BIND DNS サーバーの使用のためのドメイン コントローラの構成

テストと確認

まとめ

詳細情報

その他のリソース

サービスロケーション

サービスロケータ (SRV) レコード

BIND DNS サーバーの使用のためのドメインコントローラの構成