ダイナミック DNS アップデートの設定 - Cisco · 2012-02-24 · ダイナミック dns アップデートは、dns を dhcp と統合します。2 つのプロトコルは、補完関係

Cisco CNS Network RegOL-4363-01-J

C H A P T E R 15

ダイナミック DNS アップデートの設定

ダイナミック DNS アップデートは、DNS を DHCP と統合します。2 つのプロトコルは、補完関係

にあります。DHCP は IP アドレスの割り当てを集中的に管理し、自動化します。DNS は割り当て

られたアドレスとホスト名との間の関連付けを自動的に記録します。DHCP とダイナミック DNS

アップデートを利用することで、ホストのネットワークのための設定は、IP ネットワークに接続さ

れている限り自動的に行われます。固定的な一意の DNS ホスト名を使用して、ホストの場所を見

つけてアクセスできます。たとえば、モバイルホストはユーザまたは管理者の介入なしに、自由に

移動できます。

この章では、Cisco CNS Network Registrar サーバでダイナミック DNS アップデートを使用する方法

と、Windows 2000 クライアントシステムとの特別な関連性について説明します。

15-1istrar Release 6.1 ユーザガイド

第 15 章ダイナミック DNS アップデートの設定

ダイナミック DNS アップデートの手順

ダイナミック DNS アップデートの手順ダイナミック DNS アップデートを設定するには、少なくとも 1 つの DHCP スコープを設定して、

ホスト名を指定するかまたは Network Registrar がホスト名を生成するように要求します。アップ

デートできるのは、ダイナミック DNS アップデートをサポートするプライマリ DNS サーバのみで

す。

ダイナミック DNS アップデートを設定するには、以下の手順を実行します。

1. ダイナミック DNS アップデートに対する DHCP スコープを設定します。

2. ダイナミック DNS アップデートを受け入れる DNS ゾーンを設定します。

3. コンフィギュレージョンを調整して、必要であれば、Windows 2000 クライアントを使用可能に

します（デュアルゾーンアップデートなど）。

4. DNS サーバと DHCP サーバをリロードします。

この章の残りの部分では、各手順について詳細に説明します。

ダイナミック DNS アップデートの設定に関する考慮事項ダイナミック DNS アップデートを設定する場合、次の 2 つの問題を考慮します。

• セキュリティのため、Network Registrar のダイナミック DNS アップデートのプロセスにおいて

は、管理者が DNS データベース内に手動で入力した名前を変更または削除することはありま

せん。

• 大規模な配布に対するダイナミック DNS アップデートをイネーブルにする場合は、プライマ

リ DNS サーバと DHCP サーバを複数のクラスタで分割する必要があります。ダイナミック

DNS アップデートは、サーバに追加の負荷を与えます。

15-2Cisco CNS Network Registrar Release 6.1 ユーザガイド

OL-4363-01-J


スコープに対するダイナミック DNS の設定

スコープに対するダイナミック DNS の設定ダイナミック DNS アップデートに対して、DHCP は host-name オプション（12）でサーバに渡され

るホスト名を使用します。この名前は、クライアントのコンピュータに設定されます。

（注） Microsoft クライアントの場合、これは Control Panel/Network/Identification ダイアログボックスに表

示される名前であり、Control Panel/Network/Protocols/Microsoft TCPIP Properties/DNS ダイアログボッ

クスに表示される名前ではありません。

ステップ 1 DHCP スコープを作成します。

ステップ 2 これらのスコープアトリビュートをイネーブルにするか、または設定します。

a. dynamic-dns をイネーブルにします。

b. dns-zone-name に、クライアントのホスト名（A レコード）が追加される先の順ゾーンを設定し

ます。

c. dns-server-addr に、サーバが A レコードを追加する先のゾーンのプライマリ DNS サーバの IPアドレスを設定します。

d. dns-reverse-zone-name に、PTR レコードおよび TXT レコードでアップデートされる逆

（in.addr.arpa）ゾーンを設定します。これはオプションで、デフォルトは順ゾーンアドレスで

す。設定解除されて、DHCP サーバの synthesize-reverse-zone アトリビュートがイネーブルであ

ると、サーバは各リースのアドレス、スコープのサブネット番号、およびスコープの dns-host-bytes アトリビュート値に基づいて逆ゾーン名を作成します。

e. dns-rev-server-addr に、サーバが PTR レコードを追加する先のゾーンのプライマリ DNS サーバ

のアドレスを設定します。

f. 必要であれば、synthetic-name-stem 値を設定して、スコープ上の synthesize-name をイネーブル

にします。

synthetic-name-stem スコープアトリビュートを使用して、クライアントがホスト名を提供しな

い場合に使用するデフォルトのホスト名の基語を設定できます。デフォルトの合成名基語は

dhcp です。その後、enable synthesize-name スコープアトリビュートイネーブルにして、DHCPサーバが synthetic-name-stem アトリビュートの値に基づいてクライアントの一意な名前を合成

するようにすることができます。

g. 必要であれば、use-dns-update-prereqs サーバアトリビュートをイネーブルにします。

デフォルト（推奨）では、DHCP サーバは、クライアントのために DNS アップデートを実行す

る場合、DNS アップデートメッセージ内の前提条件を使用します。use-dns-update-prereqs アト

リビュートをディセーブルにすると、このスコープからリースのアップデートを実行するとき

に、サーバは前提条件を組み込みません。前提条件を使用しない場合、サーバは、別のクライ

アントがすでにその名前に関連付けられている場合でも、所定のドメイン名を使用する最後の

クライアントをその名前に関連付けます。

ステップ 3 DHCP サーバをリロードします。


OL-4363-01-J


ゾーンに対するダイナミックアップデートのイネーブル化

ゾーンに対するダイナミックアップデートのイネーブル化各ゾーンに対して DNS サーバをイネーブルにして、DNS サーバのダイナミック DNS アップデート

をイネーブルにする必要があります。

ステップ 1 プライマリ順ゾーンを作成します。

ステップ 2 ゾーンに対して次のアトリビュートをイネーブルにします。

• dynamic

• update-acl（P.15-5 の「トランザクションセキュリティとアクセスコントロールリスト」を参

照）。

ステップ 3 同じ設定でプライマリ逆ゾーンを作成します。

ステップ 4 必要であれば、DNS サーバアトリビュート update-relax-zone-name をイネーブルにします。つまり、

ダイナミックアップデートゾーン名レコードが実際のゾーン名であるときに必要な、RFC 2136 で

課せられた制限を緩和できます。各スコープが異なるプレフィックスを持つ名前を生成するが、そ

れらのプレフィックスが必ずしもすべて個別のゾーンとして設定されないようにホスト名を構成

する場合は、これを行う必要があります。通常はこの制限が有効であるため（デフォルト）、サー

バは、これらのアドレスが実際のどのゾーンに存在するかを識別できず、DNS サーバにより無効と

見なされるパケットを作成します。

この制限を取り除くと、権限ゾーン内で任意の名前を付けることができます。たとえば、DNS には

順ゾーンが example.com として設定されています。3 つのスコープ（net1、net2、および net3）を作

成して、その順ゾーンを net1.example.com、net2.example.com、および net3.example.com と指定します。

ステップ 5 DNS サーバをリロードします。


OL-4363-01-J


トランザクションセキュリティとアクセスコントロールリスト

トランザクションセキュリティとアクセスコントロールリストTransaction Signatures（TSIG）によって DNS パケットを認証します。これは DNS サーバをイネー

ブルにして、メッセージの内容が改変されていないことを確認し、メッセージが信頼されるソース

からであることを検証します。アクセスコントロールリスト（ACL）によってクライアントを許

可します。これはサーバをイネーブルにして、パケットに定義された要求またはアクションを許可

または否認します。

TSIG は Network Registrar Release 6.0 からサポートされ、そのリリースではダイナミック DNS アッ

プデートのみを対象とします。Network Registrar Release 6.1 では、照会およびゾーン転送のサポー

トが追加されました。

ACL は許可リストです。Network Registrar の以前のバージョンでは、単純な IP アドレスベースの

ACL を持っていました。Network Registrar Release 6.0 では、リストはさらに高度になり、TSIG キー

を組み込む機能があります。

保護される各固有なアクション（DNS 照会、アップデート、またはゾーン転送など）については、

TSIG が唯一の認証メカニズムなので、ACL をセットアップしてアクセス権制御を提供する必要が

あります。TSIG 処理は、TSIG 情報を含むメッセージについてのみ実行されます。この情報を含ま

ないか、または除去されたメッセージは、認証プロセスが省略されます。

まったくセキュアなソリューションの場合、メッセージは認証されるキーと同じキーで許可される

必要があります。たとえば、DHCP サーバがダイナミック DNS アップデートのために TSIG を使用

するように設定され、同じ TSIG キーがアップデートされるゾーンの ACL に含まれている場合、

TSIG 情報を含まないパケットはすべて認証ステップを失敗します。これによってアップデートト

ランザクションが保護され、メッセージはゾーン変更を行う前に認証され、かつ許可されます。

アクセスコントロールリスト

DNS サーバレベルまたはゾーンレベルで ACL を割り当てます。ACL は、次の要素を 1 つまたは

複数含むことができます。

• IP アドレス：ドット付き 10 進形式の表記（たとえば、192.168.1.2）。

• ネットワークアドレス：ドット付き 10 進とスラッシュ形式の表記（たとえば、192.168.0.0/24）。この例では、そのネットワーク上のホストのみ DNS サーバをアップデートできます。

• 別の ACL：その ACL が定義済みである必要があります。この ACL は、定義する ACL に値と

して含まれるため、削除できません。

• Transaction Signature（TSIG）キー：この値は key value という形式で、キーワード key の後に秘

密値を指定する必要があります。空白文字があるため、リスト全体を二重引用符で囲む必要が

あります。TSIG キーについては、P.15-6 の「トランザクションセキュリティ」を参照してく

ださい。

各 ACL に一意の名前を割り当てます。しかし、次の ACL 名は特別な意味があるので、通常の ACL

名には使用できません。

• any：誰でも特定のアクションを実行できる。

• none：特定のアクションを誰も実行できない。

• localhost：どのローカルホストアドレスでも特定のアクションを実行できる。

• localnets：どのローカルネットワークでも特定のアクションを実行できる。

ローカルクラスタ Web UI の場合、Primary Navigation バーで Administration をクリックします。

Secondary Navigation バーで、ACLs をクリックします。ACL 名と照合リストを追加します。key

value ペアを引用符で囲まないように注意してください。


OL-4363-01-J



CLI の場合、名前と 1 つまたは複数の ACL 要素を指定して acl コマンドを使用します。ACL リスト

はカンマ区切りのリストで、空白文字がある場合はリストを二重引用符で囲みます。

たとえば、次のコマンドでは 3 つの ACL が作成されます。最初の ACL は、値を持つキーで、2 番

目の ACL はネットワーク用、3 番目の ACL は最初の ACL を参照します。値の前に ! 記号を含める

と、その値がネゲート（否定）されます。したがって、一連の値の中でその値を除外できます。

nrcmd> acl sec-acl create "key h-a.h-b.example.com." nrcmd> acl dyn-update-acl create "192.168.2.0/24,!192.168.2.13" nrcmd> acl main-acl create sec-acl

ヒント ACL で 0.0.0.0/0 というネットワーク指定を使用して、すべてのユーザにゾーンのアップデートを許

可できます。

アクセスコントロールリストに対する DNS サーバまたはゾーンの設定

DNS サーバまたはゾーンに関する ACL を設定するには、update-acl アトリビュートを使用します。

ゾーンレベルで設定した ACL は、サーバの値を上書きします。値の前に ! 記号を含めると、その

値がネゲートされます。したがって、その値を除外できます。ACL は、ORed リストで、左から右

に検索されます。リスト内にネゲート要素を入れると、ほかの要素の前にその要素が位置付けられ、

ネゲート要素が必ず最初に処理されます。

トランザクションセキュリティ

Transaction Signatures（TSIG）によって受信する各メッセージを認証するように DNS サーバをイ

ネーブルにします。サーバ間の通信は暗号化されませんが、デジタル署名されます。これによりパ

ケットのデータおよびソースの信頼性の検証ができます。

ダイナミック DNS アップデートのために TSIG を使用するように Network Registrar DHCP サーバを

設定すると、サーバはメッセージに TSIG リソースレコードを付加します。TSIG レコードの一部

はデジタル署名です。

DNS サーバはメッセージを受信すると、TSIG レコードを探します。検出すると、まずその中のキー

名が認識するキーの内の 1 つであることを検証します。その後、アップデートのタイムスタンプが

妥当であることを検証します（トラフィックなりすまし攻撃に対抗するため）。最後に、サーバは、

パケットで送信されたキーの共有秘密を参照して独自の署名を算出します。算出された署名がパ

ケットに組み込まれた署名と一致すると、内容が信頼できると見なされます。

Network Registrar では、TSIG キー名が、共有秘密値と関連付けられます。キー名は、そのキーを使

用するホストの名前を反映する必要があります。名前のエントリには、共有秘密も必要です。

キーの生成

Network Registrar cnr_keygen ユーティリティを使用して TSIG キーを生成し、import keys コマンド

を使用してそれを追加またはインポートできるようにすることをお勧めします。

DOS プロンプト、あるいは Solaris または Linux のシェルから cnr_keygen キージェネレータユー

ティリティを実行します。

• Windows では、このユーティリティは install-path\bin フォルダにあります。

• Solaris および Linux では、このユーティリティは install-path/usrbin ディレクトリにあります。


OL-4363-01-J



このユーティリティの使用例（Solaris および Linux）を次に示します。

> /opt/nwreg2/local/usrbin/cnr_keygen -n a.b.example.com. -a hmac-md5 -t TSIG -b 16 -s 300

key "a.b." { algorithm hmac-md5; secret "xGVCsFZ0/6e0N97HGF50eg=="; # cnr-time-skew 300; # cnr-security-type TSIG;

};

必須の入力項目は、キー名だけです。オプションについては、表 15-1 で説明します。

生成される秘密値は、ランダム文字列として base64 でエンコードされています。

コマンドラインの末尾に > または >> インジケータを使用して、出力をファイルにリダイレクトす

ることもできます。> では所定のファイルに対する書き込みまたは上書き、>> では既存のファイル

への追加が行われます。設定例を次に示します。

> /opt/nwreg2/local/usrbin/cnr_keygen -n example.com > keyfile.txt > /opt/nwreg2/local/usrbin/cnr_keygen -n example.com >> addtokeyfile.txt

その後、CLI を使用して Network Registrar にキーファイルをインポートし、ファイル内のキーを生

成できます。キーのインポートでは、インポートファイル内で検出されるすべてのキーを生成でき

ます。設定例を次に示します。

nrcmd> import keys keyfile.txt

キーの管理の考慮事項

独自のキーを生成する場合は、base64 でエンコードされた文字列としてキーを入力する必要があり

ます。つまり、使用できる文字は、base64 アルファベットとパディング文字（=）だけです。base64

でエンコードされていない文字列を入力すると、エラーメッセージが表示されます。次に、その他

の推奨事項をいくつか示します。

• バッチコマンドを使用してキーを追加または変更しない。

• 共有秘密を頻繁に変更する。2 ヶ月ごとに変更することをお勧めします。Network Registrar は、

変更を明示的に強制しません。

表 15-1 cnr_keygen ユーティリティのオプション

オプション説明

–n name キー名。必須。最大長は 255 バイトです。

–a hmac-md5 アルゴリズム。オプション。現在、hmac-md5 だけがサポートされています。

–b bytes 秘密のバイトサイズ。オプション。デフォルトは 16 バイトです。有効な範囲は、

1 ～ 64 バイトです。

–s skew キーの時間差（秒）。これは、このキーで署名されたパケット内のタイムスタン

プとローカルシステム時間との最大の差です。オプション。デフォルトは 5 分で

す。有効な範囲は、1 秒～ 1 時間です。

–t tsig 使用するセキュリティのタイプ。オプション。現在、TSIG のみをサポートします。

–h ヘルプ。オプション。このユーティリティのシンタックスとオプションが表示さ

れます。

–v バージョン。オプション。このユーティリティのバージョンが表示されます。


OL-4363-01-J


ダイナミックレコードの確認

• 共有秘密の長さは、少なくともキー付きメッセージダイジェスト（HMAC-MD5 は 16 バイト）

と同じ長さである必要がある。Network Registrar は、明示的にこれを強制せず、共有秘密が

base64 でエンコードされた有効な文字列であることだけを確認しますが、これは RFC 2845 によって推奨されているポリシーです。

TSIG アトリビュートサポートの追加

キー名、オプションの時間差値、および秘密値を追加します。その後、DHCP サーバまたはスコー

プについて、次のアトリビュート値を設定します。

• dynamic-dns-tsig：この機能を順ゾーンに設定するか、逆ゾーンに設定するか、両方に設定する

かを決定します。スコープレベルの場合、これを enable-fwd-rev、disable-fwd-rev、enable-fwd-only、enable-rev-only、または use-server-settings に設定できます。サーバレベルの場合は、これを

enable-fwd-rev、disable-fwd-rev、enable-fwd-only、または enable-rev-only に設定できます。

• dynamic-tsig-fwd-key：順ゾーン専用のキー。

• dynamic-tsig-rev-key：逆ゾーン専用のキー。

ダイナミックレコードの確認Network Registrar DHCP サーバは、待ち状態の DNS アップデートデータをすべてディスクに格納し

ます。DHCP サーバが DNS サーバと通信できない場合は、DHCP サーバは通信を再確立するために

定期的にテストを実行し、待ち状態のアップデートをすべてサブミットします。このテストは、通

常、40 秒ごとに行われます。

ローカルクラスタ Web UI でダイナミック DNS レコードを確認するには、次の手順で行います。

ステップ 1 Primary Navigation バーで、Zone をクリックします。

ステップ 2 Secondary Navigation バーで、Zones をクリックします。

ステップ 3 Active Server RRs カラムで View アイコン（）をクリックし、List/Add DNS Server Resource Records

for Zone ページを開きます。

DNS アップデートが動作していることを CLI で確認するには、zone name listRR dynamic コマンド

を使用します。


OL-4363-01-J


変更セットとチェックポイント処理

変更セットとチェックポイント処理Network Registrar は、変更セットデータベースを保持し、ゾーン内のリソースレコードに対するす

べてのダイナミックな変更を、パフォーマンスを向上させる方法でキャプチャします。サーバが、

外部のダイナミック DNS アップデート、完全または差分ゾーン転送、ゾーンチェックポイント処

理、古いレコードの清掃、構成データベースの差分または完全リロードに応答するときに、Network

Registrar は変更セットデータベースを呼び出します。清掃については、P.15-10 の「ダイナミック

レコードの清掃」を参照してください。変更セットデータベースは、通常の mcdshadow バックアッ

プ中にバックアップされます。

変更セットは、1 つのリソースレコードである場合も多くのレコードである場合もあります。ダイ

ナミック DNS アップデートまたは差分ゾーン変更は、まず、サーバが管理する変更セットアップ

デートバッファに格納されます。10 ミリ秒のトランザクションインターバル（または 50000 変更

セット）ごとに、データはこのバッファから、データベース内のトランザクションログにフラッ

シュされます。この変更セットはトランザクションログに蓄積され、20 秒のチェックポイントイ

ンターバルごとにデータベース履歴ファイルにコミットされます。各ログファイルの最大サイズは

10 MB で、このファイルはコミット後 10 分ごとにトリムされます。

データベースファイルにはサーバのゾーンごとに 1 つの履歴リストがあり、リスト内の各エントリ

がそのゾーンの変更を表します（完全ゾーン転送の場合、履歴では転送が行われたことのみ示され

ます）。このコミットされたデータは、発信差分ゾーン転送の構成要素となります。30 秒ごとに、

データベースはほんの一部（特定の率）の履歴を調べて、履歴が大きくなりすぎた場合にトリムで

きるかどうかを確認します。履歴が 2000 変更セットに達するとすぐに、ゾーンのチェックポイン

ト処理が行われ、データベースは、常に保持する最大 400 変更セットを除き、残りの履歴をトリム

します（これらのデフォルト設定の変更は、指示がある場合のみ行ってください。P.15-11 の「ダ

イナミック DNS アップデートのトラブルシューティング」を参照）。

ゾーンのチェックポイントは、変更セットのチェックポイントとは異なります。ゾーンのチェック

ポイント処理では、auth.db ファイルのスナップショットがフラットデータファイルに保存され、

auth.db ファイルが最新の変更セットでアップデートされます。ゾーンのチェックポイントは、2000

変更セットごとに発生するだけでなく、デフォルトで 3 時間ごとにも発生します。zone

checkpoint-interval アトリビュートを使用して、1 ～ 168 時間の間でこのインターバルを調整できま

す。ゾーンのチェックポイントインターバルを大きくすると、ランタイムオーバーヘッドは小さ

くなりますが、変更セットデータベースが多くの履歴レコードを保持することになります。CLI の

場合は、zone name chkpt コマンドを使用してゾーンチェックポイントを強制することができ、ま

た zone name dumpchkpt コマンドを使用して人が読みやすい形式でゾーンチェックポイントファ

イルをダンプすることもできます。


OL-4363-01-J


ダイナミックレコードの清掃

ダイナミックレコードの清掃DHCP リースを取得した Microsoft Windows 2000 DNS クライアントは、そのアドレス（A）レコー

ドを DNS サーバで直接アップデート（リフレッシュ）できます。このようなクライアントの多く

はモバイルラップトップであり、永続的に接続しているわけではないため、一部の A レコードは

時間が経つと古くなります。Windows 2000 DNS サーバはこれらのプライマリゾーンレコードを定

期的に清掃および除去します。Network Registrar には同様の機能があり、古いレコードを定期的に

除去するように設定するのに使用できます。

清掃は、通常、デフォルトでディセーブルですが、Windows 2000 クライアントだけを含むゾーンで

はイネーブルにする必要があります。ゾーンには、no-refresh インターバルと refresh インターバル

が設定されます。レコードは、最初の作成日の後、これら 2 つのインターバルを過ぎると期限切れ

となります。図 15-1 は清掃スケジュールのインターバルを示します。

図 15-1 アドレスレコードの清掃スケジュールのインターバル

Network Registrar のプロセスは、次のとおりです。

1. クライアントが新しい A レコードで DNS サーバをアップデートすると、そのレコードはタイ

ムスタンプを取得します。または、クライアントがその A レコードをリフレッシュすると、そ

のレコードはタイムスタンプをアップデートできます（「レコードが作成またはリフレッシュ

される」）。

2. 非リフレッシュインターバル（デフォルトでは 7 日）の間は、クライアントがアドレスを変更

せずに同じレコードを送信し続ける場合、レコードのタイムスタンプはアップデートされませ

ん。

3. レコードは、非リフレッシュインターバルを過ぎると、リフレッシュインターバル（これも

デフォルトでは 7 日）に入ります。この期間中、ダイナミックアップデートはタイムスタンプ

をリフレッシュし、レコードは非リフレッシュインターバルに戻ります。

4. リフレッシュインターバルを過ぎて清掃インターバルに到達したレコードは、清掃に使用でき

ます。

次のゾーンアトリビュートは清掃に影響を及ぼします。

• scvg-interval：DNS サーバがゾーン内に古いレコードがあるかどうかを調べる期間。デフォル

トは 7 日で、1 時間から 365 日までの値を設定できます。この値は、サーバレベルおよびゾー

ンレベルで設定できます。ただし、ゾーン設定はサーバ設定を上書きします。

• scvg-no-refresh-interval：ダイナミックアップデートや前提条件のみのダイナミックアップデー

トなどのアクションが、レコードのタイムスタンプをアップデートしないインターバル。デ

フォルトは 7 日で、1 時間から 365 日までの値を設定できます。ゾーン設定はサーバ設定を上

書きします。

• scvg-refresh-interval：ダイナミックアップデートがレコードのタイムスタンプをアップデート

するインターバル。非リフレッシュインターバルとリフレッシュインターバルの両方が満了

になると、レコードは清掃の候補となります。デフォルトは 7 日で、1 時間から 365 日までの

値を設定できます。ゾーン設定はサーバ設定を上書きします。

No-Refresh

5952

2

Refresh

t0

t

tnr tnr+r


OL-4363-01-J


ダイナミック DNS アップデートのトラブルシューティング

• scvg-ignore-restart-interval：サーバが、必ずしも再起動のたびに清掃時間をリセットしないよう

にします。このインターバル内である場合、Network Registrar は、サーバがダウンしてから再

起動するまでの時間（通常はかなり短い）を無視します。このインターバルは、デフォルトで

は 2 時間ですが、最大 1 日に設定できます。設定した時間よりも長い時間が経過すると、NetworkRegistrar は清掃期間を再計算し、サーバの停止中にアップデートできなかったレコードのアッ

プデートを可能にします。ゾーン設定はサーバ設定を上書きします。

Network Registrar DNS サーバが Windows 2000 クライアント（または定期的な自動 DNS アップデー

トを行うことが知られているクライアント）だけからアップデートを受け取るゾーンに対しての

み、清掃をイネーブルにします。上に一覧表示したアトリビュートを設定します。Network Registrar

清掃マネージャは、サーバの起動時に起動します。清掃で除去されたレコードを変更セットデータ

ベースに報告します。Network Registrar はまた、プライマリゾーンから清掃されたすべてのレコー

ドのゾーン転送のためにセカンダリゾーンに通知します。清掃がディセーブルな（レコードがタイ

ムスタンプを持たない）ゾーンを作成し、後で清掃をイネーブルにした場合、Network Registrar は、

各レコードのデフォルトタイプスタンプとして、プロキシタイムスタンプを使用します。

CLI の場合、ゾーンに対して getScavengeStartTime アクションを使用して、そのゾーンの次回の清

掃開始スケジュールを確認できます。清掃がイネーブルなすべてのゾーンの場合は dns scavenge コ

マンド、清掃がイネーブルな特定のゾーンの場合は zone name scavenge コマンドを使用することに

よって、いつでも強制的に清掃を行うことができます。

1 つまたは複数のログ設定、scavenge、scavenge-details、ddns-refreshes、および ddns-refreshes-details

を使用して清掃アクティビティを監視できます。

ダイナミック DNS アップデートのトラブルシューティングDNS サーバに対してダイナミックアップデートが正常に行われたことを確認するには、nslookup

ツールを使用して、逆ルックアップを実行します。

$ nslookup Default Server: server2.example.com Address: 192.168.1.2 > leasehost1.example.com Server: server2.example.com Address: 192.168.1.100 > set type=ptr > 192.168.1.100 Server: server2.example.com Address: 192.168.1.100

100.40.168.192.in-addr.arpa name = leasehost1.example.com 40.168,192.in-addr.arpa nameserver = server2.example.com

log-settings アトリビュートに ddns を設定すると DNS サーバ上のダイナミック DNS アップデート

を監視でき、あるいは ddns-details を設定するとより詳細に表示できます。


OL-4363-01-J


Windows 2000 クライアントに対する DNS アップデートの設定

Windows 2000 クライアントに対する DNS アップデートの設定Microsoft Windows 2000 オペレーティングシステムは、DNS に大きく依存し DHCP にはあまり依存

しません。以前の Windows バージョンのこの依存関係は大幅に変更され、ネットワーク管理者は広

範囲の Windows 2000 展開を行う前に入念に準備する必要があります。

Windows 2000 クライアントは、そのアドレス（A）レコードで順ゾーンを直接アップデートして、

それ自身のエントリを DNS に追加できます。しかし、そのポインタ（PTR）レコードで逆ゾーンを

アップデートすることはできません。

クライアントの DNS アップデート

クライアントが DNS を直接アップデートできるようすることは推奨しません（P.15-18 の「推奨の

Windows 2000 デザインプラクティス」を参照）。

Windows クライアントがアドレスレコードのアップデートを DNS サーバに直接送信するには、次

の 2 つの条件が満たされている必要があります。

• Windows 2000 クライアントの TCP/IP コントロールパネル設定の DNS タブで、Register this connection’s addresses in DNS ボックスがオンになっていること

• DHCP ポリシーが直接のアップデートをイネーブルにしていること（Network Registrar ポリシー

はデフォルトでこれを行っています）

Windows 2000 クライアントは、DHCPREQUEST パケットで client-fqdn DHCP オプション（81）を

送信することによって、DNS サーバに対して A レコードをアップデートする意志を DHCP サーバ

に伝えます。完全修飾ドメイン名（FQDN）を示すことによって、このオプションは、ドメインネー

ムスペース内のクライアントの場所を明確に表します。FQDN 自身とともに、クライアントまたは

サーバは次のフラグのいずれかを client-fqdn オプションで送信できます。

• 0：クライアントはその A レコードを DNS サーバに直接登録する必要があり、DHCP サーバは

PTR レコードを登録します（ポリシーの allow-client-a-record-update アトリビュートをイネーブ

ルにすることで行われます）。

• 1：クライアントが、DHCP サーバに、クライアントの A レコードと PTR レコードを DNS サー

バに登録するよう要求します。

• 3：クライアントの要求に関係なく、DHCP サーバが A レコードと PTR レコードを DNS サー

バに登録します（ポリシーの allow-client-a-record-update アトリビュートをディセーブルにする

ことによって行われます。これはデフォルトです）。DHCP サーバだけが、このフラグを設定で

きます。

DHCP サーバは、ダイナミック DNS アップデートがイネーブルであるかどうかに基づいて、

DHCPACK でクライアントに独自の client-fqdn 応答を返します。ただし、0 フラグが設定されてい

る（ポリシーの allow-client-a-record-update プロパティがイネーブル）場合は、クライアントがその

アップデートを DNS サーバに送信できるため、ダイナミック DNS アップデートがイネーブルであ

るかディセーブルであるかは関係ありません。設定する各種プロパティに基づいて実行されるアク

ションについては、表 15-2 を参照してください。

表 15-2 Windows 2000 クライアントの DNS アップデートオプション

DHCP クライアントのアクションダイナミック DNS DHCP サーバのアクション

Register this connection’s addresses in

DNS をチェックして、client-fqdn を送

信する。DHCP サーバは allow-client-

a-record-update をイネーブルにする。

イネーブルま

たはディセー

ブル

クライアントがその A レコードをアップ

デートすることを許可する client-fqdn で

応答するが（フラグ 0 を設定）、DHCP サー

バが依然として PTR レコードをアップ

デートする。


OL-4363-01-J



Windows 2000 RC3 DHCP サーバは、クライアントの要求を無視するように client-fqdn オプションを

設定できます。Network Registrar でこれをイネーブルにするには、Windows 2000 クライアントのポ

リシーを作成して、このポリシーの allow-client-a-record-update アトリビュートをディセーブルにし

ます。

次のアトリビュートは、Network Registrar ではデフォルトでイネーブルになっています。

• サーバの use-client-fqdn：サーバは着信パケット上の client-fqdn 値を使用し、host-name は調べ

ません。DHCP サーバは、そのクライアントに定義されているスコープからドメインを特定す

るため、ドメイン名の値の最初のドットの後にあるすべての文字を無視します。クライアント

が予想外の文字を送信する可能性があるため、サーバが client-fqdn からホスト名を特定しない

ようにする場合のみ、use-client-fqdn をディセーブルにします。

• サーバの use-client-fqdn-first：サーバはクライアントからの着信パケット上の client-fqdn を調べ

てから、host-name オプション（12）を調べます。client-fqdn にホスト名が含まれていると、サー

バはそれを使用します。サーバは、このオプションが見つからない場合、host-name 値を使用し

ます。use-client-fqdn-first がディセーブルであると、サーバは client-fqdn よりも host-name 値を

優先します。

• サーバの use-client-fqdn-if-asked：クライアントが要求すると、サーバは発信パケットで client-fqdn値を返します。たとえば、クライアントは、DNS アクティビティの状態を知る必要があるた

め、DHCP サーバに client-fqdn 値を提供するよう要求することがあります。

• ポリシーの allow-client-a-record-update：クライアントが client-fqdn フラグを 0 に設定している

場合（直接アップデートを要求）、クライアントは DNS サーバで A レコードを直接アップデー

トできます。このフラグが 0 でない場合、DNS サーバは、ほかのコンフィギュレーションプロパティに基づいて A レコードをアップデートします。

クライアント要求に返されるホスト名は、次の設定により異なります（表 15-3 を参照）。

Register... をチェックして、client-fqdn

を送信する。DHCP は allow-client-

a-record-update をディセーブルにす

る。

イネーブルクライアントが DNS サーバを直接アップ

デートすることを許可しない client-fqdn

で応答し（フラグ 3 を設定）、A および PTR

レコードをアップデートする。

ディセーブル client-fqdn で応答せず、DNS サーバをアッ

プデートしない。

Register... のチェックを解除し、

client-fqdn を送信する。

イネーブル A および PTR レコードをアップデートし

ている client-fqdn で応答する。



client-fqdn を送信しない。イネーブル client-fqdn で応答しないが、A および PTR

レコードはアップデートする。



表 15-2 Windows 2000 クライアントの DNS アップデートオプション（続き）

DHCP クライアントのアクションダイナミック DNS DHCP サーバのアクション


OL-4363-01-J



Windows 2000 クライアントのデュアルゾーンアップデート

Windows 2000 DHCP クライアントは、2 つの DNS ゾーン内に A レコードが存在する DHCP 配置の

一部である場合があります。この場合、DHCP サーバは、クライアントがデュアルゾーンアップ

デートを要求できるように client-fqdn を返します。デュアルゾーンアップデートをイネーブルにす

るには、ポリシーアトリビュート allow-dual-zone-dns-update をイネーブルにします。

DHCP クライアントが client-fqdn で 0 フラグを送信し、DHCP サーバが 0 フラグを返すため、クラ

イアントはそのメインゾーン内で A レコードによって DNS サーバをアップデートできます。ただ

し、DHCP サーバも、クライアントのセカンダリゾーンに基づいてクライアントの代わりに A レ

コードアップデートを直接送信します。allow-client-a-record-update と allow-dual-zone-dns-update が

両方イネーブルである場合、デュアルゾーンアップデートが優先されるため、DHCP サーバがセ

カンダリゾーンの A レコードをアップデートできます。

Windows 2000 クライアントでのダイナミック DNS アップデート設定

Windows 2000 RC3 クライアントで詳細プロパティを設定し、client-fqdn オプションの送信をイネー

ブルにすることができます。

ステップ 1 Windows 2000 RC3 クライアントで、Control Panel に移動して、TCP/IP Settings ダイアログボックス

を開きます。

ステップ 2 Advanced タブをクリックします。

ステップ 3 DNS タブをクリックします。

表 15-3 クライアント要求パラメータに基づいて返されるホスト名

クライアント要求サーバ / ポリシーでの設定結果のホスト名

host-name（オプション

12）を含む

use-host-name=true

use-client-fqdn=false

（または use-client-fqdn-first=false）trim-host-name=true

host-name。最初のドットでトリムさ

れる。

例：host-name host1.bob は返された

host1

（次を除き同じ）

trim-host-name=falsehost-name。

例：host-name host1.bob は返された

host1.bob

client-fqdn（オプション

81）を含む

use-client-fqdn=true

use-host-name=false

（または use-client-fqdn-first=true）

client-fqdn。最初のドットでトリムさ

れる。

例：client-fqdn host1.bob は、返され

た host1

host-name（オプション

12）および client-fqdn（オ

プション 81）を省略

または

use-host-name=false

use-client-fqdn=false

クライアント/ポリシー階層で設定。

（次を除き前と同じ）

ホスト名は、クライアント / ポリ

シー階層では未定義

synthesize-name=true

合成規則に従って合成される。

（次を除き前と同じ）

synthesize-name=false未定義。


OL-4363-01-J



ステップ 4 クライアントが要求において client-fqdn オプションを送信できるようにするには、Register this

connection's addresses in DNS ボックスをオンのままにしておきます。これは、クライアントが A レ

コードのアップデートを実行するということを示します。

DHCP サーバでの Windows 2000 クライアント設定

Windows 2000 クライアントを含むスコープに対して関連ポリシーを適用し、スコープに対する

DNS アップデートをイネーブルにすることができます。

ステップ 1 Windows 2000 クライアントを含むスコープに対するポリシーを作成します。設定例を次に示しま

す。

a. policywin2k を作成します。

b. サブネット 192.168.1.0/24 とポリシーとして policywin2k を持つ win2k スコープを作成します。

192.168.1.10 ～ 192.168.1.100 のアドレス範囲を追加します。

ステップ 2 スコープアトリビュート dynamic-dns をイネーブルにします。

ステップ 3 P.15-3 の「スコープに対するダイナミック DNS の設定」で説明したように、ゾーン名、（A レコー

ドに対する）サーバアドレス、逆ゾーン名、および（PTR レコードに対する）逆サーバアドレス

を設定します。

ステップ 4 クライアントが DNS サーバで A レコードをアップデートするようにする場合は、ポリシーアトリ

ビュート allow-client-a-record-update をイネーブルにします（これがデフォルトです）。これには、

いくつかの注意事項があります。

• allow-client-a-record-update がイネーブルで、クライアントがアップデートビットをイネーブル

にして client-fqdn を送信すると、クライアントに返される host-name と client-fqdn はクライアン

トの client-fqdn に一致します（しかし、サーバ上で override-client-fqdn もイネーブルの場合、ク

ライアントに返されるホスト名と FQDN は設定されたホスト名とポリシードメイン名から生

成されます）。

• あるいは、クライアントがアップデートビットをイネーブルにして client-fqdn を送信しない場

合、サバーは A レコードをアップデートし、クライアントに返される host-name と client-fqdn（要求された場合）は、ダイナミック DNS アップデートに使用される名前と一致します。

• allow-client-a-record-update がディセーブルの場合、サーバは A レコードをアップデートし、ク

ライアントに返される host-name と client-fqdn（アップデートビットはディセーブル）は、ダ

イナミック DNS アップデートに使用される名前と一致します。

• allow-dual-zone-dns-update がイネーブルの場合、DHCP サーバは常に A レコードのアップデー

トを行います（P.15-14 の「Windows 2000 クライアントのデュアルゾーンアップデート」を参

照）。

• use-dns-prereqs がイネーブルで update-dns-first がディセーブルの場合、クライアントに返され

るホスト名と client-fqdn は、名前の明確化の遅れのために、DNS アップデートと一致すること

は保証されませんが、リースデータは新しい名前でアップデートされます。

ステップ 5 DHCP サーバをリロードします。


OL-4363-01-J



SRV レコードとダイナミック DNS アップデート

Windows 2000 は、ネットワークへのサービスのアドバタイズについては DNS プロトコルに大きく

依存しています。表 15-4 で、Windows 2000 が service location（SRV）DNS リソースレコードとダ

イナミック DNS アップデートを処理する方法を説明します。

表 15-4 Windows 2000 SRV レコードとダイナミック DNS アップデート

機能説明

SRV レコード Windows 2000 ドメインコントローラは、SRV リソースレコードを使用して、

そのサービスをネットワークにアドバタイズします。このリソースレコード

は、RFC 2782 の「A DNS RR for specifying the location of services（DNS SRV）」

で定義されています。RFC は SRV レコード（DNS タイプコード 33）のフォー

マットを次のように定義しています。

_service._protocol.name ttl class SRV priority weight port target

クライアントがサービスを解決してホストに戻せるように、必ず SRV レコー

ドのターゲットに関連付けられた A レコードが存在している必要があります。

SRV レコードを Windows 2000 に実装すると、レコードは次のように表示され

ることがあります。

myserver.example.com A 10.100.200.11_ldap._tcp.example.com SRV 0 0 389 myserver.example.com_kdc._tcp.example.com SRV 0 0 88 myserver.example.com_ldap._tcp.dc_msdcs.example.com SRV 0 0 88 myserver.example.com

サービス名とプロトコル名の先頭には必ずアンダースコア（_）が付きます。こ

の例では、_kdc は Kerberos Data Center です。優先度と重みによって、同じサー

ビスを提供するターゲットサーバ間での選択が容易になります（重みは優先度

が同じ場合の判断基準です）。優先度と重みがゼロの場合、リスト表示された

順に優先度が決定されます。Windows 2000 ドメインコントローラは、これら

の SRV レコードを DNS に自動的に配置します。

SRV レコードの

使用方法

Windows 2000 クライアントが起動されると、ネットワークログインプロセス

を開始してその Windows 2000 ドメインコントローラに対して認証しようとし

ます。クライアントはまずドメインコントローラを検出する必要があります。

これはダイナミックに生成された SRV レコードを使用して行われます。

net-login プロセスを起動する前に、クライアントは _ldap._tcp.dc_msdcs.example.

com などのサービス名で DNS を照会します。DNS サーバ SRV レコードター

ゲットは、たとえば、my-domain-controller.example.com です。その後 Windows

2000 クライアントはホスト名 my-domain-controller.example.com で DNS を照会

します。DNS はホストアドレスを返し、クライアントはこのアドレスを使用

してドメインコントローラを検索します。これらの SRV レコードがないと、

net-login プロセスは失敗します。

ダイナミック

DNS アップデー

ト

Windows 2000 サーバがドメインコントローラとして設定されている場合は、

Active Directory 管理コンソールを使用して管理するドメインの名前をスタ

ティックに設定します。この Windows 2000 ドメインコントローラには、これ

に関連付けられた対応する DNS ゾーンがあります。ドメインコントローラに

はまた、その TCP/IP プロパティコントロールパネルに設定された一連の DNS

リゾルバもあります。


OL-4363-01-J



Windows 2000 ドメインコントローラがそのサービスを DNS にダイナミックに登録して、サービス

をネットワークにアドバタイズできるように、Network Registrar DNS サーバを設定できます。この

プロセスは RFC 準拠のダイナミック DNS アップデートを使用して行われるので、Network Registrar

で通常でないことを何も行う必要はありません。

ダイナミック SRV レコードアップデートを受け入れるように Network Registrar を設定するには、次

の手順で行います。

ステップ 1 DNS によってサービスをアドバタイズする必要のあるネットワーク内のデバイスの IP アドレスを

決定します。

ステップ 2 存在しない場合は、Windows 2000 ドメインの適切な順ゾーンおよび逆ゾーンを作成します。

ステップ 3 順ゾーンおよび逆ゾーンのダイナミック DNS アップデートをイネーブルにします。

ステップ 4 ゾーンの update-acl アトリビュートの値を設定して、ダイナミックアップデートを受け入れること

を制限するホストの IP アドレスを定義します。これらは通常は DHCP サーバとすべての Windows

2000 ドメインコントローラです（Windows 2000 ドメインコントローラには、スタティック IP ア

ドレスが必要です）。

DNS サーバがアップデートを受け入れる必要のある先のすべての IP アドレスの一覧を入力するこ

とが実際的でないかまたは不可能な場合は、アドレス範囲からアップデートを受け入れるように

Network Registrar を設定できます。ただし、この設定はお勧めしません。

ステップ 5 DNS サーバと DHCP サーバをリロードします。

Windows 2000 ドメインコントローラが起動されると、次の手順を実行してそ

れ自身を DNS に登録し、ネットワークにそのサービスをアドバタイズします。

1. DNS を照会して、その Windows 2000 ドメインを大部分厳密にカプセル化

している DNS ドメインの start of authority（SOA）レコードを探します。

2. その Windows 2000 ドメイン名を大部分厳密にカプセル化している DNSゾーン（SOA レコードから）のプライマリ DNS サーバを特定します。

3. RFC 2136 ダイナミック DNS アップデートプロトコルを使用して、この

ゾーンに一連の SRV レコードを作成します。

サーバ起動プロ

セスのログファ

イル例

通常の操作条件では、Windows 2000 ドメインコントローラが起動されてその

SRV レコードを作成するときに、Network Registrar プライマリ DNS サーバが次

のログエントリを書き込みます。

data time name/dns/1 Activity Protocol 0 Added type 33 record to name “_ldap._tcp.w2k.example.com”, zone “w2k.example.com”

data time name/dns/1 Activity Protocol 0 Update of zone “w2k.example.com” from address [10.100.200.2] succeeded.

このログは、1 SRV レコードについて 1 ダイナミック DNS アップデートのみ

を示します。Windows 2000 ドメインコントローラは、起動したときに 17 レ

コードの SRV を通常は登録します。

表 15-4 Windows 2000 SRV レコードとダイナミック DNS アップデート（続き）

機能説明


OL-4363-01-J



推奨の Windows 2000 デザインプラクティス

ほとんどの Windows 2000 配置は、Windows NT 4.0 環境からの移行です。既存の Windows NT 4.0 ド

メイン構造は、できる限り保存することをお勧めします。次の規則と推奨事項により、Windows

2000 の配置がさらに管理しやすくなります。

Windows 2000 の規則と推奨事項

Windows 2000 環境についての次の規則と推奨事項を考慮します。

• Windows 2000 ドメインは、DNS ホスト名の命名規則に違反してはなりません。

• すべての Windows 2000 ドメインコントローラの IP アドレスをスタティックに設定します。

• 既存の Windows NT 4.0 ドメイン名を、DNS 命名規則に対応するように変更します。

• 必要であれば、Windows 2000 ドメイン用の新しい DNS ゾーンを作成します（w2k.example.comsubzone や local.w2k.example.com ドメインなど）。

• クライアントがダイナミックにゾーンをアップデートできないようにします。代わりに、DHCPサーバがすべてのダイナミック DNS アップデートの責任を持つように DHCP サーバを設定し

ます。

Windows 2000 ドメインの命名規則

Windows 2000 ドメインスペースは DNS ネームスペースと重複するので、特定の命名制限が

Windows 2000 ドメインに適用されます。RFC 1035 の 2.3.1（「Domain Names Implementation and

Specification」）にホスト名とドメイン名の命名規則が定義されています。DNS への依存のため、こ

れらの命名規則が Windows 2000 ドメインに適用されます。

• DNS のホスト名とドメイン名は大文字小文字を区別しません。

• ホスト名は、次のとおりでなければなりません。

－文字で始まる。

－文字または数字で終わる。

－内部には、文字、数字、またはハイフンを含む。

したがって、Windows NT 4.0 ドメイン名に一般的に使用されている多くの文字が Windows 2000 ド

メイン名には使用できません。Windows 2000 ドメイン名に使用できない文字には、アンダースコア

（_）、アットマーク（@）、アンパサンド（&）があり、これらは Windows NT 4.0 ドメイン名に一般

的に使用されています。また、大文字小文字を組み合わせたドメイン名も役に立たなくなります。

たとえば、Windows 2000 は ExampleDomain を exampledomain と同じに認識します。


OL-4363-01-J



Windows 2000 環境に関連する問題

表 15-5 で、Windows 2000 と Network Registrar との相互運用性に関する問題を説明します。これは

現場で遭遇する前に可能な問題を知っておくことを意図しています。Windows 2000 相互運用性につ

いての FAQ については、P.15-23 の「Windows 2000 統合についての FAQ」を参照してください。

表 15-5 Windows 2000 と Network Registrar の相互運用性に関する問題

問題説明

ダイナミックに

作成されたリ

ソースレコード

が表示できない

Network Registrar は、適切に設定されていると、DHCP サーバと Windows 2000

サーバの両方からダイナミック DNS を受け入れます。CLI を使用して、DNS

ゾーンのダイナミック部分にアクセスしてレコードを表示および削除できま

す。次のコマンドを入力して、指定したゾーンのすべてのダイナミック DNS リ

ソースレコードを表示します。

nrcmd> zone myzone listRR dynamic myfile

これにより出力が myfile ファイルにリダイレクトされます（例 15-1（P.15-23）

を参照）。

ダイナミックに生成されたレコードは、次のコマンドを入力して削除できます。

nrcmd> zone myzone removeDynRR myname [type]

また、nslookup を使用してそれが存在することも確認でき、またバージョン 5.x

（Windows 2000 とともに出荷）を使用してダイナミック SRV レコードを表示す

ることもできます。このバージョンでは、set type=SRV コマンドを使用して、

SRV レコードの表示をイネーブルにします。

ドメインコント

ローラの登録

Windows 2000 ドメインコントローラは、ダイナミック DNS アップデートを使

用してそれ自身を DNS に登録する必要があります。DNS RFC では、特定のゾー

ンのプライマリ DNS サーバのみがゾーンデータの編集を受け入れることがで

きると規定しています。したがって、Windows 2000 ドメインコントローラは

Windows 2000 ドメイン名を含むゾーンのプライマリ DNS サーバはどれである

かを検出する必要があります。

ドメインコントローラはこれを検出するために、リゾルバリスト（TCP/IP プ

ロパティコントロールパネルに設定されている）内の最初の DNS サーバを照

会します。最初の照会は、ドメインコントローラの Windows 2000 ドメインを

含むゾーンの SOA レコードを見つける照会です。SOA レコードには、ゾーン

のプライマリサーバの名前が含まれています。そのドメイン名のゾーンが存在

しない場合、ドメインコントローラはそのドメインに含まれるプライマリサー

バを持つ SOA レコードを見つけるまで、ドメイン名の左端のラベルを除去して

照会を送信することを続けます。ドメインコントローラがそのドメインのプラ

イマリ DNS サーバの名前を見つけると、DNS アップデートを送信して必要な

SRV レコードを作成します。

ゾーンのプライマリ DNS サーバの名前が、その SOA レコードに存在すること

を確認してください。


OL-4363-01-J



A レコードダイ

ナミック DNS

アップデートの

失敗

Windows 2000 ドメインコントローラがそれ自身をネットワークにアドバタイ

ズする場合、そのドメインのレコードの DNS サーバに複数のダイナミック DNS

サーバを送信します。これらのアップデート要求のほとんどは、SRV レコード

に関してです。しかしドメインコントローラはまた、Windows 2000 ドメインと

同じ名前の 1 つの A レコードのアップデートも要求します。

Network Registrar DNS サーバがまたこの Windows 2000 ドメインに対してと同

一のゾーンの権限も持っている場合は、ダイナミック DNS A レコードアップ

デートはスタティック SOA レコードおよび NS レコードと競合するために、A

レコードの登録を拒否します。これは、ダイナミックホストのそれ自身の登録

やサイトへの Web トラフィックのスプーフィングなどの、セキュリティ違反行

為の可能性を防止するためです。

たとえば、ドメインコントローラが w2k.example.com Windows 2000 ゾーンをコ

ントロールすることがあります。同じ名前のゾーンが Network Registrar DNS

サーバ上に存在すると、次のリソースレコードがそのゾーンの一部となること

があります。

w2k.example.com. 43200 SOA nameserver.example.com. hostmaster.example.com.(

98011312 ;serial3600 ;refresh3600 ;retry3600000 ;expire43200 ) ;minim

w2k.example.com.86400 NS nameserver.example.com

ドメインコントローラは、次のような追加レコードを追加しようとします。

w2k.example.com. 86400 A 192.168.2.1

Network Registrar はダイナミック DNS アップデートでゾーン内のスタティック

に設定された名前と競合することは、その名前に関連付けられたレコードタイ

プが異なっていても、許可しません。上記の例では、名前 w2k.example.com に

関連付けられた A レコードの追加は SOA レコードおよび NS レコードと競合

します。

表 15-5 Windows 2000 と Network Registrar の相互運用性に関する問題（続き）

問題説明


OL-4363-01-J



ドメインコントローラが起動されると、次のような DNS ログファイルエント

リが表示されます。

08/10/2000 16:35:33 name/dns/1 Info Protocol 0 Error - REFUSED - Update of static name “w2k.example.com”, from address [10.100.200.2]

これがスタティック DNS データのダイナミックアップデートに対する

Network Registrar の対応方法です。さらに、このダイナミック DNS アップデー

トの失敗は無視できます。Windows クライアントはこの A レコードを使用しま

せん。ドメインコンローラの割り当ては、SRV レコードを使用して行われま

す。Microsoft は、SRV レコードをサポートしない古い NT クライアントに対応

するために A レコードを追加しました。

コントローラの A レコードの登録に失敗するとドメインコントローラの起動

プロセスが低速になって、ユーザの全体ログインに影響することに注意してく

ださい。前述のように、対応策は権限を持つゾーンのサブドメインとして

Windows 2000 ドメインを定義するか、または DNS サーバの fake-ip-name-

response アトリビュートを使用することです。これが可能でない場合は、Cisco

Technical Assistance Center に連絡してください。

Windows 2000

RC1 DHCP クラ

イアント

Microsoft がリリースした Windows 2000 ビルド 2072（RC1 と呼ばれる）は、

DHCP クライアントが壊れています。このクライアントは Network Registrar が

解析できない変形したパケットを送信します。Network Registrar はそのパケッ

トをドロップしてクライアントを処理できず、次のエラーをログに記録します。

08/10/2000 14:56:23 name/dhcp/1 Activity Protocol 0 10.0.0.15 Lease offered to Host:'My-Computer' CID: 01:00:a0:24:1a:b0:d8 packet'R15' until True, 10 Aug 2000 14:58:23 -0400. 301 ms.

08/10/2000 14:56:23 name/dhcp/1 Warning Protocol 0 Unable to find necessary Client information in packet from MAC address:'1,6,00:d0:ba:d3:bd:3b'. Packet dropped!

Network Registrar には、特にこのような不適切にビルドされた FQDN オプショ

ンなどに対処することを目的としたエラーチェック機能が含まれています。し

かし、この問題が発生した場合は、RC1 クライアントの Microsoft パッチを

DHCP クライアントにインストールしてください。このパッチは Microsoft から

入手してください。


問題説明


OL-4363-01-J



Windows 2000 プ

ラグアンドプレ

イネットワーク

インターフェイ

スカード（NIC）

コンフィギュ

レーション

DHCP を使用するように設定されると、Windows 2000 システムは起動時に

DHCP リースを取得しようとします。DHCP サーバが使用できない場合、

Windows 2000 はコンピュータのインターフェイスをプラグアンドプレイ IP ア

ドレスで自動的に設定する場合があります。このアドレスは、ネットワーク管

理者や DHCP サーバが設定または選択したアドレスではありません。

これらのプラグアンドプレイアドレスは 169.254.0.0/16 の範囲内です。これは、

ネットワーク上のこのアドレス範囲内のデバイスを参照する場合、Windows

2000 は DHCP サーバからリースを取得できなかったので、インターフェイスを

自動設定したことを意味します。

これは、ネットワークおよびトラブルシューティングに重大な問題を発生させ

ることがあります。Windows 2000 システムは、DHCP クライアントがリースを

取得できなかったことをユーザに通知しなくなりました。すべて通常とおりに

機能しているように見えますが、クライアントはローカルサブネットからパ

ケットをルーティングできません。さらに、DHCP クライアントが 169.254.0.0/16

ネットワークのアドレスを持つネットワークで処理しようとしているのが分か

ります。これによって、Network Registrar DHCP サーバは壊れていて、間違った

アドレスを渡しているとユーザが判断することがあります。

この問題が発生したら、次の手順を実行します。

1. DHCP クライアントにアクティブなネットワークポートがあり、NIC が適

切に構成されていることを確認します。

2. クライアントと DHCP サーバ間のネットワークが適切に設定されているこ

とを確認します。すべてのルータインターフェイスが正しい IPHelper アド

レスで設定されていることを確認します。

3. DHCP クライアントを再起動します。

4. 必要であれば、DHCP ログファイルを参照します。DHCP クライアントが

パケットをサーバに正常にルーティングできると、Network Registrar がパ

ケットに応答しなくても、DHCPDISCOVER をログに記録します。

ネットワークが適切に設定され、DHCP クライアントが壊れていない場合、

Network Registrar はパケットを受信して、ログに記録します。パケット受信の

ログエントリがない場合は、ネットワーク内のいずれかで問題があります。

Windows 2000 ク

ライアントアド

レスレコードの

清掃

Windows 2000 クライアントはそれ自身を清掃しないので、そのダイナミックレ

コード登録が無限に残る可能性があります。このことは、古いアドレスが DNS

サーバ上に残ります。これらの古いレコードを定期的に削除するには、ゾーン

の清掃をイネーブルにする必要があります（P.15-10 の「ダイナミックレコー

ドの清掃」を参照）。


問題説明


OL-4363-01-J



例 15-1 表示されないダイナミックに作成されたリソースレコードを示す出力

Dynamic Resource Records_ldap._tcp.test-lab._sites 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com._ldap._tcp.test-lab._sites.gc._msdcs 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com._kerberos._tcp.test-lab._sites.dc._msdcs 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com._ldap._tcp.test-lab._sites.dc._msdcs 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com._ldap._tcp 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com._kerberos._tcp.test-lab._sites 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com._ldap._tcp.pdc._msdcs 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com._ldap._tcp.gc._msdcs 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com._ldap._tcp.1ca176bc-86bf-46f1-8a0f-235ab891bcd2.domains._msdcs 600 IN SRV 0 100 389

CNR-MKT-1.w2k.example.com.e5b0e667-27c8-44f7-bd76-6b8385c74bd7._msdcs 600 IN CNAME CNR-MKT-1.w2k.example.com._kerberos._tcp.dc._msdcs 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com._ldap._tcp.dc._msdcs 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com._kerberos._tcp 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com._gc._tcp 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com._kerberos._udp 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com._kpasswd._tcp 600 IN SRV 0 100 464 CNR-MKT-1.w2k.example.com._kpasswd._udp 600 IN SRV 0 100 464 CNR-MKT-1.w2k.example.com.gc._msdcs 600 IN A 10.100.200.2_gc._tcp.test-lab._sites 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com.

Windows 2000 統合についての FAQ

次の質問は、Network Registrar DNS サーバと Windows 2000 との統合についてのよく寄せられる質

問です。

Q. Windows 2000 クライアントと DHCP サーバの両方が同じゾーンのアップデートを許可されると、どうなりますか ? これによって古い DNS レコードがゾーンに残ることがありますか ? 残る場合は、どうすればよいですか ?

A. お勧めするのは、Windows 2000 クライアントがゾーンをアップデートできないようにすることです。これに代わり、DHCP サーバですべてのクライアントのダイナミック RR レコードを管理します。ダイナミック DNS アップデートを実行するように設定されていると、DHCP サーバはリースをサービスする対象のクライアントに関連付けされたすべてのリソースレコードを正確に管理します。対照的に、Windows 2000 クライアントマシンは日常のダイナミック DNS アップデートをやみくもにサーバに送信し、ネットワークから削除されるときに古い DNS エントリを後に残します。

ダイナミック DNS アップデートクライアントによりアップデートされるゾーンはすべて、

DNS 清掃をイネーブルにして、一時的な Windows 2000 クライアントによって残された古いリ

ソースレコードの残存期間を短縮します。DHCP サーバと Windows 2000 クライアントの両方

が同じゾーンをアップデートする場合、Network Registrar に次の 3 つのことが必要です。

a. ゾーンの清掃をイネーブルにする。

b. 各クライアントがリースを更新するときに、ダイナミック DNS アップデートエントリを

リフレッシュするように DHCP サーバを設定する。デフォルトでは、Network Registrar は作成と最終の削除の間に DNS レコードを再アップデートしません。Network Registrar が作

成するダイナミック DNS アップデートレコードは、リースの開始からリースの有効期限

切れまで存続します。DHCP サーバアトリビュート force-dns-updates を使用して、この動

作を変更できます。設定例を次に示します。

nrcmd> dhcp enable force-dns-updates 100 Ok force-dns-updates=true

c. 特定のゾーンで清掃がイネーブルの場合、DHCP サーバがそのためにゾーンをアップデー

トするクライアントに関連付けられたリース時間は no-refresh-interval と refresh-interval 清掃設定の合計時間未満でなければならない。この設定のデフォルトは、両方とも 7 日間で

す。このデフォルト値を変更しない場合は、リース時間を 14 日以下に設定できます。


OL-4363-01-J



Q. Windows 2000 ドメインと既存の DNS ドメインの命名構造を統合するのに、DNS と Windows2000 ドメインを重複しないように決定した場合、何を行う必要がありますか ? たとえば、example.com と呼ばれる既存の DNS ドメインがあり、w2k.example.com と呼ばれる Windows2000 ドメインを作成する場合、Windows 2000 ドメインと DNS ドメインを統合するのに、何を行う必要がありますか ?

A. 例では、Windows 2000 ドメインフォレストのツリーには、ルート w2k.example.com があります。example.com という名前の DNS ドメインがあります。この DNS ドメインはゾーン名example.com で表されます。このゾーンで表される DNS サブドメインが追加されることがありますが、サブドメインはこのゾーンからその独自のゾーンに委任されたことはありません。サブドメインはすべて、常に example.com ゾーンに存在します。

Q. この場合、ドメインコントローラからのダイナミック DNS アップデートはどのように処理されますか ?

A. Windows 2000 ドメインコントローラからの SRV レコードアップデートを処理するには、example.com ゾーンに対するダイナミック DNS アップデートを IP アドレスのみによってドメインコントローラに制限します（後で、DHCP サーバの IP アドレスをリストに追加します）。ゾーンでの清掃をイネーブルにします。コントローラは、example.com ゾーン内の w2k.example.comサブドメインの SRV および A レコードをアップデートします。各ドメインコントローラからのA レコードアップデートを処理するための特別な設定は必要ありません。それは、w2k.example.comの A レコードは example.com ゾーン内の SOA、NS、または他のすべてのスタティックレコードと競合しないからです。

example.com ゾーンは、その後次のレコードを組み込みます。

example.com. 43200 SOA ns.example.com. hostmaster.example.com. (98011312 ;serial3600 ;refresh3600 ;retry3600000 ;expire43200 ) ;minimum

example.com.86400 NS ns.example.comns.example.com. 86400 A 10.0.0.10_ldap._tcp.w2k.example.com. IN SRV 0 0 389 dc1.w2k.example.comw2k.example.com 86400 A 10.0.0.25...

Q. この場合、個々の Windows 2000 クライアントマシンからのゾーンアップデートはどのように処理されますか ?

A. このケースでは、クライアントは w2k.example.com へのアップデートで、example.com ゾーンにアップデートしようとします。これを回避する方法は、信頼されるソースから以外のアップデートに対してゾーンを閉じる方法です。Network Registrar 6.0 より前では、DNS サーバは IP アドレスのみで DHCP サーバからのアップデートを受け入れるように設定されています。NetworkRegistrar 6.0 では、example.com ゾーンについて DHCP サーバとプライマリ DNS サーバ間にtransaction signatures（TSIG）を使用できます。

example.com ゾーンと各クライントの適切な逆ゾーンにダイナミック DNS アップデートを行う

ように DHCP サーバを設定し、オプション 81 を使用して、クライアントが自分自身にダイナ

ミック DNS アップデートを行わないようにします。

Q. この場合、セキュリティは対処されていますか ?

A. 信頼される IP アドレスからのアップデートのみを受け入れるように順ゾーンおよび逆ゾーンを設定すると、ネットワーク上の他のすべてのデバイスからのアップデートに対してゾーンを閉じます。IP によるセキュリティは最も理想的な解決策ではありません。スプーフィングされた IPアドレスソースからの悪意ある攻撃を防止しません。DHCP サーバと DNS サーバ間に TSIG を設定すると、DHCP サーバからのアップデートを保護できます。

Q. この場合、清掃は必要ですか ?

A. いいえ。ドメインコントローラと DHCP サーバからのアップデートのみ受け入れられます。DHCP サーバは追加するレコードのライフサイクルを正確に維持し、清掃は必要ありません。Network Registrar のシングルレコードダイナミックリソースレコード削除機能を使用すると、ドメインコントローラのダイナミックエントリを手動で管理できます。


OL-4363-01-J



Q. ネームスペースを共有する Windows 2000 ドメインを DNS ドメインと統合するには、何を行う必要がありますか ? たとえば、example.com と呼ばれる既存の DNS ゾーンがあり、example.comと呼ばれる Windows 2000 Active Directory ドメインを配置する必要がある場合、どうすればよいですか ?

A. この例では、Windows 2000 ドメインフォレストのツリーにルート example.com があります。また、example.com という名前のゾーンで表される example.com という名前の既存のゾーンもあります。

Q. この場合、個々の Windows 2000 クライアントマシンからのダイナミック DNS アップデートはどのように処理されますか ?

A. SRV レコードアップデートを処理するには、次のサブゾーンを作成します。

_tcp.example.com._sites.example.com._msdcs.example.com._msdcs.example.com._udp.example.com.

これらのゾーンに対するダイナミック DNS アップデートを IP アドレスのみによってドメイン

コントローラに制限します。これらのゾーンでの清掃をイネーブルにします。

各ドメインコントローラからの A レコードアップデートを処理するには、DNS サーバアトリ

ビュート simulate-zone-top-dynupdate をイネーブルにします。

nrcmd> dns enable simulate-zone-top-dynupdate

必須ではありませんが、必要であれば、ドメインコントローラの A レコードを example.comゾーンに手動で追加します。

Q. この場合、個々の Windows 2000 クライアントマシンからのゾーンアップデートはどのように処理されますか ?

A. このケースでは、クライアントは潜在的に example.com ゾーンをアップデートしようとします。これを回避する方法は、信頼されるソースから以外のアップデートに対してゾーンを閉じる方法です。Network Registrar 6.0 より前では、DNS サーバは IP アドレスのみで DHCP サーバからのアップデートを受け入れるように設定されています。Network Registrar 6.0 では、example.comゾーンについて DHCP サーバとプライマリ DNS サーバ間に transaction signatures（TSIG）を使用できます。

example.com ゾーンと各クライントの適切な逆ゾーンにダイナミック DNS アップデートを行う

ように DHCP サーバを設定し、オプション 81 を使用して、クライアントが自分自身にダイナ

ミック DNS アップデートを行わないようにします。

Q. この場合、セキュリティは対処されていますか ?

A. 信頼される IP アドレスからのアップデートのみを受け入れるように順ゾーンおよび逆ゾーンを設定すると、ネットワーク上の他のすべてのデバイスからのアップデートに対してゾーンを閉じます。IP によるセキュリティは最も理想的な解決策ではありません。スプーフィングされた IPアドレスソースからの悪意ある攻撃を防止しません。DHCP サーバと DNS サーバ間に TSIG が設定されると、DHCP サーバからのアップデートがよりセキュアになります。

Q. この場合、清掃は対処されていますか ?

A. はい。サブゾーンの _tcp.example.com、_sites.example.com、_msdcs.example.com、_msdcs.example.com、および _udp.example.com ゾーンはドメインコントローラからのみのアップデートを受け入れ、これらのゾーンについての清掃はオンになっています。example.com ゾーンは、DHCPサーバからのみのダイナミック DNS アップデートを受け入れます。


OL-4363-01-J




OL-4363-01-J

Documents

ダイナミック DNS アップデートの設定 - Cisco · 2012-02-24 · ダイナミック dns アップデートは、dns を dhcp と統合します。2 つのプロトコルは、補完関係