DNS 更新を構成する際には、次の 2 つの問題を考慮してください。

• セキュリティ上の理由から、Cisco Prime Network レジストラー DNS 更新プロセスでは、管理者が DNS データベースに手動で入力した名前は変更または削除されません。
• 大規模な展開で DNS 更新を有効にし、HA DNS を使用していない場合 (「高可用性 DNS ペアの展開」のCisco Prime Network Registrar 11.1 Authoritative and Caching DNS User Guide章を参照) は、プライマリ DNS サーバーと DHCP サーバーを複数のクラスターに分割します。DNS 更新は、サーバーに追加の負荷を生成します。

DHCPv6 の DNS 更新には、リース用の AAAA および PTR RR のマッピングが含まれます。Cisco Prime Network レジストラーでは、サーバーまたはエクステンションを使用した完全修飾ドメイン名と DHCPv6 クライアントFQDNオプション(39)がサポートされます。

Cisco Primeネットワーク レジストラーは RFC 4701、4703、および 4704 に準拠しているため、DHCID リソース レコード(RR)をサポートします。すべての RFC-4703 準拠のアップデータは、DHCID R を生成し、クライアント識別子 (DUID) と FQDN (RFC 4701 に従う) のハッシュであるデータを生成できます。ただし、更新ポリシー ルールで AAAA および DHCID の R を使用できます。

DHCPv6 の DNS 更新処理は、DHCPv4 の場合と似ていますが、1 つの FQDN が複数のリースを持つことができる点を除いて、1 つのクライアントに対して複数の AAAA および PTR R が発生します。複数の AAAA R は、同じ名前または異なる名前にすることができます。ただし、PTR の R は、リース アドレスに基づいて常に異なる名前で指定されます。RFC-4703 準拠のアップデータは、複数のクライアント間の競合を回避するために DHCID RR を使用します。

（注）	DNS サーバーがダウンしていて、DHCP サーバーが DNS 更新を完了して DHCPv6 リースに追加された R を削除できない場合、リースは引き続き AVAILABLE 状態で存在します。同じクライアントのみがリースを再利用します。

委任されたプレフィックスの DNS 更新を有効にして、委任されたプレフィックス リースの AAAA および PTR マッピングを更新できます。ただし、この場合、委任されたプレフィックスの 0 アドレスの DNS のみが更新されます。たとえば、2001:db8:3333:3333:/64 のプレフィックスが委任されている場合、2001:db8:3333:3333::0 の PTR および/または AAAA のみが委任されます。は DNS で更新されます。この機能は、委任されたプレフィックスに対して DNS 委任を行う手段を提供しません。

委任されたプレフィックスの更新は、DNS 更新構成でプレフィックス委任更新属性が有効になっている場合にのみ有効になります。この属性はデフォルトでは無効になっています。委任されたプレフィックスの更新は、アドレス更新とは異なるゾーンに発生する可能性が高いため、新しい DNS 更新構成を作成して、対応するプレフィックスに関連付ける必要があります。

標準の名前生成規則が適用されるため、ヒントを含む FQDN オプションを含むクライアントは、結果の名前に影響を与える可能性があります (構成で許可されている場合)。クライアントは、FQDN オプションを要求した場合、プレフィックスの委任の更新に使用される名前を返されることはありません。

（注）	この機能を使用する場合は、両方のフェールオーバー パートナーがこの機能をサポートするバージョンを実行していることを確認する必要があります。それ以外の場合、更新はアップグレードされたサーバーによってサービスを提供された場合にのみ実行されます。したがって、両方のパートナーがアップグレードされるまで、この機能を有効にしないでください。

Cisco Prime Network レジストラーの前に設定された、DHCPv6 処理用の DNSDHCPv6 ポリシー階層更新オブジェクトを参照するポリシーを使用する場合(を参照)、サーバーは、指定された DNS サーバーに対する DNS 更新のキューイングを開始します。これは、DNS 更新が DHCPv6 リースに対して自動的に (および予期せず) 開始する可能性があることを意味します。

注意	Cisco Prime Network レジストラーまたはその他の DNS サーバーの以前のバージョンを使用する場合、最近の DHCID RR 標準の変更により、ゾーン転送および DNS 更新の相互運用性の問題が発生する可能性があります。DHCPv6 DNS 更新をサポートするために、DNS サーバーをアップグレードする必要がある場合があります。

クライアントがホスト名を指定しない場合、DHCPv4 および DHCPv6 には合成名生成プログラムが含まれます。DNS 更新構成の v6 合成名前生成属性を使用すると、次の内容に基づいて生成された名前を合成名のステムに追加できます。

• クライアント DHCP 一意識別子 (DUID) 値 (プリセット値) のハッシュ。
• 未加工のクライアント DUID 値 (区切り記号のない 16 進数のストリング)。
• CableLabs ケーブルラボ-17オプションdevice-idサブオプション値(区切り文字のない 16 進数文字列、または見つからない場合はクライアント DUID のハッシュ)。
• CableLabs ケーブルラボ-17オプションcm-mac-addressサブオプション値 (区切り記号のない 16 進数の文字列として、または見つからない場合はクライアント DUID のハッシュ)。

注意	ドメインがインターネットからアクセス可能な場合、一部の生成方法によってプライバシーの問題が発生する可能性があります。

DNS 更新構成のv4 合成名前生成属性では、次の内容に基づいて生成された名前を合成名のステムに追加できます。

• address:クライアントの v4 アドレスを識別します。
• クライアント ID:要求で DHCPv4 クライアントによって指定されたクライアント ID または DUID (オプション 61)。
• hashed-client-id—SHA-256 ハッシュの右部分 64 ビットで形成された 13 文字のベース 32 でエンコードされた文字列である、ハッシュ化されたクライアント ID に、前方ゾーン名が付加されます。

合成DNS 更新設定の作成名の生成を使用して DNS 更新構成を作成する方法については、「」を参照してください。

CLI では、この設定の例を次に示します。

nrcmd> dhcp-dns-update example-update-config set v6-synthetic-name-generator=hashed-duid
 
nrcmd> dhcp-dns-update example-update-config set v4-synthetic-name-generator=client-id

DNS 更新構成では、指定された逆ゾーン プレフィックス長属性のプレフィックス長の値を使用して、ip6.arpa ドメインの逆ゾーンを生成します。ip6.arpa ドメインを使用して合成できるため、完全なリバースゾーンを指定する必要はありません。逆引き DNS 更新の構成に対してDNS 更新設定の作成この属性を設定します (「 」を参照してください)。逆引きゾーンプレフィックス長に関する規則を次に示します。

• ip6.arpa ゾーンは 4 ビット境界上にあるため、値には 4 の倍数を使用します。4 の倍数でない場合、値は 4 の次の倍数に切り上げられます。
• 最大値は 124 で、128 を指定すると、ホスト名が含まれる可能性のないゾーン名が作成されます。
• 値 0 はゾーン名に使用されるビットが一切使用されないので、ip6.arpa が使用されます。
• DNS 更新構成から値を省略すると、サーバーはプレフィックスの値を使用するか、最後の手段としてプレフィックスのアドレス値から取得されるプレフィックス長を使用します (「」をプレフィックスとリンクの設定参照)。

逆ゾーン名を合成するには、DHCP サーバーに対して、ゾーンの逆引きのシンセを有効にしておく必要があります。したがって、逆ゾーン名が DHCPv6 に対して合成される順序は次のようになります。

1. 逆引き DNS 更新の構成で完全な逆ゾーン名を使用します。
2. 逆引き DNS 更新構成では、逆ゾーン プレフィックス長からの ip6.arpa ゾーンに基づいて設定します。
3. プレフィックス定義の逆ゾーンプレフィックス長から ip6.arpa ゾーンに基づいて設定します。
4. プレフィックス定義のアドレスのプレフィックス長から ip6.arpa ゾーンに基づいて設定します。

nrcmd> dhcp-dns-update example-update-config set reverse-zone-prefix-length=32

Web UI でプレフィックスの逆引きゾーンを作成するには、プレフィックスの一覧/追加ページCreate Reverse Zone に各プレフィックスのボタンが含まれています。（プレフィックスの作成と編集 を参照）。

CLI では、プレフィックスprefix のリバース–range ゾーンを作成する名前createReverseZone [ ] コマンドも提供します (アドレスまたは範囲の値から)。prefix 名前deleteReverseZone [ ]–range を使用して、逆引きゾーンを削除します。

逆ゾーンを直接構成するときにサブネットまたはプレフィックスの値を入力して、DHCPv4 サブネットまたは DHCPv6 プレフィックスからリバース ゾーンを作成することもできます。詳細については、以下の「プライマリ リバース ゾーンの構成」を Cisco Prime Network Registrar 11.1 Authoritative and Caching DNS User Guide参照してください。

既存の DHCP サーバーの使用クライアント fqdn属性は、要求の DHCPv6 クライアント FQDN オプションにサーバーが注意を払うかどうかを制御します。クライアントに複数の名前が存在する場合に、サーバーが返す名前を決定するために使用する規則は、次の優先順位です。

1. クライアントを使用するサーバー FQDN は、(DNS 内に存在すると見なされない場合でも) リースに使用されている場合に、FQDN を要求しました。
2. DNS 内に最も長い有効期間を持つ FQDN が有効であると見なされます。
3. DNS 内にまだない有効期間が最長の FQDN。

DNS キャッシュ サーバーまたはゾーン レベルで ACL を割り当てます。ACL には、次の 1 つ以上の要素を含めることができます。

• IP - ドット区切り 10address 進表記法たとえば、192.168.1.2 とします。
• Network - ドット 10 進表記とaddress スラッシュ表記。たとえば、192.168.0.0/24 などです。この例では、そのネットワーク上のホストのみが DNS サーバーを更新できます。
• Another - 事前定義するACL 必要があります。埋め込みリレーションシップを削除するまでは、別の ACL に埋め込まれている ACL を削除できません。その ACL へのすべての参照が削除されるまで、ACL を削除しないでください。
• Transaction- Signature値は、キーワードの後にシークレット値が続く形式の値でなければなりません。 (TSIG) key key key スペース文字を格納するには、リスト全体を二重引用符で囲む必要があります。TSIG キーについては、トランザクションのセキュリティを参照してください。

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

• any —誰でも特定のアクションを実行できます
• none -誰も特定のアクションを実行できません
• localhost - ローカル・ホスト・アドレスは、特定のアクションを実行できます。
• localnets - ローカル ネットワークは、特定のアクションを実行できます。

次の点に注意してください。

• ACL が設定されていない場合はany 、この値が想定されます。
• ACL が設定されている場合、少なくとも 1 つの句でトラフィックを許可する必要があります。
• 否定演算子 (! ) は、前のオブジェクトのトラフィックを禁止しますが、明示的に指定しない限り、本質的に他のトラフィックを許可しません。たとえば、IP アドレス 192.168.50.0 のトラフィックのみを禁止するには、を使用!192.168.50.0, any します。

DNS サーバーまたはゾーンの ACL を構成するには、DNS 更新ポリシーを設定し、ゾーンに対してこの更新ポリシーDNS 更新ポリシーの設定を定義します (「」を参照)。

TSIG キーを生成するには、Cisco Prime Network レジストラー cnr_keygen ユーティリティを使用して、追加するか、またはimport keys を使用してインポートすることをお勧めします。

DOScnr_keygen Linux シェルからキー生成ユーティリティを実行します。このユーティリティは、インストールパス/usrbin ディレクトリにあります。

使用例を次に示します。

> /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; 
};

キー名だけが必要です。オプションを次の表に示します。

結果のシークレットは、ランダムな文字列として base64 エンコードされます。

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

その後、CLI を使用してキー ファイルを Cisco Prime Network レジストラーにインポートし、ファイル内のキーを生成できます。キーのインポートでは、インポート ファイルで検出された数だけキーを生成できます。ファイルへのパスは完全修飾パスにする必要があります。次に例を示します。

nrcmd> import keys keydir/keyfile.txt
 

独自のキーを生成する場合は、base64 エンコード文字列として入力する必要があります (base64 エンコードの詳細については RFC 4648 を参照してください)。これは、許可される文字は base64 のアルファベット文字と、埋め込み文字としての等号 (=) だけであることを意味します。base64 エンコードされていない文字列を入力すると、エラー メッセージが表示されます。

次に、他の推奨事項をいくつか示します。

• バッチ コマンドを使用してキーを追加または変更しないでください。
• 共有シークレットを頻繁に変更する。2ヶ月ごとにお勧めします。Cisco プライムネットワーク レジストラーでは、明示的にはこれを適用しないことに注意してください。
• 共有秘密の長さは、キー付きメッセージ ダイジェスト (HMAC-MD5 が 16 バイト) の長さ以上にする必要があります。Cisco Prime Network レジストラーでは、明示的に強制するものではなく、共有シークレットが有効な base64 でエンコードされた文字列であることを確認するだけですが、RFC 2845 で推奨されているポリシーです。

DNS 更新の構成に対して TSIGDNS 更新設定の作成サポートを追加するには (を参照) 次の属性を設定します。

• server-key

• backup-server-key

TSIG で GSS-TSIG セキュリティ アルゴリズムを使用するには、以下の属性を有効にします。

• 使用-gss-tsig

dhcp-dns-update 名前create を使用する [属性=値..] 次に例を示します。

dhcp-dns-update example-update-config create

dynamic-dns属性を適切な値 (更新なし、すべて更新、更新-fwd のみ、または更新 -逆のみ) に設定します。次に例を示します。

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

Cisco Prime Network レジストラーリリースでは、管理者が入力した静的 R を使用しましたが、DNS 更新は変更できませんでした。静的な R と動的な R の区別はなくなりました。ここで、R を保護または保護解除としてマークできるようになりました (の「リソース レコード セットの保護」セクションを Cisco Prime Network Registrar 11.1 Authoritative and Caching DNS User Guide参照)。管理者が、R を作成または変更することで、R を保護するかどうかを指定できるようになりました。DNS 更新は、指定されたタイプの RR がセット内にまだ存在しない場合でも、保護された RR セットを変更できません。

（注）	以前のリリースでは、A、TXT、PTR、CNAME、および SRV レコードに対してのみ DNS 更新を許可しました。これは、保護されていない名前セット内の SOA レコードおよび NS レコード以外のすべてのレコードを更新できるように変更されました。以前のリリースとの互換性を維持するには、更新ポリシーを使用して RR 更新を制限します。

DNS 更新ポリシーは、ACL に基づいて特定の R の更新を許可または拒否するルールを定義する場合にのみ有効です。ルールが満たされない場合、デフォルトの (最後の暗黙的な) ルールは"deny any wildcard * *" 、すべての更新を拒否する ( )。

[デザイン] メニューForward ZonesのサブメニューAuth DNSの下で 選択し、[転送ゾーンのリスト/追加] ページを開きます。左側のペインで必要なゾーンを選択し、[ゾーンの編集] ページの [リソース レコード] タブをクリックします。

zone name listRR dns を使用します。

[DNS サーバーの管理] ページで、[コマンド] をクリックして [DNSコマンド] ダイアログ ボックスを開きます。[すべてのゾーンを清掃する] の横にある [実行] アイコンをクリックします。

特定の前方ゾーンまたは逆ゾーンのみをスキャベンジするには、[ゾーンのゾーン コマンド] ページに移動します。 [スキャベンジ ゾーン] の横にある [実行] アイコンをクリックします。次に清掃がゾーンにスケジュールされている時刻を確認するには、[清掃開始時刻を取得] の横にある [実行] アイコンをクリックします。

清掃dns scavenge が有効になっているすべてのゾーンに使用します。ゾーンでgetScavengeStartTime のアクションを使用して、清掃が次回開始される予定の時刻を確認します。

クライアントが DNS を直接更新することを許可することはお勧めしません。

Windows クライアントがアドレス レコードの更新を DNS サーバーに送信するには、次の 2 つの条件が適用される必要があります。

• Windows クライアントの [TCP/IP コントロール パネルRegister this connection’s addresses in DNS ] 設定のDNS タブでチェック ボックスをオンにする必要があります。

• DHCP ポリシーは直接更新を有効にする必要があります(Cisco Prime Network レジストラーポリシーはデフォルトで有効にします)。

Windows クライアントは、DHCPREQUESTパケットでクライアント FQDN DHCP オプション (81) を送信して、DNS サーバーに A レコードを更新する意図を DHCP サーバーに通知します。完全修飾ドメイン名 (FQDN) を示すことによって、このオプションは、ドメイン名前空間内のクライアントの場所を明確に示します。FQDN 自体と共に、クライアントまたはサーバーは、クライアント FQDNオプションで次のいずれかのフラグを送信できます。

• 0 クライアントは、その A レコードを DNS サーバーに直接登録し、DHCP サーバーは PTR レコードを登録します (有効になっているポリシーのクライアントレコード更新を許可する属性を使用して行われます)。

• 1 :クライアントは、DHCP サーバーに対して、その A レコードと PTR レコードを DNS サーバーに登録するように要求します。

• 3 DHCP サーバーは、クライアント要求に関係なく、A および PTR レコードを DNS サーバーに登録します(ポリシーの[クライアントのレコード更新を許可]属性を使用して行われる場合は、デフォルト値です)。このフラグを設定できるのは DHCP サーバーだけです。

DHCP サーバーは、DNS 更新が有効になっているかどうかに基づいて、DHCPACK 内のクライアントに対して、独自のクライアント FQDN応答を返します。ただし、0 フラグが設定されている場合 (ポリシーでクライアントのレコード更新を許可する属性が有効になっている)、DNS 更新を有効または無効にすることは、クライアントが DNS サーバーに更新を送信できるため、無関係です。さまざまなプロパティの設定方法に基づいて実行されるアクションについては、次の表を参照してください。

DHCP サーバーは、クライアント要求を無視する client-fqdn オプションを設定できます。Cisco Prime Network レジストラーでこの動作を有効にするには、Windows クライアント用のポリシーを作成し、このポリシーのクライアントのレコード更新許可属性を無効にします。

Cisco プライムネットワーク レジストラーでは、次の属性がデフォルトで有効になっています。

• Server use-client-fqdn：サーバーは着信パケットで client-fqdn 値を使用しますが、host-name は確認しません。DHCP サーバーは、ドメイン名の値の最初のドットの後のすべての文字を無視します。クライアント名が予期しない文字を送信している可能性があるために、サーバーがクライアント名をクライアント fqdnから判別しないようにする場合にのみ、use-client-fqdnを無効にします。

• Server use-client-fqdn-first：サーバーは host-name オプション (12) を確認する前に、クライアントからの着信パケットで client-fqdn を確認します。クライアント fqdnにホスト名が含まれている場合、サーバーはそれを使用します。サーバーがオプションを見つけられない場合は、host-name値を使用します。use-client-fqdn-firstが無効になっている場合、サーバーはクライアント fqdnよりもホスト名の値を優先します。

• Server use-client-fqdn-if-asked：クライアントが要求した場合、サーバーは発信パケットの client-fqdn 値を返します。たとえば、クライアントは DNS アクティビティの状態を知りたい場合、DHCP サーバーがクライアント fqdn値を提示するように要求します。

• Policy allow-client-a-record-update：クライアントが client-fqdn フラグを 0 に設定（直接の更新を要求）している限り、クライアントは DNS サーバーで直接 A レコードを更新できます。それ以外の場合、サーバーは、他の構成プロパティに基づいて A レコードを更新します。

クライアント要求に返されるホスト名は、これらの設定によって異なります (下の表を参照)。

Windows DHCP クライアントは、2 つの DNS ゾーンに A レコードを持つ DHCP 展開の一部である場合があります。この場合、DHCP サーバーはクライアントがデュアル ゾーン更新を要求できるように、クライアント fqdnを返します。デュアル ゾーン更新を有効にするには、ポリシー属性の許可デュアル ゾーン DNS 更新を有効にします。

DHCP クライアントは、クライアント fqdnに 0 フラグを送信し、クライアントがメイン ゾーンの A レコードを使用して DNS サーバーを更新できるように、0 フラグを返します。ただし、DHCP サーバーは、クライアントの代わりにクライアントのセカンダリ ゾーンに基づいて A レコードの更新も直接送信します。クライアントのレコード更新と、デュアル ゾーンDNS の許可の両方が有効になっている場合、デュアル ゾーン更新が優先され、サーバーがセカンダリ ゾーン A レコードを更新できるようになります。

Windows は、ネットワークへの広告サービスの DNS プロトコルに大きく依存しています。次の表は、Windows がサービスロケーション (SRV) DNS R および DNS 更新を処理する方法を示しています。

Cisco Prime Networkレジストラー DNS サーバーを設定して、Windows ドメイン コントローラがサービスを DNS に動的に登録し、それによってネットワークにアドバタイズできるようにすることができます。このプロセスは RFC 準拠の DNS アップデートによって行われるため、Cisco Prime Network レジストラーでは通常の方法で何もする必要はありません。

_ service ._ protocol . name ttl class SRV priority weight port target

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

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.

次の表では、Windows および Cisco Prime Network Registrar 間の接続相互運用性に関する問題について説明します。この表の情報は、現場で発生する可能性のある問題を事前に通知することを目的としています。Windows の相互運用性に関してよく寄せられる質問Windows の統合に関するよく寄せられる質問については、を参照してください。

nrcmd> zone myzone listRR dynamic myfile

nrcmd> zone myzone removeDynRR myname [ type ] 

w2k.example.com. 43200 SOA nameserver.example.com.
hostadmin.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

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]

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!

Cisco Primeネットワーク レジストラー DNS サービスと Windows の統合について、次の質問がよく寄せられます。

Windows クライアントと DHCP サーバーの両方が同じゾーンを更新できる場合の動作これにより、古い DNS レコードがゾーンに残される可能性が生まれますか。もしそうなら、それについて何ができますか?

Windows クライアントがゾーンを更新することを許可しないことをお勧めします。代わりに、DHCP サーバーはすべてのクライアントの動的 RR レコードを管理する必要があります。DNS 更新を実行するように構成されている場合、DHCP サーバーはリースを提供したクライアントに関連付けられたすべての DR を正確に管理します。これに対し、Windows クライアント マシンは、毎日の DNS 更新をサーバーに盲目的に送信し、ネットワークから削除された場合は、古い DNS エントリを残します。

DNS 更新クライアントによって更新されるゾーンでは、一時的な Windows クライアントが残す古い R の長寿を短縮するために DNS の清掃機能を有効にする必要があります。DHCP サーバーと Windows クライアントの両方が同じゾーンを更新している場合、Cisco Prime Network レジストラーでは次の 3 つのことが必要です。

1. ゾーンの清掃を有効にします。

2. 各クライアントがリースを更新するたびに、DHCP サーバーが DNS 更新エントリを更新するように構成します。デフォルトでは、Cisco Primeネットワーク レジストラーは、作成から最終削除までの間に DNS レコードを再度更新しません。Cisco プライムネットワーク レジストラーがリースの開始からリースの期限が切れるまで、ライフを作成する DNS 更新レコード。この動作は、DHCP サーバー (または DNS 更新構成) 属性 (強制 DNS 更新) を使用して変更できます。次に例を示します。

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

3. 特定のゾーンで清掃が有効になっている場合、DHCP サーバーが代わりにそのゾーンを更新するクライアントに関連付けられているリース時間は、更新なし間隔および更新間隔の清掃設定の合計より小さくなければなりません。これらの設定は両方とも 7 日間に設定されています。これらのデフォルト値を変更しない場合は、リース期間を 14 日以下に設定できます。

重複する DNS ドメインと Windows ドメインを持たないと判断した場合に Windows ドメインを既存の DNS ドメインの命名構造と統合するのに必要な手順たとえば、example.com という既存の DNS ドメインがあり、w2k.example.comという Windows ドメインが作成されている場合、Windows ドメインを DNS ドメインに統合するには何をする必要がありますか。

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

この場合、ドメイン コントローラからの DNS 更新はどのように処理されますか。

Windows ドメイン コントローラからの SRV レコードの更新を処理するには、DNS の更新をexample.comに制限します。ゾーンは IP アドレスによってのみドメイン コントローラに接続されます。(後で、DHCP サーバーの IP アドレスも一覧に追加します)。ゾーンの清掃を有効にします。コントローラは、example.com ゾーン内のw2k.example.com サブドメインの SRV レコードと A レコードを更新します。w2k.example.comの A レコードは、EXAMPLE.COM ゾーン内の SOA、NS、またはその他の静的レコードと競合しないため、各ドメイン コントローラからの A レコードの更新を処理するために特別な構成は必要ありません。

example.com. 43200 SOA ns.example.com. hostadmin.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
...

この場合、個々の Windows クライアント マシンからのゾーン更新はどのように処理されますか。

このシナリオでは、クライアントは、example.comを更新しようとする可能性があります。w2k.example.com ドメインの更新を含むゾーン。これを回避する方法は、信頼できるソースからのゾーンを更新プログラムに閉じる方法です。Cisco Prime Network レジストラーでは、DHCP サーバーとexample.com ゾーンのプライマリ DNS サーバーの間でトランザクション シグニチャ(TSIG)を使用できます。

DHCP サーバーを構成して、example.com ゾーンに対して DNS 更新を行い、各クライアントに対して適切な逆ゾーンを使用し、オプション 81 を使用してクライアントが DNS 更新を実行できないようにします。

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

信頼された IP アドレスからの更新のみを受け入れるように、前方ゾーンと逆方向のゾーンを構成すると、ネットワーク上の他のデバイスからの更新プログラムに対してゾーンを閉じます。IP によるセキュリティは、なりすまし IP アドレス ソースからの悪意のある攻撃を防ぐことができないので、最も理想的なソリューションではありません。DHCP サーバーと DNS サーバーの間で TSIG を構成することで、DHCP サーバーからの更新をセキュリティで保護できます。

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

いいえ。更新は、ドメイン コントローラと DHCP サーバーからのみ受け付けられます。DHCP サーバーは、追加するレコードのライフ サイクルを正確に維持し、清掃を必要としません。Cisco Prime Network レジストラーの単一レコード動的 RR 削除機能を使用して、ドメイン コントローラのダイナミック エントリを手動で管理できます。

名前空間を DNS ドメインと共有する Windows ドメインを統合するのに必要な手順たとえば、example.comという既存の DNS ゾーンがあり、example.comという Windows Active Directory ドメインを展開する必要がある場合、どうすればいいでしょうか。

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

この場合、個々の Windows クライアント マシンからの DNS 更新はどのように処理されますか。

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

DNS の更新をこれらのゾーンに対して、IP アドレスのみでドメイン コントローラに制限します。これらのゾーンで清掃を有効にします。

各ドメイン コントローラからの A レコードの更新を処理するには、DNS サーバー属性であるゾーン トップ dynupdateをシミュレートする属性を有効にします。

nrcmd> dns enable simulate-zone-top-dynupdate

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

この場合、個々の Windows クライアント マシンからのゾーン更新はどのように処理されますか。

このシナリオでは、クライアントがexample.comゾーンを更新しようとする可能性があります。これを回避する方法は、信頼できるソースからのゾーンを更新プログラムに閉じる方法です。Cisco Prime Network レジストラーでは、DHCP サーバーとexample.com ゾーンのプライマリ DNS サーバーの間でトランザクション シグニチャ(TSIG)を使用できます。

DHCP サーバーを構成して、example.com ゾーンに対して DNS 更新を行い、各クライアントに対して適切な逆ゾーンを使用し、オプション 81 を使用してクライアントが DNS 更新を実行できないようにします。

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

信頼された IP アドレスからの更新のみを受け入れるように、前方ゾーンと逆方向のゾーンを構成すると、ネットワーク上の他のデバイスからの更新プログラムに対してゾーンを閉じます。IP によるセキュリティは、なりすましソースからの悪意のある攻撃を防ぐことができないので、最も理想的なソリューションではありません。DHCP サーバーと DNS サーバーの間で TSIG が構成されている場合、DHCP サーバーからの更新の方が安全です。

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

はい。サブゾーン _tcp.example.com、_sites.example.com、_msdcs.example.com、_msdcs_msdcs.example.com、および _udp.example.com ゾーンは、ドメイン コントローラーからのみ更新を受け入れ、これらのゾーンに対して清掃が有効になっています。example.com ゾーンは、DHCP サーバーからのみ DNS 更新を受け付けます。