Cisco CNS Network Registrar Release 6.2 ユーザ ガイド
DNS アップデートの設定
DNS アップデートの設定
発行日;2012/02/01 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

DNS アップデートの設定

DNS アップデートの手順

特別な考慮事項

DHCP 用の DNS アップデート設定の作成

DNS 用の DNS アップデート マップの作成

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

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

アクセス コントロール リストに対するゾーンの設定

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

TSIG キーの作成

キーの生成

キーの管理の考慮事項

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

DNS アップデート ポリシーの設定

以前の リリースとの互換性

アップデート ポリシーの作成

アップデート ポリシーのルールの定義と適用

名前付きアップデート ポリシーに対するルールの定義

アップデート ポリシーのゾーンへの適用

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

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

DNS アップデートのトラブルシューティング

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

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

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

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

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

SRV レコードと DNS アップデート

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

Windows の規則と推奨事項

Windows ドメインの命名規則

Windows 環境に関連する問題

Windows 統合についての FAQ

DNS アップデートの設定

DNS アップデート プロトコル(RFC 2136)は、DNS と DHCP を統合するものです。2 つのプロトコル(DNS と DHCP)は、補完関係にあります。DHCP は IP アドレスの割り振りを集中的に管理し、自動化します。DNS は割り当てられたアドレスとホスト名との間の関連付けを自動的に記録します。DHCP と DNS アップデートを利用することで、ホストのネットワークのための設定は、IP ネットワークに接続されている限り自動的に行われます。固定的な一意の DNS ホスト名を使用して、ホストの場所を見つけてアクセスできます。たとえば、モバイル ホストはユーザまたは管理者の介入なしに、自由に移動できます。

この章では、Cisco CNS Network Registrar サーバで DNS アップデートを使用する方法と、Windows クライアント システムとの特別な関連性について説明します。

DNS アップデートの手順

DNS アップデートを設定するには、DHCP サーバ用に少なくとも 1 つの DNS アップデート設定と、DNS サーバ用に 1 つの DNS アップデート マップを作成する必要があります。また、ホスト名を指定するか、Network Registrar で生成するように要求する必要があります。DNS アップデートを設定するには、以下の手順を実行します。

1. DHCP サーバ用の DNS アップデート設定を作成する。この設定は、順ゾーンまたは逆ゾーン、またはその両方に対して作成できます。


) Network Registrar の以前のリリースは、DNS アップデート設定アトリビュートをスコープ レベルで設定します。6.2 にアップグレードする場合、アップグレード時にスコープ アトリビュートは新しい DNS アップデート設定に移行されます。


2. DHCP フェールオーバー ペア、ハイ アベイラビリティ(HA)DNS サーバ ペア、関連付けられている DNS アップデート設定を含む DNS サーバに対して、DNS アップデート マップを作成します。

3. オプションで、DNS アップデート用のアクセス コントロール リスト(ACL)または Transaction Signature(TSIG)を定義します。

4. オプションで、これらの ACL または TSIG に基づいて 1 つ以上の DNS アップデート ポリシーを作成し、ゾーンに適用します。

5. 必要に応じて、Windows クライアント用に設定を調整します(デュアル ゾーン アップデート用など)。

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

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

特別な考慮事項

DNS アップデートを設定する場合、次の 2 つの問題を考慮します。

セキュリティのため、Network Registrar の DNS アップデートのプロセスにおいては、管理者が DNS データベース内に手動で入力した名前を変更または削除することはありません。

大規模な展開で、HA DNS(「ハイ アベイラビリティ DNS サーバの設定」を参照)を使用しないで DNS アップデートをイネーブルにする場合は、プライマリ DNS サーバと DHCP サーバを複数のクラスタに分割します。DNS アップデートは、サーバに追加の負荷を与えます。

DHCP 用の DNS アップデート設定の作成

DNS アップデート設定によって、アップデート用に順ゾーンまたは逆ゾーン(または両方)を設定するかどうかを決定し、これらのゾーンを定義し、トランザクションのバックアップ DNS サーバおよび TSIG キーを設定し、その他のアトリビュートを設定するフレームワークが作成されます。次に、DNS サーバの DNS アップデート マップによって、このアップデート設定が DHCP スコープ(以後、リース)に関連付けられます。


ステップ 1 Web UI では、 DHCP をクリックしてから DNS をクリックし、List DNS Update Configurations ページを開きます。

ステップ 2 Add DNS Update Configuration をクリックして、Add DNS Update Configuration ページを開きます(図27-1 を参照)。

図27-1 Add DNS Update Configuration ページ(ローカル)

 

ステップ 3 name アトリビュート フィールドに、アップデート設定の名前を入力します。

CLI では、 dhcp-dns-update name create を使用します。例を示します。

nrcmd> dhcp-dns-update example-update-config create
 

ステップ 4 適切な dynamic-dns 設定をクリックします。

update-none:順ゾーンまたは逆ゾーンをアップデートしません。

update-all:順ゾーンおよび逆ゾーンをアップデートします(デフォルト)。

update-fwd-only:順ゾーンだけをアップデートします。

update-reverse-only:逆ゾーンだけをアップデートします。

CLI では、 dhcp-dns-update name set dynamic-dns= value を使用します。例を示します。

nrcmd> dhcp-dns-update example-update-config set dynamic-dns=update-all
 

ステップ 5 その他のアトリビュートを設定します。

a. 必要であれば、 synthesize-name をイネーブルにして、 synthetic-name-stem 値を設定します。

synthetic-name-stem を使用して、クライアントがホスト名を提供しない場合に使用するデフォルトのホスト名の基語を設定できます。その後、 synthesize-name スコープ アトリビュートをイネーブルにして、DHCP サーバが synthetic-name-stem の値に基づいてクライアントの一意な名前を合成するようにする必要があります。得られる名前は、ハイフンで区切られた IP アドレスを基語に追加した名前です。たとえば、example.com ドメイン内のアドレス 192.168.50.1 に対して synthetic-name-stem host を指定し、 synthesize-name アトリビュートをイネーブルにすると、結果として得られるホスト名は host-192-168-50-1.example.com になります。名前の基語を省略すると、設定エラーが発生します。

b. 順ゾーンをアップデートする場合は、 forward-zone-name に順ゾーンを設定します。

c. reverse-zone-name に、PTR レコードおよび TXT レコードでアップデートされる逆(in.addr.arpa)ゾーンを設定します。これはオプションで、デフォルトは順ゾーン アドレスです。設定解除されて、DHCP サーバの synthesize-reverse-zone アトリビュートがイネーブルであると、サーバは各リースのアドレス、スコープのサブネット番号、および DNS アップデート設定の(またはスコープの) dns-host-bytes アトリビュート値に基づいて逆ゾーン名を作成します。

d. server-addr に、順ゾーンの(逆ゾーンだけをアップデートする場合は、逆ゾーンの)プライマリ DNS サーバの IP アドレスを設定します。

e. TSIG キーを使用してすべての DNS アップデートを処理する場合は、 server-key および backup-server-key を設定します(「トランザクション セキュリティ」を参照)。

f. HA DNS が設定されている場合は、 backup-server-addr に、バックアップ DNS サーバの IP アドレスを設定します。

g. 必要に応じて、 update-dns-first (デフォルトではディセーブル)または update-dns-for-bootp (デフォルトではイネーブル)をイネーブルまたはディセーブルにします。 update-dns-first 設定は、リースを許可する前に DHCP が DNS をアップデートするかどうかを制御します。このアトリビュートをイネーブルにすることは推奨されません。

ステップ 6 Web UI で、 Add DNS Update Configuration をクリックします。


 

DNS 用の DNS アップデート マップの作成

DNS アップデート マップを使用すると、アップデート設定に基づいて HA DNS サーバ ペアまたは DHCP フェールオーバー サーバ ペア間でアップデート プロパティが同期化され、冗長なデータ入力が削減されるため、DNS アップデートの設定が簡単になります。アップデート マップは、DNS ペアが処理するすべてのプライマリ ゾーン、または DHCP ペアが処理するすべてのスコープに適用されます。アップデート マップのポリシーを指定する必要があります。この機能を使用するには、dns-management ロールまたは central-dns-management ロールの server-management サブロールと、dhcp-management ロール(アップデート設定用)が割り当てられている管理者になる必要があります。


ステップ 1 Web UI では、 DNS をクリックしてから Update Maps をクリックし、List DNS Update Maps ページを開きます。

ステップ 2 Add DNS Update Map をクリックして、Add DNS Update Map ページを開きます(図27-2 を参照)。

図27-2 Add DNS Update Map ページ(ローカル)

 

ステップ 3 Name フィールドに、アップデート マップの名前を入力します。

CLI では、 dns-update-map name create dhcp-cluster dns-cluster dns-config を使用してアップデート マップを作成するときに、名前、DHCP および DNS サーバ(または DHCP フェールオーバーまたは HA DNS サーバ ペア)のクラスタ、および DNS アップデート設定を指定する必要があります。次の例を参考にしてください。

nrcmd> dns-update-map example-update-map create Example-cluster Boston-cluster example-update-config
 

ステップ 4 Web UI では、前のセクションにある DNS アップデート設定を dns-config フィールドに入力します。

ステップ 5 dhcp-policy-selector アトリビュートに適用するポリシー選択の種類を設定します。選択肢は次のとおりです。

use-named-policy: dhcp-named-policy アトリビュートに設定されている名前付きポリシーを使用します(デフォルト)。

use-client-class-embedded-policy: dhcp-client-class アトリビュートに設定されているクライアントクラスの組み込みポリシーを使用します。

use-scope-embedded-policy:スコープの組み込みポリシーを使用します。

CLI では、 set メソッドを使用して、これらのアトリビュートを設定します。次の例を参考にしてください。

nrcmd> dns-update-map example-update-map set dhcp-policy-selector=use-named-policy
nrcmd> dns-update-map example-update-map set dhcp-named-policy=example-policy
 

ステップ 6 アップデート ACL または DNS アップデート ポリシーを使用する場合は、 dns-update-acl アトリビュートまたは dns-update-policy-list アトリビュートを設定します。これらの値は、1 つのアドレスまたはカンマで区切った複数のアドレスにできます。 dns-update-acl は、 dns-update-policy-list よりも優先されます。

両方の値を省略した場合、 dns-config アトリビュートで指定されているアップデート設定で設定された server-key 値を使用して、指定された DHCP サーバまたはフェールオーバー ペアだけがアップデートを実行できる単純なアップデート ACL が構築されます(DNS アップデート ポリシーについては、「DNS アップデート ポリシーの設定」を参照してください)。

ステップ 7 Web UI で、 Add DNS Update Map をクリックします。

ステップ 8 リージョナル Web UI では、List DNS Update Maps ページで、アップデート マップをローカル クラスタに適用したり、複製データベースから取得することもできます。


 

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

ACL は許可リストで、Transaction Signature(TSIG)は認証メカニズムです。

ACL は、サーバがパケットに定義された要求またはアクションを許可または拒否できるようにします。

TSIG は、DNS メッセージが信頼されるソースからのものであり、改変されていないことを保証します。

各 DNS クエリー、アップデート、保護されるゾーン転送ごとに、アクセス権制御を提供する ACL を設定する必要があります。TSIG 処理は、TSIG 情報を含むメッセージについてのみ実行されます。この情報を含まないか、または除去されたメッセージは、認証プロセスが省略されます。

まったくセキュアなソリューションでは、メッセージを同じ認証キーで許可する必要があります。たとえば、DHCP サーバが DNS アップデートのために TSIG を使用するように設定され、同じ TSIG キーがアップデートされるゾーンの ACL に含まれている場合、TSIG 情報を含まないパケットはすべて認証ステップを失敗します。これによってアップデート トランザクションが保護され、メッセージはゾーン変更を行う前に認証され、かつ許可されます。

ACL および TSIG は、サーバまたはゾーンの DNS アップデート ポリシーの設定において、「DNS アップデート ポリシーの設定」で説明する役割を果たします。

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

DNS サーバ レベルまたはゾーン レベルで ACL を割り当てます。ACL は、次の要素を 1 つまたは複数含むことができます。

IP アドレス:ドット付き 10 進形式の表記(たとえば、192.168.1.2)。

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

別の ACL:定義しておく必要があります。別の ACL に組み込まれている ACL は、組み込み関係を削除するまで削除できません。

Transaction Signature(TSIG)キー:この値は key value という形式で、キーワード key の後に秘密値を指定する必要があります。空白文字を使用するには、リスト全体を二重引用符で囲む必要があります。TSIG キーについては、「トランザクション セキュリティ」を参照してください。

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

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

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

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

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

Web UI では、 DNS をクリックしてから ACLs をクリックし、List/Add Access Control Lists ページを開きます。ACL 名と照合リストを追加します。 key value ペアを引用符で囲まないように注意してください。リージョナル Web UI では、複製 ACL を取得したり、ローカル クラスタに ACL を適用することもできます。

CLI の場合、名前と 1 つまたは複数の ACL 要素を指定して acl name create match-list を使用します。ACL リストはカンマ区切りのリストで、空白文字がある場合はリストを二重引用符で囲みます。CLI には、取得機能および適用機能はありません。

たとえば、次のコマンドでは 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
 

アクセス コントロール リストに対するゾーンの設定

DNS サーバまたはゾーン用に ACL を設定するには、DNS アップデート ポリシーを設定し、このアップデート ポリシーをゾーンに対して定義します(「DNS アップデート ポリシーの設定」を参照)。

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

Transaction Signatures(TSIG)によって 受信する各メッセージを認証するように DNS サーバをイネーブルにします。サーバ間の通信は暗号化されませんが、デジタル署名されます。この操作によりパケットのデータおよびソースの信頼性の検証ができます。

DNS アップデートのために TSIG を使用するように Network Registrar DHCP サーバを設定すると、サーバはメッセージに TSIG リソース レコード(RR)を付加します。TSIG レコードの一部はデジタル署名です。

DNS サーバはメッセージを受信すると、TSIG レコードを探します。検出すると、まずその中のキー名が認識するキーのうちの 1 つであることを検証します。その後、アップデートのタイムスタンプが妥当であることを検証します(トラフィックなりすまし攻撃に対抗するため)。最後に、サーバは、パケットで送信されたキーの共有秘密を参照して独自の署名を算出します。算出された署名がパケットに組み込まれた署名と一致すると、内容が信頼できると見なされます。

Network Registrar では、TSIG キー名が、共有秘密値と関連付けられます。キー名は、そのキーを使用するホストの名前を反映する必要があります。名前のエントリには、共有秘密も必要です。

TSIG キーの作成

Web UI で TSIG キーを作成するには、 DNS をクリックしてから Keys をクリックし、List/Add Encryption Keys ページを開きます(既存のキーについては、図27-3 を参照)。

CLI では、 key name create secret を使用します。

キーの名前(hosta-hostb-example.com などのドメイン名形式を使用)を指定し、共有秘密の最小値を base64 でエンコードされた文字列で指定します(オプションの時間差アトリビュートについては、 表27-1 を参照してください)。次に、CLI での例を示します。

nrcmd> key hosta-hostb-example.com. create secret-string
 

図27-3 List/Add Encryption Keys ページ(ローカル)

 


) Address-to-User Lookup(ATUL)サポート用にキー認証をイネーブルにするには、キー識別番号(id アトリビュート値)も定義する必要があります。「DHCP 転送の設定」を参照してください。


キーの生成

Network Registrar cnr_keygen ユーティリティを使用して TSIG キーを生成し、 import keys を使用してそれを追加またはインポートできるようにすることをお勧めします。

DOS プロンプト、あるいは Solaris または Linux のシェルから cnr_keygen キー ジェネレータ ユーティリティを実行します。

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

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

このユーティリティの使用例(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.example.com." {
algorithm hmac-md5;
secret "xGVCsFZ0/6e0N97HGF50eg==";
# cnr-time-skew 300;
# cnr-security-type TSIG;
};
 

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

 

表27-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

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

生成される秘密値は、ランダム文字列として 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 keydir/keyfile.txt
 

キーの管理の考慮事項

独自のキーを生成する場合は、base64 でエンコードされた文字列としてキーを入力する必要があります。つまり、使用できる文字は、base64 アルファベットとパディング文字の等号(=)だけです。base64 でエンコードされていない文字列を入力すると、エラー メッセージが表示されます。次に、その他の推奨事項をいくつか示します。

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

共有秘密を頻繁に変更する。2 ヶ月ごとに変更することをお勧めします。Network Registrar は、変更を明示的に強制しません。

共有秘密の長さは、少なくともキー付きメッセージ ダイジェスト(HMAC-MD5 は 16 バイト)と同じ長さである必要がある。Network Registrar は、明示的にこれを強制せず、共有秘密が base64 でエンコードされた有効な文字列であることだけを確認しますが、これは RFC 2845 によって推奨されているポリシーです。

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

DNS アップデート設定(「DHCP 用の DNS アップデート設定の作成」を参照)に TSIG サポートを追加するには、次のアトリビュートを設定します。

server-key

backup-server-key

DNS アップデート ポリシーの設定

DNS アップデート ポリシーは、RR レベルでアップデート認証を管理するメカニズムを提供します。アップデート ポリシーを使用すると、RR 名やタイプだけではなく、ACL に基づいたルールに従い、DNS アップデートを許可または拒否できます。ACL については 「アクセス コントロール リスト」を参照してください。

以前の Network Registrar リリースとの互換性

以前の Network Registrar リリースでは、管理者が入力し、DNS アップデートでは変更できないスタティック RR が使用されていました。この、スタティック RR とダイナミック RR の区別はなくなりました。現在は、RR に保護されているか、保護されていないかのマークを付けることができます(「リソース レコード セットの保護」を参照)。RR を作成または変更する管理者は、RR を保護するかどうかを指定できます。DNS アップデートは、そのタイプの RR がセットに存在しているかどうかに関係なく、保護されている RR セットを変更できません。


) 以前のリリースでは、DNS アップデートは A、TXT、PTR、CNAME、および SRV の各レコードだけで可能でした。現在は、保護されていない名前セットでは、SOA と NS 以外のすべてのレコードをアップデートできるように変更されました。以前のリリースとの互換性を維持するには、RR のアップデートを制限するアップデート ポリシーを使用します。


アップデート ポリシーの作成


ステップ 1 Web UI では、 DNS をクリックしてから Update Policies をクリックし、List DNS Update Policies ページを開きます。

ステップ 2 Add Policy をクリックして、Add DNS Update Policy ページを開きます(図27-4 を参照)。

図27-4 Add DNS Update Policies ページ(ローカル)

 

ステップ 3 アップデート ポリシーの名前を入力します。

CLI では、 update-policy name create を使用します。例を示します。

nrcmd> update-policy policy1 create
 

ステップ 4 「アップデート ポリシーのルールの定義と適用」の項に進みます。


 

アップデート ポリシーのルールの定義と適用

DNS アップデート ポリシーは、ACL に基づいて特定の RR に対するアップデートを許可または拒否するルールを定義した場合にのみ有効です。どのルールも満たされない場合、デフォルト(暗黙的な最後の)ルールはすべてのアップデートの拒否( 「deny any wildcard * *」 )になります。

名前付きアップデート ポリシーに対するルールの定義


ステップ 1 「アップデート ポリシーの作成」の説明に従い、アップデート ポリシーを作成するか、編集します。

ステップ 2 CLI では、 update-policy name rules add rule を使用します。 rule がルールです。次の例を参考にしてください。

nrcmd> update-policy policy1 rules add "grant 192.168.50.101 name host1 A,TXT" 0
 

ルールは引用符で囲みます。ルール シンタックスは、次のように解析されます。

grant :サーバが実行するアクション。 grant または deny です。

192.168.50.101 :ACL。この例では、IP アドレスです。ACL は、次のいずれかです。

名前。「アクセス コントロール リスト」で説明したように、名前で作成された ACL です。

IP アドレス。この例を参照してください。

ネットワーク アドレスとマスク。 192.168.50.0/24 などです。

TSIG キー。 key= key 形式の Transaction Signature キーです(「トランザクション セキュリティ」を参照)。

次のいずれかの予約語。

any :任意の ACL

none :ACL なし

localhost :任意のローカル ホスト アドレス

localnets :任意のローカル ネットワーク アドレス

前に感嘆符( ! )を付けることで、その ACL 値を否定できます。

name :RR で実行するチェックのキーワードまたはタイプ。次のいずれかです。

name :RR の名前。名前の値が必要です。

subdomain :RR の名前、またはサブドメインとその RR のいずれか。名前またはサブドメインの値が必要です。

wildcard :ワイルドカード値( 表27-2 を参照)による RR の名前。

host1 :キーワードに基づく値。この例では、host1 という RR です。サブドメイン名にしたり、 wildcard キーワードを使用している場合は、ワイルドカードを含めることができます( 表27-2 を参照)。

A,TXT :RR のタイプ。カンマで区切ります。 付録 A「リソース レコード」 で説明する RR タイプのリストにできます。前に感嘆符( ! )を付けることで、そのレコード タイプ値を否定できます。

このルール、または割り当てられているルールのいずれも満たされない場合、デフォルトはすべての RR アップデートの拒否です。

ルールの末尾(引用符の外側)に、インデックス番号が追加されています(この例では 0 )。インデックス番号は 0 から始まります。アップデート ポリシーに複数のルールがある場合、インデックスを使用してルールを特定の順序で追加できます。小さな番号のインデックスほど、リスト内で優先度が高くなります。ルールにインデックスが含まれていない場合、リストの末尾に置かれます。つまり、明示的に定義するかどうかにかかわらず、ルールは常にインデックスを持ちます。ルールの削除が必要になった場合も、インデックス番号を指定します。

Web UI の場合は、次の手順に従います。

a. オプションの値を Index フィールドに入力します。

b. ルールを許可する場合は Grant をクリックし、ルールを拒否する場合は Deny をクリックします。

c. アクセス コントロール リストを ACL List フィールドに入力します。

d. Keyword ドロップダウン リストからキーワードを選択します。

e. キーワードに基づく値を Value フィールドに入力します。RR またはサブドメイン名にしたり、 wildcard キーワードを使用している場合は、ワイルドカードを含めることができます( 表27-2 を参照)。

 

表27-2 アップデート ポリシー ルールのワイルドカード値

ワイルドカード
説明

*

0 個以上の文字と一致します。たとえば、パターン example* は、 example で始まるすべての文字列と一致します( example- など)。

?

単一の文字にのみ一致します。たとえば、パターン example?.com は、
example1.com example2.com と一致しますが、 example.com とは一致しません。

/[ /]

エスケープされたカッコ内の任意の文字と一致します( /[abc/] など)。角カッコは、スラッシュ( / )を使用してエスケープする必要があります。文字は、範囲にすることもできます( /[0-9/] /[a-z/] など)。パターンにハイフンを含めるには、先頭にハイフンを付けます( example/[-a-z/] など)。

f. 1 つ以上の RR タイプをカンマで区切って、RR Types フィールドに入力します。RR は、 付録 A「リソース レコード」 で説明されている任意のタイプにできます。感嘆符を前に付けることで、否定値を使用できます( !PTR など)。

g. Add Policy をクリックします。

ステップ 3 リージョナル Web UI では、List DNS Update Policies ページで、アップデート ポリシーをローカル クラスタに適用したり、複製データベースから取得することもできます。

ステップ 4 Web UI でアップデート ポリシーを編集するには、List DNS Update Policies ページでアップデート ポリシーの名前をクリックし、Edit DNS Update Policy ページを開き、フィールドを変更し、 Edit Policy をクリックします。

CLI でアップデート ポリシーを編集するには、 update-policy name delete を使用し、アップデート ポリシーを再作成します。ルールを編集するには、 update-policy name rules remove index を使用します。ここで、 index は明示的に定義された、またはシステム定義されたインデックス番号です(インデックス番号は 0 から始まることに注意してください)。次に、ルールを再作成します。前の例で、2 番目のルールを削除するには、次のように入力します。

nrcmd> update-policy policy1 rules remove 1
 


 

アップデート ポリシーのゾーンへの適用


ステップ 1 ローカル Web UI では、 DNS をクリックしてから Forward Zones をクリックし、List/Add Forward Zones ページを開きます。

ステップ 2 ゾーンの名前をクリックして、Edit Forward Zone ページを開きます。


ヒント この機能は、Edit Zone Template ページで、ゾーン テンプレートに対して実行することもできます。また、Edit Primary Reverse Zone ページで、プライマリ逆ゾーンに対して実行することもできます(「ゾーンの管理」を参照)。

CLI では、 zone name set update-policy-list を使用します。 update-policy-list アトリビュートは、「アップデート ポリシーの作成」で定義した、カンマで区切られたアップデート ポリシーのリストです。次の例を参考にしてください。

nrcmd> zone example.com set update-policy-list="policy1,policy2"
 

ステップ 3 Web UI では、1 つ以上の既存の名前付きアップデート ポリシーの名前、またはカンマで区切られた複数の名前を update-policy-list アトリビュート フィールドに入力します(サーバは
update-policy-list
を処理する前に、 update-acl を処理することに注意してください)。

ステップ 4 Web UI では、 Modify Zone をクリックします。


 

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

Network Registrar DHCP サーバは、待ち状態の DNS アップデート データをすべてディスクに格納します。DHCP サーバが DNS サーバと通信できない場合は、DHCP サーバは通信を再確立するために定期的にテストを実行し、待ち状態のアップデートをすべてサブミットします。このテストは、通常、40 秒ごとに行われます。

ダイナミック RR が DNS サーバに存在することをローカル クラスタ Web UI で確認するには、 DNS をクリックしてから Forward Zones をクリックします。RRs カラムで View アイコン( )をクリックし、List/Add DNS Server RRs for Zone ページを開きます。

CLI では、 zone name listRR dynamic を使用します。

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

DHCP リースを取得した Microsoft Windows 2003 および XP の DNS クライアントは、その Address(A)レコードを DNS サーバで直接アップデート(リフレッシュ)できます。このようなクライアントの多くはモバイル ラップトップであり、永続的に接続しているわけではないため、一部の A レコードは時間が経つと古くなります。Windows DNS サーバはこれらのプライマリ ゾーン レコードを定期的に清掃および除去します。Network Registrar には同様の機能があり、古いレコードを定期的に除去するために使用できます。

清掃は、通常、デフォルトでディセーブルですが、Windows クライアントだけを含むゾーンではイネーブルにする必要があります。ゾーンには、 no-refresh 間隔と refresh 間隔が設定されます。レコードは、最初の作成日の後、これら 2 つの間隔を過ぎると期限切れとなります。図27-5 は清掃スケジュールの間隔を示しています。

図27-5 Address レコードの清掃スケジュールの間隔

 

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

1. クライアントが新しい A レコードで DNS サーバをアップデートすると、そのレコードはタイムスタンプを取得します。または、クライアントがその A レコードをリフレッシュすると、そのレコードはタイムスタンプをアップデートできます(「レコードが作成またはリフレッシュされる」)。

2. 非リフレッシュ間隔(デフォルトでは 7 日)の間は、クライアントがアドレスを変更せずに同じレコードを送信し続ける場合、レコードのタイムスタンプはアップデートされません。

3. レコードは、非リフレッシュ間隔を過ぎると、リフレッシュ間隔(これもデフォルトでは 7 日)に入ります。この期間中、DNS アップデートはタイムスタンプをリフレッシュし、レコードは非リフレッシュ間隔に戻ります。

4. リフレッシュ間隔を過ぎて清掃間隔に到達したレコードは、清掃に使用できます。

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

scvg-interval :DNS サーバがゾーン内に古いレコードがあるかどうかを調べる期間。値の範囲は、1 時間から 365 日間です。この値はサーバにも設定できますが(デフォルトは 1 週間)、ゾーン設定が優先されます。

scvg-no-refresh-interval :ダイナミック DNS アップデートや前提条件のみの DNS アップデートなどのアクションが、レコードのタイムスタンプをアップデートしない間隔。値の範囲は、1 時間から 365 日間です。ゾーン設定がサーバ設定(デフォルトは 1 週間)よりも優先されます。

scvg-refresh-interval :DNS アップデートがレコードのタイムスタンプを増やす間隔。非リフレッシュ間隔とリフレッシュ間隔の両方が満了になると、レコードは清掃の候補となります。値の範囲は、1 時間から 365 日間です。ゾーン設定がサーバ設定(デフォルトは 1 週間)よりも優先されます。

scvg-ignore-restart-interval :サーバが、必ずしも再起動のたびに清掃時間をリセットしないようにします。この間隔内である場合、Network Registrar は、サーバがダウンしてから再起動するまでの時間(通常はかなり短い)を無視します。値の範囲は、2 時間から 1 日間です。設定した時間よりも長い時間が経過すると、Network Registrar は清掃期間を再計算し、サーバの停止中に実行できなかったレコードのアップデートを可能にします。ゾーン設定がサーバ設定(デフォルトは 2 時間)よりも優先されます。

Network Registrar DNS サーバが Windows クライアント(または定期的な自動 DNS アップデートを行うことが知られているクライアント)だけからアップデートを受け取るゾーンに対してのみ、清掃をイネーブルにします。上に一覧表示したアトリビュートを設定します。Network Registrar 清掃マネージャは、サーバの起動時に起動します。清掃で除去されたレコードを変更セット データベースに報告します。Network Registrar はまた、プライマリ ゾーンから清掃されたすべてのレコードのゾーン転送のためにセカンダリ ゾーンに通知します。清掃がディセーブルな(レコードがタイムスタンプを持たない)ゾーンを作成し、後で清掃をイネーブルにした場合、Network Registrar は、各レコードのデフォルト タイプスタンプとして、プロキシ タイムスタンプを使用します。

ローカル クラスタ Web UI でゾーン清掃を強制的に実行するには、Manage DNS Server ページの Commands カラムにある Run アイコン( )をクリックし、DNS Server Commands ページを開きます(図6-3 を参照)。このページで、Scavenge all zones の横の Run アイコンをクリックします。

特定の順ゾーンまたは逆ゾーンのみを清掃するには、List/Add Zones ページまたは List/Add Reverse Zones ページで Run アイコン( )をクリックし、Zone Commands for Zone ページを開きます。Zone Commands for Zone ページで、Scavenge zone の横の Run アイコンをもう一度クリックします。ゾーンに対してスケジュールされている次回の清掃を調べるには、Get scavenge start time の横の Run アイコンをクリックします。

CLI では、清掃がイネーブルになっているすべてのゾーンで清掃を実行する場合は、 dns scavenge を使用します。清掃がイネーブルになっている特定のゾーンで清掃を実行する場合は、 zone name scavenge を使用します。次回の清掃の開始がスケジュールされている時刻を調べるには、ゾーンで getScavengeStartTime アクションを使用します。

1 つまたは複数のログ設定、scavenge、scavenge-details、ddns-refreshes、および ddns-refreshes-details を使用して清掃アクティビティを監視できます。

DNS アップデートのトラブルシューティング

dig nslookup などの標準 DNS ツールを使用すると、サーバに RR を照会できます。このツールは、ダイナミックに生成された RR が存在するかどうかを判別するために役立ちます。次の例を参考にしてください。

$ 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 を設定するとより詳細に表示できます。

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

Windows 2003 および XP オペレーティング システムは、DNS に大きく依存し、DHCP にはあまり依存しません。以前の Windows バージョンのこの依存関係は大幅に変更され、ネットワーク管理者は広範囲の Windows 展開を行う前に入念に準備する必要があります。Windows クライアントは、そのアドレス(A)レコードで順ゾーンを直接アップデートして、それ自身のエントリを DNS に追加できます。しかし、そのポインタ(PTR)レコードで逆ゾーンをアップデートすることはできません。

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

クライアントが DNS を直接アップデートできるよう許可することは推奨しません(「推奨の Windows デザイン プラクティス」を参照)。

Windows クライアントがアドレス レコードのアップデートを DNS サーバに送信するには、次の 2 つの条件が満たされている必要があります。

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

DHCP ポリシーが直接のアップデートをイネーブルにしていること(Network Registrar ポリシーはデフォルトでこれを行っています)

Windows クライアントは、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 アップデートがイネーブルであるかディセーブルであるかは関係ありません。設定する各種プロパティに基づいて実行されるアクションについては、 表27-3 を参照してください。

 

表27-3 Windows クライアントの 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 レコードをアップデートする。

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 で応答せず、DNS サーバをアップデートしない。

client-fqdn を送信しない。

イネーブル

client-fqdn で応答しないが、A および PTR レコードはアップデートする。

 

ディセーブル

client-fqdn で応答せず、DNS サーバをアップデートしない。

Windows DHCP サーバは、クライアントの要求を無視するように client-fqdn オプションを設定できます。Network Registrar でこの動作をイネーブルにするには、Windows クライアントのポリシーを作成して、このポリシーの 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 レコードをアップデートします。

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

 

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

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

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 =false

host-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

指定された synthetic-name-stem の後ろにハイフンで区切られたホストの IP アドレスを追加する、という合成ルールに従って合成されます。

 

(次を除いて前と同じ)
synthesize-name =false

未定義。

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

Windows 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 クライアントでの DNS アップデート設定

Windows クライアントで詳細プロパティを設定し、 client-fqdn オプションの送信をイネーブルにすることができます。


ステップ 1 Windows クライアントで、Control Panel に移動して、TCP/IP Settings ダイアログボックスを開きます。

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

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

ステップ 4 クライアントが要求において client-fqdn オプションを送信できるようにするには、 Register this
connection's addresses in DNS
ボックスをオンのままにしておきます。これは、クライアントが A レコードのアップデートを実行するということを示します。


 

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

Windows クライアントを含むスコープに対して関連ポリシーを適用し、スコープに対する DNS アップデートをイネーブルにすることができます。


ステップ 1 Windows クライアントを含むスコープに対するポリシーを作成します。次の例を参考にしてください。

a. policywin2k を作成します。

b. サブネット 192.168.1.0/24 とポリシーとして policywin2k を持つ win2k スコープを作成します。192.168.1.10 ~ 192.168.1.100 のアドレス範囲を追加します。

ステップ 2 スコープ アトリビュート dynamic-dns に update-all、update-fwd-only、または update-rev-only を設定します。

ステップ 3 「DHCP 用の 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 レコードのアップデートを行います(「Windows クライアントのデュアル ゾーン アップデート」を参照)。

use-dns-prereqs がイネーブルで update-dns-first がディセーブルの場合、クライアントに返されるホスト名と client-fqdn は、名前の明確化の遅れのために、DNS アップデートと一致することは保証されませんが、リース データは新しい名前でアップデートされます。

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


 

SRV レコードと DNS アップデート

Windows は、ネットワークへのサービスのアドバタイズに関して DNS プロトコルに大きく依存しています。 表27-5 で、Windows が service location(SRV)DNS RR と DNS アップデートを処理する方法を説明します。

 

表27-5 Windows の SRV レコードと DNS アップデート

機能
説明

SRV レコード

Windows ドメイン コントローラは、SRV RR を使用して、そのサービスをネットワークにアドバタイズします。この RR は、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 に実装すると、レコードは次のように表示されることがあります。

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 ドメイン コントローラは、これらの SRV レコードを DNS に自動的に配置します。

SRV レコードの使用方法

Windows クライアントが起動されると、ネットワーク ログイン プロセスを開始してその Windows ドメイン コントローラに対して認証しようとします。クライアントはまずドメイン コントローラを検出する必要があります。これはダイナミックに生成された SRV レコードを使用して行われます。

net-login プロセスを起動する前に、クライアントは
_ldap._tcp.dc_msdcs.example.com などのサービス名で DNS を照会します。DNS サーバ SRV レコード ターゲットは、たとえば、
my-domain-controller.example.com です。その後 Windows クライアントはホスト名 my-domain-controller.example.com で DNS を照会します。DNS はホスト アドレスを返し、クライアントはこのアドレスを使用してドメイン コントローラを検索します。これらの SRV レコードがないと、net-login プロセスは失敗します。

DNS アップデート

Windows サーバがドメイン コントローラとして設定されている場合は、Active Directory 管理コンソールを使用して管理するドメインの名前をスタティックに設定します。この Windows ドメインには、これに関連付けられた対応する DNS ゾーンがあります。ドメイン コントローラにはまた、その TCP/IP プロパティ コントロール パネルに設定された一連の DNS リゾルバもあります。

 

Windows ドメイン コントローラが起動されると、次の手順を実行してそれ自身を DNS に登録し、ネットワークにそのサービスをアドバタイズします。

1. DNS を照会して、その Windows ドメインを大部分厳密にカプセル化している DNS ドメインの start of authority(SOA)レコードを探します。

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

3. RFC 2136 DNS アップデート プロトコルを使用して、このゾーンに一連の SRV レコードを作成します。

サーバ起動プロセスのログ ファイル例

通常の操作条件では、Windows ドメイン コントローラが起動されてその 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 ドメイン コントローラは、起動したときに 17 レコードの SRV を通常は登録します。

Windows ドメイン コントローラがそのサービスを DNS にダイナミックに登録して、サービスをネットワークにアドバタイズできるように、Network Registrar DNS サーバを設定できます。このプロセスは RFC 準拠の DNS アップデートを使用して行われるので、Network Registrar で通常でないことを何も行う必要はありません。

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


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

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

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

ステップ 4 DNS アップデートの許可を制限するホストの IP アドレスを定義する、DNS アップデート ポリシーを設定します(「DNS アップデート ポリシーの設定」を参照)。これらは通常は DHCP サーバとすべての Windows ドメイン コントローラです(Windows ドメイン コントローラには、スタティック IP アドレスが必要です)。

DNS サーバがアップデートを受け入れる必要のある先のすべての IP アドレスの一覧を入力することが実際的でないかまたは不可能な場合は、アドレス範囲からアップデートを受け入れるように Network Registrar を設定できます。ただし、この設定はお勧めしません。

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


 

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

ほとんどの Windows 展開は、Windows NT 4.0 環境からの移行です。既存の Windows NT 4.0 ドメイン構造は、できる限り保存することをお勧めします。次の規則と推奨事項により、Windows 展開がさらに管理しやすくなります。

Windows の規則と推奨事項

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

Windows ドメインは、DNS ホスト名の命名規則に違反しないようにします。

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

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

必要であれば、Windows ドメイン用の新しい DNS ゾーンを作成します(w2k.example.com サブゾーンや local.w2k.example.com ドメインなど)。

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

Windows ドメインの命名規則

Windows ドメイン スペースは DNS ネーム スペースと重複するので、特定の命名制限が Windows ドメインに適用されます。RFC 1035 の 2.3.1(「Domain Names Implementation and Specification」)にホスト名とドメイン名の命名規則が定義されています。DNS への依存のため、これらの命名規則が Windows ドメインに適用されます。

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

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

文字で始まる。

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

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

したがって、Windows NT 4.0 ドメイン名に一般的に使用されている多くの文字が Windows ドメイン名には使用できません。Windows ドメイン名に使用できない文字には、アンダースコア(_)、アットマーク(@)、アンパサンド(&)があり、これらは Windows NT 4.0 ドメイン名に一般的に使用されています。また、大文字小文字を組み合せたドメイン名も役に立たなくなります。たとえば、Windows は ExampleDomain を exampledomain と同じであると認識します。

Windows 環境に関連する問題

表27-6 で、Windows と Network Registrar との相互運用性に関する問題を説明します。この表で示す情報は、発生する可能性がある問題について、実際に発生する前に知っておくために提供されています。Windows 相互運用性についての FAQ については、「Windows 統合についての FAQ」を参照してください。

 

表27-6 Windows と Network Registrar の相互運用性に関する問題

問題
説明

表示されないダイナミックに作成された RR

Network Registrar は、適切に設定されていると、DHCP サーバと Windows サーバの両方から DNS アップデートを受け入れます。CLI を使用して、DNS ゾーンのダイナミック部分にアクセスしてレコードを表示および削除できます。次のコマンドを入力して、指定したゾーンのすべての DNS RR を表示します。

nrcmd> zone myzone listRR dynamic myfile
 

 

この操作により出力が myfile ファイルにリダイレクトされます( P.27-27の例27-1 を参照)。

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

nrcmd> zone myzone removeDynRR myname [ type ]
 

また、 nslookup を使用してそれが存在することも確認でき、またバージョン 5. x (Windows とともに出荷)を使用してダイナミック SRV レコードを表示することもできます。このバージョンでは、 set type=SRV を使用して、SRV レコードの表示をイネーブルにします。

ドメイン コントローラの登録

Windows ドメイン コントローラは、DNS アップデートを使用してそれ自身を DNS に登録する必要があります。DNS RFC では、特定のゾーンのプライマリ DNS サーバのみがゾーン データの編集を受け入れることができると規定しています。したがって、Windows ドメイン コントローラは Windows ドメイン名を含むゾーンのプライマリ DNS サーバはどれであるかを検出する必要があります。

ドメイン コントローラはこれを検出するために、リゾルバ リスト(TCP/IP プロパティ コントロール パネルに設定されている)内の最初の DNS サーバを照会します。最初の照会は、ドメイン コントローラの Windows ドメインを含むゾーンの SOA レコードを見つける照会です。SOA レコードには、ゾーンのプライマリ サーバの名前が含まれています。そのドメイン名のゾーンが存在しない場合、ドメイン コントローラはそのドメインに含まれるプライマリ サーバを持つ SOA レコードを見つけるまで、ドメイン名の左端のラベルを除去して照会を送信することを続けます。ドメイン コントローラがそのドメインのプライマリ DNS サーバの名前を見つけると、DNS アップデートを送信して必要な SRV レコードを作成します。

ゾーンのプライマリ DNS サーバの名前が、その SOA レコードに存在することを確認してください。

A レコード DNS アップデートの失敗

Windows ドメイン コントローラがそれ自身をネットワークにアドバタイズする場合、そのドメインのレコードの DNS サーバに複数の DNS アップデート要求を送信します。これらのアップデート要求のほとんどは、SRV レコードに関してです。しかしドメイン コントローラはまた、Windows ドメインと同じ名前の 1 つの A レコードのアップデートも要求します。

Network Registrar DNS サーバがまたこの Windows ドメインに対してと同一のゾーンの権限も持っている場合は、DNS A レコード アップデートはスタティック SOA レコードおよび NS レコードと競合するために、A レコードの登録を拒否します。これは、ダイナミック ホストのそれ自身の登録やサイトへの Web トラフィックのスプーフィングなどの、セキュリティ違反行為の可能性を防止するためです。

たとえば、ドメイン コントローラが w2k.example.com Windows ゾーンをコントロールすることがあります。同じ名前のゾーンが Network Registrar DNS サーバ上に存在すると、次の RR がそのゾーンの一部となることがあります(次の例を参照)。

w2k.example.com. 43200 SOA nameserver.example.com.
hostmaster.example.com.
(
98011312 ;serial
3600 ;refresh
3600 ;retry
3600000 ;expire
43200 ) ;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 レコードと競合します。

 

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

0 8/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 データの DNS アップデートに対する Network Registrar の対応方法です。さらに、この DNS アップデートの失敗は無視できます。Windows クライアントはこの A レコードを使用しません。ドメイン コンローラの割り振りは、SRV レコードを使用して行われます。Microsoft は、SRV レコードをサポートしない古い NT クライアントに対応するために A レコードを追加しました。

コントローラの A レコードの登録に失敗するとドメイン コントローラの起動プロセスが低速になって、ユーザの全体ログインに影響することに注意してください。前述のように、対応策は権限を持つゾーンのサブドメインとして Windows ドメインを定義するか、または DNS サーバの
simulate-zone-top-dynupdate アトリビュートをイネーブルにすることです。これが可能でない場合は、Cisco Technical Assistance Center に連絡してください。

Windows RC1
DHCP クライアント

Microsoft がリリースした Windows ビルド 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 から入手してください。

Windows プラグアンドプレイ ネットワーク インターフェイス カード(NIC)コンフィギュレーション

DHCP を使用するように設定されると、Windows システムは起動時に DHCP リースを取得しようとします。DHCP サーバが使用できない場合、Windows はコンピュータのインターフェイスをプラグアンドプレイ IP アドレスで自動的に設定する場合があります。このアドレスは、ネットワーク管理者や DHCP サーバが設定または選択したアドレスではありません。

これらのプラグアンドプレイ アドレスは 169.254.0.0/16 の範囲内です。ネットワーク上でこのアドレス範囲内のデバイスが見つかった場合、Windows が DHCP サーバからリースを取得できなかったために、インターフェイスを自動設定したことを意味します。

これは、ネットワークおよびトラブルシューティングに重大な問題を発生させることがあります。これ以降、Windows システムは、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 クライアント アドレス レコードの清掃

Windows クライアントはそれ自身を清掃しないので、そのダイナミック レコード登録が無限に残る可能性があります。そのため、古いアドレスが DNS サーバ上に残ります。これらの古いレコードを定期的に削除するには、ゾーンの清掃をイネーブルにする必要があります(「ダイナミック レコードの清掃」を参照)。

例27-1 表示されないダイナミックに作成された RR を示す出力

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 統合についての FAQ

次の質問は、Network Registrar DNS サービスと Windows との統合についてのよく寄せられる質問です。

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

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

DNS アップデート クライアントによりアップデートされるゾーンはすべて、DNS 清掃をイネーブルにして、一時的な Windows クライアントによって残された古い RR の残存期間を短縮します。DHCP サーバと Windows クライアントの両方が同じゾーンをアップデートする場合、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 日以下に設定できます。

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

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

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

A. Windows ドメイン コントローラからの 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 ;serial
3600 ;refresh
3600 ;retry
3600000 ;expire
43200 ) ;minimum
example.com.86400 NS ns.example.com
ns.example.com. 86400 A 10.0.0.10
_ldap._tcp.w2k.example.com. IN SRV 0 0 389 dc1.w2k.example.com
w2k.example.com 86400 A 10.0.0.25
...
 

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

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

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

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

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

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 によるセキュリティは最も理想的な解決策ではありません。スプーフィングされたソースからの悪意ある攻撃を防止しません。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 アップデートのみを受け入れます。