最終更新日: 2004年11月30日
このシナリオでは、実験で使用したネットワークにおいて、Windows 2000 ベースのコンピュータと Microsoft® Windows NT® Version 4.0 ベースのコンピュータ向けのドメイン ネーム システム (DNS) 動的更新や、Windows 2000 ベースのコンピュータ向けのセキュリティで保護された DNS 動的更新をどのようにして導入したか説明します。
トピック
目的
設計のロジック
DNS データベース内のデータの動的更新
スケーラビリティ
セキュリティ
機能するしくみ
Windows 2000 ベース クライアント向けの動的更新
Windows NT 4.0 ベースのクライアント向けの動的更新
Windows 2000 ベース クライアント向けのセキュリティで保護された動的更新
実装した方法
セットアップ手順
その他の参考資料
目的
このシナリオでは、以下の目的を達成するために動的更新を使用します。
Windows 2000 ベースおよび Windows NT 4.0 ベースの両方のクライアントに対して、データベースを継続的に更新し、その正確性を高めるために、ネットワークへの接続時に前方参照ゾーンおよび逆引き参照ゾーンのリソース レコードで DNS データベースを自動的に更新します。
管理者が介在することなく、クライアントを自動的にネットワークに追加することによって、ネットワークのスケーラビリティを確保します。
セキュリティで保護された動的更新でも同じ目的を達成できますが、権限のないユーザーに対して DNS ゾーンおよびリソース レコードを修正することを禁止できるため、Windows 2000 ベースのクライアントの DNS データを保護するのに役立ちます。
次の「設計のロジック」では、このシナリオのインフラストラクチャで上記の目的をどのようにして達成したか説明します。
設計のロジック
このシナリオでは、動的更新およびセキュリティで保護された動的更新の両方で、同じコンポーネントを使用します。動的更新とセキュリティで保護された動的更新の機能の違いについては、後述の「機能するしくみ」を参照してください。セットアップ手順の違いについては、「実装した方法」を参照してください。図 1 は、このシナリオで使用するコンポーネントの構成です。
図 1: Seattle サブネット内のコンポーネント
動的更新およびセキュリティで保護された動的更新では、Windows ベースのクライアント、動的ホスト構成プロトコル (DHCP) サーバー、および DNS サーバー間で対話処理を行って、DNS データベース リソース レコードを自動的に更新します。その後、DNS サービスがこの DNS リソース レコードを使用して、DNS 名を IP アドレスに解決します。またセキュリティで保護された動的更新では、権限のないユーザーによる改ざんから DNS データが保護されます。
このシナリオでは、Resource Kit Corporation の Seattle サブネットのみで動的更新およびセキュリティで保護された動的更新を導入します。ただし、動的更新およびセキュリティで保護された動的更新を異なるサブネット間で動作させることもできます。DHCP および DNS の動的更新の導入について詳しくは、シナリオ『複数のサブネット環境のための DHCP 構成』を参照してください。
DNS データベース内のデータの動的更新
動的更新およびセキュリティで保護された動的更新を有効にする前は、管理者が DNS データベースに手動で DNS エントリを追加しました。動的更新およびセキュリティで保護された動的更新は自動的に機能するため、管理者が介在しなくても、DNSデータベースを継続的に更新し、その正確性を保つという最初の目的が達成されます。
このシナリオで使用する主なコンポーネントは、Windows 2000 ベースのドメイン コントローラ、Windows 2000 DNS サーバー、Windows 2000 DHCP サーバー、Windows 2000 ベースのクライアント、そして Windows NT 4.0 ベースのクライアントです。ドメイン コントローラは、ネットワークにログオンすることをクライアントに許可し、ネットワークのセキュリティを確保します。DNS サーバーは、ドメイン コントローラと同じコンピュータ上に構成されていて、ほかのコンピュータからネットワーク上のクライアントを検索するための名前解決機能を提供します。DHCP サーバーは、Active Directory から権限を与えられて、ネットワークに接続するクライアントに IP アドレス リースとその他の構成設定を提供します。
Microsoft® Windows® 2000 Professional ベースのクライアント、およびWindows NT 4.0 ベースのクライアントを既定の構成で使用します。動的更新によって、Windows 2000 Professional ベースのクライアントおよび Windows NT 4.0 ベースのクライアントの両方の名前および IP アドレスを DNS データベース内で自動的に更新できます。ただし、Windows 2000 ベースのクライアントだけが単独で、セキュリティで保護された動的更新処理を開始できます。動的更新およびセキュリティで保護された動的更新は Windows 2000 の新機能です。したがって、Windows NT 4.0 オペレーティング システムでは動的更新が認識されません。このため、Windows 2000 DHCP サーバー構成を変更して、Windows NT 4.0 ベースのクライアントで動的更新を利用できるようにします。
スケーラビリティ
Resource Kit Corporation のネットワーク環境では、新しいクライアントを多数追加するので、ネットワークを拡張するためにコスト効率が高く手間のかからない方法が必要です。動的更新機能およびセキュリティで保護された動的更新機能の自動処理によって、新しいクライアントを短時間で簡単に追加することが可能になります。動的更新機能またはセキュリティで保護された動的更新機能の構成されたサブネットでは、十分な DHCP リースが利用可能である限り、新しいクライアントを追加できます。Resource Kit Corporation では、ネットワーク トポロジの作成時に 22 ビットのサブネット マスクを選択したため、広範な IP アドレスを利用できます。
セキュリティ
セキュリティで保護された動的更新機能は、権限のないユーザーによる DNS のゾーンおよびレコードの改ざんを抑止します。Active Directory 統合ゾーンを作成した場合、このゾーンでは既定の構成でセキュリティで保護された動的更新のみが許可されます。
このシナリオではまず、保護されていない動的更新を使用する構成を適用します。その後、セキュリティで保護された動的更新を実行するように再構成します。
機能するしくみ
動的更新機能では、クライアントと DNS サーバーとの間でメッセージが交換されます。セキュリティで保護された動的更新は、動的更新と同様に機能しますが、IETF インターネット草案「GSS Algorithm for TSIG (GSS-TSIG) 」で指定されたアルゴリズムで署名される点が異なります。詳細については、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 6 章 Windows 2000 DNS」の「6.6 動的更新とセキュリティで保護された動的更新」を参照してください。
図 2 は、このシナリオで動的更新およびセキュリティで保護された動的更新を導入するために使用したエンタプライズの一部分を示しています。
図 2: Seattle サブネットのインフラストラクチャ
このシナリオの Windows 2000 DNS サーバーでは、Windows 2000 Professional ベースのクライアントおよび Windows NT 4.0 ベースのクライアント向けに送信される動的更新を処理します。
Windows 2000 向けの動的更新と、Windows NT 4.0 向けの動的更新、そして Windows 2000 向けのセキュリティで保護された動的更新では、それぞれの機能が多少異なり、さらに異なる構成が必要になるため、ここでは各種類の更新がどのように機能するか説明します。
Windows 2000 ベースのクライアント向けの動的更新
Windows NT 4.0 ベースのクライアント向けの動的更新
Windows 2000 ベースのクライアント向けのセキュリティで保護された動的更新
Windows 2000 ベース クライアント向けの動的更新
Windows 2000 ベースのクライアントは、DHCP によって IP アドレス リースを取得します。その後 Windows 2000 クライアントは、アドレス (A) リソース レコード (ホスト名リソース レコード) を含む更新メッセージを Windows 2000 DNS サーバーに送信し、これによって DNS データベースが更新されます。次に Windows 2000 DHCP サーバーは、ポインタ (PTR) リソース レコード (逆引き参照リソース レコード) を更新するために、DNS サーバーに更新メッセージを送信します。
以下の手順は、Windows 2000 ベース クライアント向けの動的更新処理がどのように実行されるか、その詳細を示しています。
図 3 で示すように、Windows 2000 ベースのクライアント SEA-NA-W2P-02.noam.reskit.com がネットワークに初めて接続すると、DHCP サーバーを特定するためにネットワーク上のすべてのコンピュータに DHCPDISCOVER メッセージをブロードキャストします。
図 3: DHCP サーバーを探索するためのブロードキャスト
図 4 で示すように、Windows 2000 DHCP サーバー SEA-NA-DHCP-01.noam.reskit.com が DHCPDISCOVER メッセージを受け取ると、利用可能なリースがあるかどうか自身の DHCP データベースをチェックします。
図 4: DHCP データベースのチェック
図 5 で示すように、この Windows 2000 DHCP サーバーは、リースが利用可能な場合、Windows 2000 ベースのクライアントに DHCPOFFER メッセージを送信します。この DHCPOFFER メッセージには、提供された IP アドレスと、サーバーでセットアップされているオプションの設定が含まれます。
図 5: Windows 2000 ベースのクライアントへの DHCPOFFER メッセージ
Windows 2000 ベースのクライアントは、DHCPOFFER メッセージ内の情報を使用して DHCP サーバーを選択し (通常は最初に応答した DHCP サーバー) 、IP アドレス リースを受け取るために、提供された IP アドレスに対応する DHCPREQUEST メッセージを DHCP サーバーに送信します。図 6 で示したこのメッセージではまた、さまざまな DHCP オプションに関する情報が必要になります。このようなオプションのいくつかを以下の一覧に示します。
サブネット マスク
ルーター IP アドレス
ドメイン名 (接続固有の DNS サフィックス)
WINS サーバー リスト
DNS サーバー リスト
オプション 81 情報
オプション 81 には、クライアントの FQDNと、PTR リソース レコード (PTR RR) の更新をクライアントのために代行することを DHCP サーバーに求める要求が含まれています。
図 6: IP アドレスの DHCPREQUEST メッセージ
図 7 で示すように、DHCPREQUEST メッセージを受け取った DHCP サーバーは、クライアントに DHCPACK メッセージを送信することによって、DHCP サーバーがリースを発行したことをクライアントに通知し、クライアントから要求された DHCP オプションの情報をクライアントに提供し、そして DHCP サーバーが PTR リソース レコードの更新を試みることをオプション 81 を使用してクライアントに応答します。
図 7: リースを認知する DHCPACK メッセージ
クライアントは、DHCP サーバーに PTR リソース レコードの更新を代行してほしいことをオプション 81 で示しました。図 8 で示すように、DHCP サーバーは、Windows 2000 ベースのクライアントの優先 DNS サーバー SEA-NA-DC-01.noam.reskit.com に DNS Start of Authority (SOA) クエリを送信することによって更新処理を開始し、FQDN に基づく逆引き参照レコード 55.8.16.172.in-addr.arpa の権威のあるゾーンおよび権威のあるサーバーを検索します。Windows 2000 ベースのクライアントにリースされた IP アドレスは 172.16.8.55 です。
図 8: 権威のあるゾーンおよび権威のあるサーバーを特定するための DNS SOA クエリ
図 9 で示すように、DNS サーバーは、55.8.16.172.in-addr.arpa の権威のあるゾーンと、権威のあるサーバー SEA-NA-DC-01.noam.reskit.com に関する NAME_ERROR および SOA の情報を応答します。この場合では、権威のある DNS サーバーと優先 DNS サーバーは同じです。
図 9: DNS SOA クエリへの DNS 応答
図 10 で示すように DHCP サーバーは、権威のある DNS サーバー SEA-NA-DC-01.noam.reskit.com に動的更新の要求を送信し、Windows 2000 ベースのクライアントのエントリ 55.8.16.172.in-addr.arpa を使用して PTR リソース レコードを更新することを要求します。
図 10: PTR リソースレコードの動的更新の要求
DNS サーバーは PTR リソース レコードを更新し、DHCP サーバーに動的更新の応答を送信して、DNS サーバーが Windows 2000 ベースのクライアントの PTR リソース レコードを更新したことを DHCP サーバーに通知します (図 11 を参照) 。
図 11: PTR リソースレコードの動的更新の応答
Windows 2000 ベースのクライアントは、優先 DNS サーバー SEA-NA-DC-01.noam.reskit.com に名前 SEA-NA-W2P.noam.reskit.com に関する DNS SOA クエリを送信し、クライアントの名前に対して権威のあるゾーンと権威のあるサーバーを特定します (図 12 を参照) 。
図 12: 権威のあるゾーンおよび権威のあるサーバーを特定するための DNS SOA クエリ
DNS サーバーは、権威のあるゾーン noam.reskit.com と、権威のあるサーバー SEA-NA-DC-01.noam.reskit.com に関する NAME_ERROR および SOA の情報を応答します (図 13 を参照) 。この場合、権威のある DNS サーバーと優先 DNS サーバーは同じです。
図 13: 権威のあるゾーンおよび権威のあるサーバーに関する DNS 応答
Windows 2000 ベースのクライアントは、権威のある DNS サーバー SEA-NA-DC-01.noam.reskit.com に動的更新の要求を送信し、Windows 2000 ベースのクライアント SEA-NA-W2P-02.noam.reskit.com の名前を IP アドレス 172.16.8.55 に割り当てている A リソース レコードを更新するように求めます (図 14 を参照) 。
図 14: A リソースレコードに対する動的更新の要求
DNS サーバーは、自身の DNS データベース内の A リソース レコードを更新した後、Windows 2000 ベースのクライアントに動的更新の応答を送信して、クライアントの名前を更新したことをクライアントに通知します (図 15 を参照) 。
図 15: A リソースレコードに対する動的更新の応答
注意
この例では、DHCP サーバーおよび Windows 2000 ベースのクライアントの両方で、優先 DNS サーバーとして SEA-NA-DC-01.noam.reskit.com が構成されていて、代替 DNS サーバーが構成されていない場合を仮定しています。DHCP サーバーおよび Windows 2000 ベースのクライアントが A リソース レコードと PTR リソース レコードを更新する順序は、ネットワーク条件に応じて異なります。
Windows NT 4.0 ベースのクライアント向けの動的更新
Windows NT 4.0 ベースのクライアントでは、DHCP によって IP アドレス リースを取得します。Windows NT 4.0 ベースのクライアントは動的更新処理を認識しないので、Windows NT 4.0 クライアントに代わって Windows 2000 DHCP サーバーが、Windows 2000 DNS サーバーによってホストされた DNS データベース内の A リソース レコードおよび PTR リソース レコードを更新します。
以下の手順は、Windows NT 4.0 ベース クライアント向けの動的更新処理がどのように実行されるか、その詳細を示しています。
図 16 で示すように、Windows NT 4.0 ベースのクライアント SEA-NA-NT4-01.noam.reskit.com がネットワークに初めて接続すると、DHCP サーバーを特定するためにネットワーク上のすべてのコンピュータに DHCPDISCOVER メッセージをブロードキャストします。
図 16: DHCP サーバーを探索するためのブロードキャスト
図 17 で示すように、Windows 2000 DHCP サーバー SEA-NA-DHCP-01.noam.reskit.com が DHCPDISCOVER メッセージを受け取ると、利用可能なリースがあるかどうか自身の DHCP データベースをチェックします。
図 17: DHCP データベースのチェック
図 5 で示すように、この Windows 2000 DHCP サーバーは、リースが利用可能な場合、Windows 4.0 ベースのクライアントに DHCPOFFER メッセージを送信します。この DHCPOFFER メッセージには、提供された IP アドレスと、サーバーでセットアップされているオプションの設定が含まれます。
図 18: Windows 4.0 ベースのクライアントへの DHCPOFFER メッセージ
Windows 4.0 ベースのクライアントは、DHCPOFFER メッセージ内の情報を使用して DHCP サーバーを選択し (通常は最初に応答した DHCP サーバー) 、IP アドレス リースを受け取るために、提供された IP アドレスに対応する DHCPREQUEST メッセージを DHCP サーバーに送信します。図 19 で示したこのメッセージではまた、さまざまな DHCP オプションに関する情報が必要になります。このようなオプションのいくつかを以下の一覧に示します。
サブネット マスク
ルーター IP アドレス
ドメイン名 (接続固有の DNS サフィックス noam.reskit.com)
WINS サーバー リスト
DNS サーバー リスト
Windows 2000 ベースのクライアントの場合とは異なり、Windows NT 4.0 ベースのクライアントは動的更新処理を認識しないので、オプション 81 の情報を DHCPREQUEST メッセージの一部として送信しません。
図 19: IP アドレスの DHCPREQUEST メッセージ
DHCPREQUEST メッセージを受け取った DHCP サーバーは、クライアントに DHCPACK メッセージを送信することによって、リースを発行したことを通知し、クライアントから要求されたオプションに対する回答を提示します (図 20 を参照) 。DHCPREQUEST メッセージにオプション 81 情報が含まれていなかったので、DHCPACK メッセージにもこのオプション 81 情報は含まれていません。
図 20: リースを認知する DHCPACK メッセージ
Windows NT 4.0 に代わって DHCP サーバーが DNS リソース レコードの動的更新を実行するように構成されているので、DHCP サーバーはさらにクライアント SEA-NA-NT4-01.noam.reskit.com の名前の権威のあるゾーンと権威のあるサーバーを検索するために、Windows NT 4.0 ベースのクライアントの優先 DNSサーバー SEA-NA-DC-01.noam.reskit.com (DHCP スコープ オプションによって提示されます) に DNS Start of Authority (SOA) クエリを送信します (図 21 を参照) 。Windows NT 4.0 ベースのクライアントにリースされた IP アドレスは 172.16.8.52 です。
図 21: 権威のあるゾーンおよび権威のあるサーバーを特定するための DNS SOA クエリ
DNS サーバーは、権威のあるゾーン noam.reskit.com と、権威のあるサーバー SEA-NA-DC-01.noam.reskit.com に関する NAME_ERROR および SOA の情報を応答します (図 22 を参照) 。権威のあるゾーンは noam.reskit.com です。この場合では、権威のある DNS サーバーと優先 DNS サーバーは同じです。
図 22: SOA クエリへの DNS 応答
DHCP サーバーは、権威のある DNS サーバー SEA-NA-DC-01.noam.reskit.com に動的更新の要求を送信し、Windows 4.0 ベースのクライアント SEA-NA-NT4-01.noam.reskit.com の名前を IP アドレス 172.16.8.52 に割り当てている A リソース レコードを更新するように求めます (図 23 を参照) 。
図 23: A リソースレコードに対する動的更新の要求
DNS サーバーは、自身の DNS データベース内の A リソース レコードを更新した後、DHCP サーバーに動的更新の応答を送信して、A リソース レコードを更新したことを DHCP サーバーに通知します (図 24 を参照) 。
図 24: A リソースレコードに対する動的更新の応答 DHCP-02-39
DHCP サーバーは優先 DNS サーバー SEA-NA-DC-01.noam.reskit.com に対して 52.8.16.172.in-addr.arpa の SOA リソース レコードについて照会して、FQDN に基づいた 52.8.16.172.in-addr.arpa の逆引き参照レコードの権威のあるサーバーおよび権威のあるゾーンを検索します (図 25 を参照) 。Windows NT 4.0 ベースのクライアントによってリースされた IP アドレスは 172.16.8.52 です。
図 25: 権威のあるサーバーおよび権威のあるゾーンを特定するための DNS SOA クエリ
図 26 で示すように、DNS サーバーは、52,8.16.172.in-addr.arpa の権威のあるゾーンと、権威のあるサーバー SEA-NA-DC-01.noam.reskit.com に関する NAME_ERROR および SOA の情報を応答します。この場合、権威のある DNS サーバーと優先 DNS サーバーは同じです。
図 26: クエリへの DNS 応答
図 27 で示すように DHCP サーバーは、権威のある DNS サーバーに動的更新の要求を送信し、Windows NT 4.0 ベースのクライアントのエントリ 52.8.16.172.in-addr.arpa を使用して PTR リソース レコードを更新することを要求します。
図 27: PTR リソースレコードの動的更新の要求
DNS サーバーは PTR リソース レコードを更新し、DHCP サーバーに動的更新の応答を送信して、DNS サーバーが Windows NT 4.0 ベースのクライアントの PTR リソース レコードを更新したことを DHCP サーバーに通知します (図 28 を参照) 。
図 28: PTR リソースレコードの動的更新の応答
Windows 2000 ベース クライアント向けのセキュリティで保護された動的更新
Windows 2000 ベースのクライアント向けのセキュリティで保護された動的更新は、Windows 2000 ベースのクライアント向けの動的更新とほぼ同様に機能します。Windows 2000 ベースのクライアントでは、DHCP によって IP アドレス リースを取得します。その後クライアントは、DNS データベースを更新する Windows 2000 DNS サーバーに A リソース レコードを含む動的更新メッセージを送信します。DHCP サーバーは、PTR リソース レコードを更新するために、DNS サーバーに動的更新メッセージを送信します。しかし、クライアント (Windows 2000 ベースのクライアントまたは DHCP サーバー) が署名された (保護された) 更新要求を送信するまで、動的更新メッセージは拒否されます。
以下の手順は、Windows 2000 ベース クライアント向けのセキュリティで保護された動的更新処理がどのように実行されるか、その詳細を示しています。
Windows 2000 ベースのクライアント SEA-NA-W2P-02.noam.reskit.com がネットワークに初めて接続すると、DHCP サーバーを特定するためにネットワーク上のすべてのコンピュータに DHCPDISCOVER メッセージをブロードキャストします。
Windows 2000 DHCP サーバー SEA-NA-DHCP-01.noam.reskit.com が DHCPDISCOVER メッセージを受け取ると、利用可能なリースがあるかどうか自身の DHCP データベースをチェックします。
リースが利用可能な場合、Windows 2000 ベースのクライアントに DHCPOFFER メッセージを送信します。この DHCPOFFER メッセージには、提供された IP アドレスと、サーバーでセットアップされているオプションの設定が含まれます。
Windows 2000 ベースのクライアントは、この情報を使用して DHCP サーバーを選択し (通常は最初に応答した DHCP サーバー) 、IP アドレス リースを受け取るために、提供された IP アドレスに対応する DHCPREQUEST メッセージを DHCP サーバーに送信します。このメッセージではまた、さまざまな DHCP オプションに関する情報が必要になります。このようなオプションのいくつかを以下の一覧に示します。
サブネット マスク
ルーター IP アドレス
ドメイン名 (接続固有の DNS サフィックス)
WINS サーバー リスト
DNS サーバー リスト
オプション 81 情報
オプション 81 には、クライアントの FQDN と、PTR リソース レコードの更新をクライアントのために代行することを DHCP サーバーに求める要求が含まれています。
DHCPREQUEST メッセージを受け取った DHCP サーバーは、クライアントに DHCPACK メッセージを送信することによって、DHCP サーバーがリースを発行したことをクライアントに通知し、クライアントから要求された DHCP オプションの情報をクライアントに提供して、DHCP サーバーが PTR リソース レコードの更新を試みることをオプション 81 を使用してクライアントに応答します。
クライアントは、DHCP サーバーに PTR レコードの更新を代行してほしいことをオプション 81 で示します。DHCP サーバーは、Windows 2000 ベースのクライアントの優先 DNS サーバー SEA-NA-DC-01.noam.reskit.com に DNS Start of Authority (SOA) クエリを送信することによって更新処理を開始し、FQDN に基づく逆引き参照レコード 55.8.16.172.in-addr.arpa の名前に対して権威のあるゾーンおよび権威のあるサーバーを検索します。Windows 2000 ベースのクライアントにリースされた IP アドレスは 172.16.8.55 です。
DNS サーバーは、8.16.172.in-addr.arpa の権威のあるゾーンと、権威のあるサーバー SEA-NA-DC-01.noam.reskit.com に関する NAME_ERROR および SOA の情報を応答します。この場合では、権威のある DNS サーバーと優先 DNS サーバーは同じです。
図 29 で示すように DHCP サーバーは、権威のある DNS サーバー SEA-NA-DC-01.noam.reskit.com に動的更新の要求を送信し、Windows 2000 ベースのクライアントのエントリ 55.8.16.172.in-addr.arpa を使用して PTR リソース レコードを更新することを要求します。
図 29: PTR リソースレコードの動的更新の要求
セキュリティで保護された動的更新向けにゾーンが構成されているので、DNS サーバーは DHCP サーバーに動的更新の応答を送信し、動的更新の要求を拒否することを通知します (図 30 を参照) 。
図 30: PTR リソースレコードの動的更新の要求の拒否
DHCP サーバーは、ネットワーク認証プロトコルとして Kerberos を使用するために DNS サーバーとネゴシエートします。
DHCP サーバーと DNS サーバーは Kerberos を使用して相互に身元を確認し、TKEY リソース レコードについて DNS クエリとその応答を送信することによって、セキュリティ コンテキストを確立します。
DHCP サーバーは、署名を含む TSIG リソース レコードの追加セクションの付加された新しい動的更新の要求を DNS サーバーに送信します (図 31 を参照) 。TKEY 交換中に確立したセキュリティ コンテキストは、TSIG リソース レコード内に署名を生成するキーとして使用されます。この要求は署名されているため、セキュリティで保護された動的更新の要求として認識されます。
図 31: PTR リソースレコードのセキュリティで保護された動的更新の要求
DNS サーバーは、セキュリティ コンテキストと TSIG リソース レコードを使用して、動的更新の要求元を確認します。DNS サーバーは、DNS データの格納された Active Directory をチェックして、DHCP サーバーが PTR リソース レコードを変更するための適切なアクセス許可を持つかどうか確認します。その後 DNS サーバーは、Windows 2000 ベースのクライアントの PTR リソース レコードを更新します。
DNS サーバーは、TSIG リソース レコードで署名された動的更新の応答を DHCP サーバーに送信して、DNS サーバーが PTR リソース レコードを更新したことを DHCP サーバーに通知します (図 32 を参照) 。
図 32: PTR リソースレコードのセキュリティで保護された動的更新の応答
Windows 2000 ベースのクライアントは、優先 DNS サーバー SEA-NA-DC-01.noam.reskit.com に名前 SEA-NA-W2P-02.noam.reskit.com に関する DNS SOA クエリを送信し、クライアントの名前に対して権威のあるサーバーと権威のあるゾーンを特定します。
DNS サーバーは、noam.reskit.com の権威のあるゾーンと、権威のあるサーバー SEA-NA-DC-01.noam.reskit.com に関する NAME_ERROR および SOA の情報を応答します。この場合、権威のある DNS サーバーと優先 DNS サーバーは同じです。
Windows 2000 ベースのクライアントは、権威のある DNS サーバー SEA-NA-DC-01.noam.reskit.com に動的更新の要求を送信し、Windows 2000 ベースのクライアント SEA-NA-W2P-02.noam.reskit.com の名前を IP アドレス 172.16.8.55 に割り当てている A リソース レコードを更新するように求めます。
図 33: A リソースレコードに対する動的更新の要求
セキュリティで保護された動的更新向けにゾーンが構成されているので、DNS サーバーは Windows 2000 ベースのクライアントに動的更新の応答を送信し、動的更新の要求を拒否することを通知します (図 34 を参照) 。
図 34: A リソースレコードの動的更新の要求の拒否
Windows 2000 ベースのクライアントは、ネットワーク認証プロトコルとして Kerberos を使用するために、DNS サーバーとネゴシエートします。
Windows 2000 ベースのクライアントと DNS サーバーは Kerberos を使用して相互に身元を確認し、TKEY リソース レコードについて DNS クエリとその応答を送信することによって、セキュリティ コンテキストを確立します。
Windows 2000 ベースのクライアントは、署名を含む TSIG リソース レコードの追加セクションの付加された新しい動的更新の要求を DNS サーバーに送信します (図 35 を参照) 。この要求は署名されているため、セキュリティで保護された動的更新の要求として認識されます。
図 35: A リソースレコードに対するセキュリティで保護された動的更新の要求
DNS サーバーは、セキュリティ コンテキストと TSIG リソース レコードを使用して、動的更新のメッセージの送信元を確認します。DNS サーバーは Active Directory をチェックし、クライアントが A リソース レコードを変更するための適切なアクセス許可を持っているかどうか確認します。その後 DNS サーバーは、Windows 2000 ベースのクライアントの A リソース レコードを更新します。
DNS サーバーは、TSIG リソース レコードで署名された動的更新の応答を Windows 2000 ベースのクライアントに送信して、DNS サーバーが A リソース レコードを更新したことをクライアントに通知します (図 36 を参照) 。
図 36: A リソースレコードに対するセキュリティで保護された動的更新の応答
注意
この例では、DHCP サーバーおよび Windows 2000 ベースのクライアントで、優先 DNS サーバーとして SEA-NA-DC-01.noam.reskit.com が構成されていて、代替 DNS サーバーが構成されていない場合を仮定しています。DHCP サーバーおよび Windows 2000 ベースのクライアントが A リソース レコードと PTR リソース レコードを更新する順序は、ネットワーク条件に応じて異なります。
実装した方法
ここで示すセットアップ手順は、導入実験のシナリオを構築し、ハードウェア、ソフトウェア、および管理面の権限に関する要件を考慮するときに使用したものです。
注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして示したものです。実際の各ネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、そのシナリオの機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。
管理者は、ここに記載したセットアップ手順で必要になる構成を各コンピュータで実行するための適切な権限を持たなければなりません。このシナリオのセットアップ手順で使用したアカウントについて説明しておきます。
このセットアップ手順では、以下の構成を仮定しています。
表 1 で示すように、すべてコンピュータ、ルーター、およびスイッチに適切なオペレーティング システムがインストールされています。
各コンピュータに適切な名前が付けられています。
各コンピュータで、管理者の権利とパスワードが必要です。通常 DHCP サーバーと DNS サーバーは、ローカルにセットアップされますが、中央で管理されます。
Reskit.com ドメインを作成するために、172.16.4 0/22 サブネット内にある DNS サーバーをもう 1 台使用していますが、ここでは触れません。このサーバーは、Active Directory をサポートするために使用しています。
シナリオ『Windows 2000 DNS の Active Directory サポートへの構成』で説明したように SEA-RK-DC-01.reskit.com が既にセットアップされていて、さらにゾーン 8.16.172.in-addr.arpa に対する権威を有するサーバーとして SEA-NA-DC-01.noam.reskit.com の委任がルート ゾーン カタログに追加されています。
必要に応じて、コンピュータがエンタプライズの残りの部分と通信するためのルーティングがセットアップされています。
これらのサーバーには、以下の IP アドレスが割り当てられています。
SEA-NA-DC-01.noam.reskit.com 172.16.8.11 SEA-NA-DHCP-01.noam.reskit.com 172.16.8.25
クライアント コンピュータの IP アドレスは DHCP サーバーによって割り当てられます。
注意
これらの IP アドレスは、プライベート ネットワーク用の IP アドレス空間内のアドレスです。これらの IP アドレスは、テスト環境またはファイアウォールの背後のプライベート ネットワーク内で使用できます。インターネットに接続したネットワークでは使用できません。詳細については、RFC 1918 を参照してください。
表 1 に、導入実験のこのシナリオを開発するために使用したハードウェアおよびソフトウェアのリストを示します。
表 1 動的更新およびセキュリティで保護された動的更新の導入実験で使用したコンポーネント
コンポーネント |
ハードウェア |
ソフトウェア |
---|---|---|
Seattle スイッチ SEA-NA-CISCO-03. |
Cisco 6006 レイヤ 3 スイッチ |
Cisco IOS version 12.1 (1) E |
Seattle DHCP サーバー SEA-NA-DHCP-01. |
Compaq ProLiant コンピュータ |
Microsoft® Windows® 2000 Server DHCP サービス |
Seattle DNS サーバー SEA-NA-DC-01. |
Compaq ProLiant コンピュータ |
Windows 2000 Server DNS service DC サービス |
Windows 2000 ベースのクライアント SEA-NA-W2P-02. |
Compaq Desktop コンピュータ |
Windows 2000 Professional |
Windows NT 4.0 ベースのクライアント SEA-NA-NT4-01. |
Compaq Desktop コンピュータ |
Windows NT 4.0 Workstation |
セットアップ手順
このシナリオで動的更新を導入するために、以下の作業を実施しました。
セキュリティで保護された動的更新のための構成と、動的更新のための構成はほぼ同じですが、セキュリティで保護された動的更新は DNS ゾーン上で有効にする点が異なります。
このシナリオでセキュリティで保護された動的更新を導入するために、以下の作業を実施しました。
図 37 は、このシナリオで使用したネットワーク全体のレイアウトを示しています。
図 37: Seattle サブネットのインフラストラクチャ
その他の参考資料
このシナリオに関する情報について、以下の資料が参考になります。
導入実験のシナリオ
DHCP について詳しくは、導入実験のシナリオの『複数のサブネット環境のための DHCP 構成』を参照してください。
DNS および Active Directory のセットアップについて詳しくは、導入実験のシナリオの『Windows 2000 DNS の Active Directory サポートへの構成』を参照してください。
Windows 2000 リソースキット
以下は、『Microsoft Windows 2000 Professional リソース キット』および『Microsoft Windows 2000 Server リソース キット』の参考資料です。オンラインで概要を参照できる章もあります。
DHCP について詳しくは、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 4 章 DHCP (動的ホスト構成プロトコル) 」を参照してください。
DNS について詳しくは、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 6 章 Windows 2000 DNS () 」 (英語) を参照してください。
ツール
Ipconfig
Ipconfig は、ローカル コンピュータまたはネットワーク上のリモート コンピュータ上で構成された TCP/IP パラメータに関する情報を取得する TCP/IP コマンドライン ユーティリティです。Ipconfig コマンドの使用方法について詳しくは、コマンド プロンプトで ipconfig /? と入力してください。
Netdiag
Netdiag は、ネットワーク クライアントの状態を確認し、それが機能しているかどうかを特定する一連のテストを実行することによって、ネットワーク機能の問題と接続の問題を分離できるユーティリティです。Netdiag について詳しくは、Windows 2000 Support Tools のヘルプを参照してください。
Windows 2000 Support Tools および Support Tools ヘルプをインストールし、使用する方法については、Windows 2000 オペレーティング システム CD-ROM の \Support\Tools フォルダ内のファイル Sreadme.doc (英語) を参照してください。
Dnscmd.exe
Dnscmd.exe を使用すれば、[DNS] スナップインで実行する大半の作業を行うことができます。Dnscmd.exe について詳しくは、Windows 2000 Support Tools のヘルプを参照してください。
Windows 2000 Support Tools および Support Tools ヘルプをインストール、使用する方法については、Windows 2000 オペレーティング システム CD-ROM の \Support\Tools フォルダ内のファイル Sreadme.doc (英語) を参照してください。
Requests for Comments (RFC)
DHCP について詳しくは、RFC Editor Web サイト (英語) の RFC 2131、「Dynamic Host Configuration Protocol」を参照してください 。
動的更新について詳しくは、RFC Editor Web サイト (英語) の RFC 2136、「Dynamic Updates in the Domain Name System (DNS UPDATE) 」を参照してください 。
導入実験の詳細と協力企業について
- 導入実験、および導入実験に提供されたハードウェアに関する情報については、『導入実験のハードウェア仕様』を参照してください。
リソースキット導入実験シナリオの凡例
- Microsoft Windows 2000 リソース キット導入実験シナリオのネットワーク図で使用されている略語や記号について詳しくは、『導入実験シナリオの凡例』を参照してください。
リソースキット導入実験のネットワーク図
- ネットワークの設計、ネットワーク ルーティング設計、ドメイン ネーム システム (DNS) 設計、および Active Directory 階層の高水準の編成については、『導入実験のネットワーク図』を参照してください。
関連資料
Windows 2000 Server リソース キット 購入ページ
Windows 2000 Professional リソース キット 購入ページ
Windows 2000 リソース キットの詳細については、こちらを参照してください。
注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。