次の方法で共有

動的更新

動的更新を使用すると、DNS クライアント コンピュータは、変更が発生するたびに DNS サーバーにリソース レコードを登録および更新できます。 この機能により、特に頻繁に場所を移動または変更し、DHCP を使用して IP アドレスを取得するクライアントの場合、ゾーン レコードを手動で管理する必要性が軽減されます。

DNS クライアントおよびサーバー サービスは、 RFC 2136 で説明されているように、動的更新をサポートします。 DNS サーバー サービスでは、ゾーンごとに動的更新を有効または無効にできます。 既定では、Windows Server DNS クライアント サービスは、TCP/IP 用に構成されている場合、DNS のホスト (A) リソース レコードを動的に更新します。 DNS サーバー サービスは、既定では、セキュリティで保護された動的更新のみを許可するように構成されています。

プロトコルの概要

RFC 2136 では、 UPDATE メッセージ形式が導入されており、前提条件を確認しながら、指定したゾーン内のリソース レコードを追加および削除できます。 更新はアトミックであり、更新が行われるにはすべての条件が満たされている必要があります。

ゾーンの更新は、そのゾーンのプライマリ DNS サーバーでコミットする必要があります。 セカンダリ DNS サーバーは、レプリケーション トポロジを使用して、プライマリ DNS サーバーに到達するまで更新を転送します。 Active Directory 統合ゾーンを使用すると、ゾーン内のリソース レコードの更新を、データ ストアにゾーンが含まれている Active Directory ドメイン コントローラーで実行されている任意の DNS サーバーに送信できます。

ゾーン転送プロセスが開始されると、ゾーンはロックされます。 このロックにより、セカンダリ DNS サーバーは、データの転送中にゾーンの一貫したビューを受け取ることができます。 この間、ゾーンは動的更新を受け入れることができません。 ゾーンが大きく、転送のために頻繁にロックされると、動的更新クライアントが不足し、システムが不安定になる可能性があります。 この問題を回避するために、Windows Server DNS サーバー サービスは、ゾーン転送中に到着する更新要求をキューに入れ、転送の完了後に処理します。

コンピュータがDNS名を更新する方法

既定では、TCP/IP 用に静的に構成されているコンピューターは、インストールされているネットワーク接続によって構成および使用される IP アドレスのホスト (A) およびポインター (PTR) リソース レコードを動的に登録しようとします。 すべてのコンピュータは、FQDN に基づいてレコードを登録します。

DNS クライアントは、次の項目の動的更新を試みません。

  • リモート アクセスまたは仮想プライベート ネットワーク (VPN) 接続経由。 この構成を変更するには、特定のネットワーク接続の高度な TCP/IP 設定を変更するか、レジストリを変更します。

  • トップレベル ドメイン (TLD) ゾーン。 単一ラベル名で名前が付けられたゾーン ( com、 edu、 blank、 my-company など) は TLD ゾーンと見なされます。

また、既定では、コンピュータの FQDN のプライマリ DNS サフィックス部分は、コンピュータが参加している Active Directory ドメインの名前と同じです。 ドメイン管理者は、異なるプライマリ DNS サフィックスを許可するために、ドメイン オブジェクト コンテナー内の msDS-AllowedDNSSuffixes 属性を変更することで、許可されるサフィックスの制限付きリストを作成できます。 ドメイン管理者は、Active Directory サービス インターフェイス (ADSI) またはライトウェイト ディレクトリ アクセス プロトコル (LDAP) を使用して属性を管理できます。 動的更新は、次のいずれかの理由またはイベントで送信できます。

  • インストールされているいずれかのネットワーク接続の TCP/IP プロパティ構成で、IP アドレスが追加、削除、または変更されます。
  • 起動時、コンピューターの電源がオンになったとき。
  • メンバー サーバーはドメイン コントローラーに昇格されます。
  • IP アドレスのリースは、インストールされているネットワーク接続のいずれかを変更または更新します (たとえば、コンピュータの起動時や ipconfig /renew コマンドの使用時)。
  • ipconfig /registerdns コマンドは、DNS のクライアント名登録を手動で強制的に更新するために使用されます。

Important

ipconfig /registerdns を使用すると、DNS クライアント サービスは DHCP サーバーをバイパスして、DNS レコードを直接登録しようとします。 この登録は、DHCP サーバーが DNS A レコードと PTR レコードを常に動的に更新するように構成されている場合でも行われます。 クライアントにリソース レコードを更新するアクセス許可がない場合、登録はサイレントに失敗します。 DNS クライアントにこのアクセス許可がある場合は、リソース レコードが更新されます。 アクセス許可をリセットして、DHCP サーバーがリソース レコードに対して将来の更新を実行できなくなるようにすることができます。
Windows を実行している DHCP クライアントの DNS 登録を更新するには、 ipconfig /renew を使用することをお勧めします。 ipconfig /registerdnsは使用しないでください。

上記のいずれかのイベントによって動的更新がトリガーされると、DNS クライアント サービスから更新が送信されます。 このトリガは、IP アドレス情報に変更が加えられた場合に、DNS で対応する更新が実行され、コンピュータの名前とアドレスのマッピングが同期されるように設計されています。 DNS クライアント サービスは、DHCP を使用するように構成されていない接続を含め、システムで使用されるすべてのネットワーク接続に対してこの機能を実行します。

この更新プロセスでは、Windows Server を実行しているサーバーに対してインストールの既定値が有効であることを前提としています。 特定の名前と更新動作は、既定以外の DNS 設定を使用するように拡張 TCP/IP プロパティが構成されている場合に調整できます。

コンピュータの完全なコンピュータ名 (またはプライマリ名) に加えて、接続固有の DNS 名を構成し、必要に応じて DNS に登録または更新できます。

動的更新のしくみ

動的更新は、通常、コンピューター上で DNS 名または IP アドレスが変更されたときに要求されます。 たとえば、 oldhost という名前のクライアントが最初に次の名前で構成されているとします。

  • コンピューター名: oldhost
  • DNS ドメイン名: example.contoso.com
  • 完全なコンピューター名: oldhost.example.contoso.com

この例では、コンピューターに対して接続固有の DNS ドメイン名は構成されていません。 その後、コンピュータの名前が oldhost から newhost に変更され、システムの名前が次のように変更されます。

  • コンピューター名: newhost
  • DNS ドメイン名: example.contoso.com
  • 完全なコンピューター名: newhost.example.contoso.com

名前の変更が [システムのプロパティ] に適用されると、コンピューターを再起動するように求められます。 コンピュータが Windows を再起動すると、DNS クライアント サービスは次のシーケンスを実行して DNS を更新します。

  1. DNS クライアント サービスは、コンピューターの DNS ドメイン名を使用して SOA タイプのクエリを送信します。

    クライアント コンピューターは、このクエリで指定された名前として、コンピューターの現在構成されている FQDN (newhost.example.contoso.comなど) を使用します。

  2. クライアント FQDN を含むゾーンの権限のある DNS サーバーは、SOA タイプのクエリに応答します。

    標準のプライマリ・ゾーンの場合、SOA問合せレスポンスで返されるプライマリ・サーバー(所有者)は固定で静的です。 これは、ゾーンと共に格納されている SOA リソース レコードに表示される正確な DNS 名と常に一致します。 更新されるゾーンがディレクトリ統合されている場合、FQDN の Active Directory ドメインのドメイン コントローラーで実行されている任意の DNS サーバーが応答できます。 SOAクエリ応答にゾーンのプライマリサーバー(所有者)として独自の名前を動的に挿入できます。

  3. その後、DNS クライアント サービスはプライマリ DNS サーバーへの接続を試みます。

    クライアントは、その名前に対する SOA クエリ応答を処理して、その名前を受け入れるためのプライマリ サーバーとして承認された DNS サーバーの IP アドレスを決定します。 次に、必要に応じて次の一連の手順を実行して、プライマリ サーバーに接続し、動的に更新します。

    • SOA クエリ応答で決定されたプライマリ サーバーに動的更新要求を送信します。
    • 更新が成功した場合、それ以上のアクションは実行されません。
    • この更新が失敗した場合、クライアントは次に、SOA レコードで指定されたゾーン名に対して NS タイプのクエリを送信します。
    • このクエリに対する応答を受信すると、応答にリストされている最初の DNS サーバーに SOA クエリを送信します。

    SOA クエリが解決されると、クライアントは、返された SOA レコードで指定されたサーバーに動的更新を送信します。

    • 更新が成功した場合、それ以上のアクションは実行されません。
    • この更新が失敗した場合、クライアントは、応答にリストされている次のDNSサーバーに要求を送信して、SOAクエリプロセスを繰り返します。

  4. 更新を実行できる DNS サーバーに接続した後、クライアントは更新要求を送信し、DNS サーバーは更新要求を処理します。

    更新要求の内容には、 newhost.example.contoso.com の A (場合によっては PTR) リソース レコードを追加し、以前に登録された名前である oldhost.example.contoso.com のこれらの同じレコードの種類を削除する指示が含まれています。

    また、DNS サーバーは、クライアント要求に対して更新が許可されていることも確認します。 標準のプライマリ ゾーンの場合、動的更新はセキュリティで保護されないため、クライアントの更新の試行はすべて成功します。 Active Directory 統合ゾーンの場合、更新はセキュリティで保護され、ディレクトリ ベースのセキュリティ設定を使用して実行されます。 詳細については、この記事で後述する「セキュリティで保護された動的更新」セクションを参照してください。

動的更新は定期的に送信または更新されます。 既定では、コンピューターは 7 日ごとに更新を送信します。 更新によってゾーン データに変更がなかった場合、ゾーンは現在のバージョンのままで、変更は書き込まれません。 更新により、名前またはアドレスが変更された場合にのみ、ゾーンが変更されたり、ゾーン転送が増加したりします。

名前が非アクティブになったり、更新間隔 (7 日間) 内に更新されなくなったりした場合、名前は DNS ゾーンから削除されません。 DNSには、名前をリリースしたり、廃棄したりするためのメカニズムはありません。 ただし、DNS クライアントは、新しい名前が適用されると、古い名前レコードを削除しようとします。 DNS クライアントは、アドレスが変更されたときにも名前レコードの更新を試みます。

DNS クライアント サービスは、コンピューターの A リソース レコードと PTR リソース レコードを登録するときに、ホスト レコードの既定のキャッシュである Time To Live (TTL) を 15 分使用します。 この TTL は、他の DNS サーバーとクライアントがクエリ応答に含まれるときに、コンピューターのレコードをキャッシュする時間を決定します。

Time to Live

動的更新クライアントが DNS に登録されるたびに、関連付けられている A および PTR リソース レコードには Time to Live (TTL) が含まれます。 デフォルトでは、Netlogon サービスによって登録されたレコードの TTL は 10 分に設定されています。 DHCP クライアント サービスによって登録されたレコードの場合、TTL は 15 分に設定されます。 DNS サーバー サービスが独自のゾーンのレコードを動的に登録する場合、既定の TTL は 20 分です。 レジストリのデフォルト設定を変更できます。 値を小さくすると、キャッシュされたエントリの有効期限が短くなり、DNS トラフィックは増加しますが、キャッシュされたレコードが古くなるリスクは減少します。 エントリの有効期限を早めると、DHCP リースを頻繁に更新するコンピュータに役立ちます。 保持期間が長いと、DHCP リースを頻繁に更新しないコンピューターに役立ちます。

名前の競合の解決

DNS クライアント サービスが A レコードを登録しようとすると、権限のある DNS ゾーンに、同じ名前で異なる IP アドレスの A レコードが既に含まれているかどうかを確認します。 デフォルトでは、DNS Client サービスは、既存の A レコードを、DNS クライアントの IP アドレスを含む新しい A レコードに置き換えようとします。 その結果、セキュリティで保護された動的更新が使用されていない限り、ネットワーク上の任意のコンピューターが既存の A レコードを変更できます。 セキュアな動的更新用に構成されたゾーンでは、許可されたユーザーのみがリソース レコードを変更できます。

既定の設定を変更して、DNS クライアント サービスが登録プロセスを終了し、既存の A レコードを置き換える代わりにイベント ビューアにエラーを記録するようにすることができます。 詳細については、この記事で後述する「セキュリティで保護された動的更新」セクションを参照してください。

DNS と DHCP

Windows DNS クライアントは動的更新に対応しており、動的更新プロセスを開始できます。 DNS クライアントは、クライアントが IP アドレスをリースするか、リースを更新するときに、DHCP サーバーと動的更新のプロセスをネゴシエートします。 このネゴシエーションは、クライアントの A リソースレコードと PTR リソースレコードを更新するコンピュータを決定します。 DNS クライアントと DHCP サーバーは、レコードを更新するユーザーをネゴシエートします。 クライアントとサーバーは、更新する名前に対して権限を持つプライマリ DNS サーバーに動的更新要求を送信します。

Windows Server DHCP サーバー サービスでは、DHCP クライアント サービスの FQDN オプションをサポートしていないクライアントの DNS レコードを更新できます。 この機能は、DHCP コンソールのサーバー プロパティの [DNS ] タブで有効にすることができます。 DHCP サーバーは、最初に DHCP REQUEST パケットからレガシ クライアントの名前を取得します。 次に、そのスコープに指定されたドメイン名を追加し、A リソースレコードと PTR リソースレコードを登録します。

場合によっては、DHCP クライアントのリースの有効期限が切れると、古い PTR または A リソース レコードが DNS サーバーに表示されることがあります。 たとえば、DNS クライアントが DHCP サーバーと動的更新手順をネゴシエートしようとすると、DNS クライアントは A リソース レコードと PTR リソース レコードの両方を自身で登録する必要があります。 後で、クライアントがネットワークから不適切に削除された場合、クライアントは A および PTR リソース レコードを登録解除できなくなり、古いレコードになります。

セキュリティで保護された動的更新のみを許可するゾーンに古い A リソース レコードが表示されている場合、その A リソース レコードの名前に他のリソース レコードを登録できるコンピューターはありません。 古い PTR および A リソース レコードの問題を防ぐために、エージングと清掃機能を有効にできます。 エージングと清掃機能の詳細については、「DNS のエージングと清掃」を参照してください。

動的更新のフォールト トレランスを提供するには、Windows クライアントからの動的更新を受け入れるゾーンの Active Directory 統合を検討してください。 権限のある DNS サーバーの検出を高速化するために、各クライアントを、そのディレクトリ統合ゾーンのプライマリである優先 DNS サーバーと代替 DNS サーバーの一覧で構成できます。 DNS サーバーが使用できないために、クライアントが優先 DNS サーバーでゾーンを更新できなかった場合、クライアントは別のサーバーを試すことができます。 優先 DNS サーバーが使用可能になると、クライアントからの更新を含む、更新されたディレクトリ統合ゾーンが読み込まれます。

動的更新プロセス

このセクションでは、DHCP クライアント、静的に構成されたクライアント、リモート アクセス クライアント、およびマルチホーム クライアントの動的更新プロセスについて説明します。

DHCP クライアント プロセス

動的更新プロセスを開始するために、DHCP クライアントは、DHCP クライアント サービスの FQDN オプションを使用して、 DHCPREQUEST パケットで FQDN を DHCP サーバーに送信します。 その後、DHCP サーバーは、FQDN オプション (オプション コード 81) を含む DHCP 確認 (DHCPACK) メッセージを送信して、DHCP クライアントに応答します。

次の表に、 DHCPREQUEST パケットの FQDN オプションのフィールドを示します。

Field Explanation
Code このオプションのコードを指定します (81)。
Len このオプションの長さをオクテット単位で指定します (最小 4)。
Flags 値は、次のいずれかです。

0. クライアントは A リソース レコードを登録する必要があり、サーバーに PTR リソース レコードを更新するように要求します。

1. クライアントは、サーバーに A および PTR リソース レコードを登録することを要求します。

3. DHCPサーバは、クライアントの要求に関係なく、AおよびPTRリソースレコードを登録します。
RCODE1 と RCODE2 DHCP サーバーは、これらのフィールドを使用して、クライアントに代わって実行された A および PTR リソース レコード登録からの応答コードを指定し、 DHCPACKを送信する前に更新を試みたかどうかを示します。
ドメイン名 クライアントの FQDN を指定します。

DHCP クライアントが FQDN オプションを送信する条件は、クライアントが実行しているオペレーティング システムとクライアントの構成方法によって異なります。 DHCP サーバーによって実行されるアクションは、サーバーが実行しているオペレーティング システムとサーバーの構成方法によっても異なります。

デフォルトでは、Windows DHCP クライアントサービスは次のプロセスを使用します。

  1. Windows DHCP クライアント サービスは、フラグ フィールドを 0 に設定した FQDN オプションを送信します。 このフラグは、クライアントが A リソース レコードを更新し、DHCP サーバー サービスが PTR リソース レコードを更新するように要求します。

  2. クライアントは、DHCP サーバーからの応答を待ちます。 DHCP サーバーが Flags フィールドを 3 に設定しない限り、DNS クライアントは A リソース レコードの更新を開始します。

  3. DHCP サーバーが DNS レコードの登録をサポートしていないか、DNS レコードの登録用に構成されていない場合、FQDN は応答に含まれません。 この場合、DNS クライアントは A リソースレコードと PTR リソースレコードの登録を試みます。

DHCP クライアントが要求する内容に応じて、DHCP サーバーは異なるアクションを実行できます。

DHCP クライアントが FQDN オプションを使用せずに DHCPREQUEST メッセージを送信する場合、動作は DHCP サーバーのタイプとその構成によって異なります。 DHCP サーバーは、FQDN オプションをサポートしていない DHCP クライアントの代わりにレコードを更新するように構成した場合、両方のレコードを更新します。

次の場合、DHCP サーバーはアクションを実行しません。

  • DHCP サーバーは動的更新をサポートしていません。

  • DHCP サーバーは、FQDN オプションをサポートしていないクライアントに対して動的更新を行わないように構成されています。

  • DHCP サーバーは、DNS リソース レコードを登録しないように構成されています。

Windows DHCP クライアントが、サーバーに PTR リソース レコードの更新を要求し、A リソース レコードの更新を要求しない場合、動作は DHCP サーバーの種類とその構成によって異なります。

サーバーは、次のアクションを実行できます。

  • Windows DHCP サーバーが動的更新を実行しないように構成されている場合、応答に FQDN オプションは含まれません。 また、どちらのリソースレコードも更新されません。 この場合、DNS クライアントは、対応可能な場合は A リソース レコードと PTR リソース レコードの両方を更新しようとします。

  • Windows DHCP サーバーが DHCP クライアントの要求に従って更新するように構成されている場合、サーバーは PTR リソース レコードの更新を試みます。 DHCP サーバーは、DHCP クライアントに DHCPACK メッセージを送信します。 このメッセージには、[フラグ] フィールドが 0 に設定された FQDN オプションが含まれています。 DHCPACK メッセージは、DHCP サーバーが PTR レコードを更新することを確認します。 その後、DNS クライアントは、対応可能な場合は A リソース レコードの更新を試みます。

  • DHCP サーバーが A レコードと PTR レコードの両方を常に更新するように構成されている場合、DHCP サーバーは両方のリソース レコードの更新を試みます。 DHCP クライアントへの DHCP サーバー DHCPACK メッセージには、フラグ フィールドが 3 に設定された FQDN オプションが含まれており、DHCP サーバーが A レコードと PTR レコードを更新することを DHCP クライアントに通知します。 この場合、DNS クライアントはどちらのリソース レコードも更新しようとしません。

静的に設定されたリモートアクセスクライアントプロセス

静的に構成されたクライアントとリモート アクセス クライアントは、DNS 登録のために DHCP サーバーに依存しません。 静的に構成されたクライアントは、開始するたびに A リソースレコードと PTR リソースレコードを動的に更新します。 また、クライアントは 24 時間ごとに更新され、DNS データベース内のレコードが更新されます。

リモート アクセス クライアントは、ダイヤルアップ接続が確立されたときに、A リソースと PTR リソース レコードを動的に更新できます。 また、ユーザーが明示的に接続を閉じたときに、A および PTR リソース レコードの取り消しまたは登録解除を試みることもできます。 リモート アクセス ネットワーク接続を使用して Windows Server を実行しているコンピューターは、この接続の IP アドレスの A レコードと PTR レコードを動的に登録しようとします。 既定では、Windows クライアント上の DNS クライアント サービスは、リモート アクセスまたは VPN 接続経由で動的更新を試みません。 この構成を変更するには、特定のネットワーク接続の高度な TCP/IP 設定を変更するか、レジストリを変更します。

すべてのオペレーティング システムで、リモート アクセス クライアントが DNS リソース レコードの登録解除の試行から正常な応答を受け取らなかった場合、またはその他の理由でリソース レコードの登録解除が 4 秒以内に失敗した場合、DNS クライアントは接続を閉じます。 このような場合、DNS データベースに古いレコードが含まれている可能性があります。

リモート アクセス クライアントが DNS リソース レコードの登録解除に失敗した場合、イベント ログにメッセージが追加され、イベント ビューアを使用して表示できます。 リモート アクセス クライアントは古いレコードを削除しませんが、クライアントが切断されると、リモート アクセス サーバーは PTR リソース レコードの登録解除を試みます。

既定では、Windows DNS クライアント サービスは、ダイヤルアップ接続の A レコードと PTR レコードを自動的に更新しようとはしません。

マルチホーム クライアント プロセス

動的更新クライアントがマルチホームの場合、つまり、クライアントが複数のネットワーク接続と関連付けられた IP アドレスを持つ場合、ネットワーク接続ごとにすべての IP アドレスが登録されます。 これらの IP アドレスを登録しない場合は、IP アドレスを登録しないようにネットワーク接続を構成できます。

動的更新クライアントは、コンピューターが接続されているすべての名前空間の DNS サーバーにすべての IP アドレスを登録するわけではありません。 たとえば、マルチホーム コンピューター client1.example.contoso.com は、インターネットと企業イントラネットの両方に接続されています。 クライアントは、IP アドレスが 172.16.8.7 の DHCP アダプターであるアダプター A によってイントラネットに接続されます。 クライアントは、IP アドレスが 10.3.3.9 のリモート アクセス アダプターであるアダプター B によってもインターネットに接続されます。 クライアントは、イントラネット上のネーム・サーバーを使用してイントラネット名を解決し、インターネット上のネーム・サーバーを使用してインターネット名を解決します。

セキュアな動的更新

DNS 更新セキュリティは、Active Directory に統合されているゾーンでのみ使用できます。 ゾーンを Active Directory に統合すると、DNS コンソールでアクセス制御リスト (ACL) を使用して、指定したゾーンまたはリソース レコードの ACL にユーザーとグループを追加または削除できます。 ACL は DNS 管理アクセス制御専用であり、DNS クエリの解決には影響しません。

既定では、DNS サーバーとクライアントの動的更新セキュリティは次のように処理されます。

  • DNS クライアントは、最初にセキュリティで保護されていない動的更新を使用しようとします。 セキュリティで保護されていない更新プログラムが拒否された場合、クライアントはセキュリティで保護された更新プログラムを使用しようとします。

    デフォルトの更新ポリシーでは、ブロックされていない限り、クライアントは以前に登録されたリソース レコードの上書きを試みることができます。

  • ゾーンが Active Directory に統合されると、Windows Server を実行している DNS サーバーは、既定でセキュリティで保護された動的更新のみを許可します。

    ファイルベースのゾーン記憶域を使用する場合、DNS サーバー サービスの既定では、ゾーンの動的更新は許可されません。 ディレクトリ統合ゾーンまたは標準のファイルベースストレージを使用するゾーンの場合は、すべての動的更新を許可するようにゾーンを変更できます。 この設定により、すべての更新が受け入れられます。

動的更新は、 RFC 2136 で定義されている DNS 標準仕様に追加されています。

DNS リソース レコードの動的登録は、レジストリ エントリを使用して制限できます。

セキュアな動的更新の仕組み

セキュアな動的更新プロセスについては、次のように説明します。

  1. セキュリティで保護された動的更新を開始するために、DNS クライアントは最初にセキュリティ コンテキスト ネゴシエーション プロセスを開始し、その間にトークンは TKEY リソース レコードを使用してクライアントとサーバー間で渡されます。 ネゴシエーション・プロセスの最後に、セキュリティ・コンテキストが確立されます。

  2. DNS クライアントは、動的更新要求を DNS サーバーに送信します。 この要求には、データを追加、削除、または変更するためのリソース レコードが含まれています。

    1. 要求は、以前に確立されたセキュリティ コンテキストを使用して署名されます。

    2. 署名は、動的更新パケットに含まれる TSIG リソース レコードで渡されます。

  3. サーバーは、クライアントの資格情報を使用して Active Directory の更新を試み、更新の結果をクライアントに送信します。 これらの結果も、セキュリティコンテキストと、レスポンスに含まれる TSIG リソースレコードに渡された署名を使用して署名されます。

安全な動的更新プロセス

セキュアな動的更新プロセスについては、次のように説明します。

  1. DNS クライアントは、優先 DNS サーバーにクエリを実行して、更新しようとしているドメイン名に対して権限のある DNS サーバーを特定します。 優先 DNS サーバーは、ゾーンの名前と、そのゾーンに対して権限のあるプライマリ DNS サーバーで応答します。

  2. DNS クライアントは標準の動的更新を試行し、ゾーンがセキュリティで保護された動的更新のみを許可するように構成されている場合 (Active Directory 統合ゾーンの既定の構成)、DNS サーバーはセキュリティで保護されていない更新を拒否します。 ゾーンがセキュリティで保護された動的更新ではなく標準の動的更新用に構成されている場合、DNS サーバーは、そのゾーン内のリソース レコードを追加、削除、または変更しようとする DNS クライアントの試行を受け入れます。

  3. DNS クライアントと DNS サーバーは TKEY ネゴシエーションを開始します。

    1. DNS クライアントと DNS サーバーは、基になるセキュリティ メカニズムをネゴシエートします。 Windows 動的更新クライアントと DNS サーバーは、Kerberos プロトコルのみを使用できます。

    2. セキュリティ メカニズムを使用して、DNS クライアントと DNS サーバーはそれぞれの ID を確認し、セキュリティ コンテキストを確立します。

  4. DNS クライアントは、確立されたセキュリティ コンテキストを使用して署名された動的更新要求を DNS サーバーに送信します。 署名は、動的更新要求パケットに含まれる TSIG リソース・レコードの署名フィールドに含まれます。 DNS サーバーは、セキュリティ コンテキストと TSIG 署名を使用して、動的更新パケットの発信元を確認します。

  5. DNS サーバーは、Active Directory のリソース レコードの追加、削除、または変更を試みます。 更新は、DNS クライアントに適切なアクセス許可があるかどうか、および前提条件が満たされているかどうかによって異なります。

  6. DNS サーバーは、確立されたセキュリティ コンテキストを使用して署名された更新を行うことができたかどうかを示す応答を DNS クライアントに送信します。 署名は、動的更新応答パケットに含まれる TSIG リソース・レコードの署名フィールドに含まれます。 DNS クライアントは、スプーフィングされた応答を受信した場合、それを無視して署名された応答を待ちます。

FQDN オプションをサポートしていない DHCP クライアントのセキュリティ

FQDN オプション (オプション 81) をサポートしていない Windows DHCP クライアントは、動的更新に対応していません。 これらのクライアントの A リソース レコードと PTR リソース レコードを DNS に動的に登録する場合は、クライアントに代わって動的更新を実行するように DHCP サーバーを構成する必要があります。

FQDN オプションをサポートしていない DHCP クライアントの代わりに DHCP サーバーにセキュリティで保護された動的更新を実行させるには、アクセス許可の問題を回避するために追加の構成が必要です。 DHCP サーバーが名前に対してセキュリティで保護された動的更新を実行すると、その名前の所有者になります。 その名前のレコードを更新できるのは、その DHCP サーバーだけです。

たとえば、DHCP サーバー DHCP1 が host1.example.com という名前のオブジェクトを作成し、その後応答を停止し、後でバックアップ DHCP サーバー DHCP2 が同じ名前 host1.example.com のレコードを更新しようとしたとします。 この状況では、DHCP2 は名前を所有していないため、名前を更新できません。

この問題を回避するには、 DnsUpdateProxy という組み込みのセキュリティ グループを使用します。 すべての DHCP サーバーを DnsUpdateProxy グループのメンバーとして追加すると、最初のサーバーで障害が発生した場合に、別のサーバーで 1 つのサーバーのレコードを更新できます。 また、DnsUpdateProxy グループのメンバーによって作成されたすべてのオブジェクトはセキュリティで保護されていないため、DNS 名に関連付けられているレコードのセットを最初に変更したユーザーがその所有者になります。 レガシ クライアントがアップグレードされると、DNS サーバーで名前レコードの所有権を取得できます。 古いクライアントのリソース レコードを登録するすべての DHCP サーバーが DnsUpdateProxy グループのメンバーである場合、前に説明した問題は発生しません。

DnsUpdateProxy グループを使用したレコードの保護

DHCP サーバーが DnsUpdateProxy グループのメンバーである場合、登録した DNS ドメイン名はセキュリティで保護されません。 そのため、グループのメンバーによって作成されたレコードをセキュリティで保護するための追加の手順を実行せずに、セキュリティで保護された動的更新のみを許可する Active Directory 統合ゾーンでは、このグループを使用しないでください。

セキュリティで保護されていないレコードから保護するか、DnsUpdateProxy グループのメンバーがセキュリティで保護された動的更新のみを許可するゾーンにレコードを登録できるようにするには、専用のユーザー アカウントを作成します。 このユーザーアカウントの資格情報を使用して、DNS動的更新を実行するようにDHCPサーバーを構成します。 複数の DHCP サーバーが、1 つの専用ユーザー アカウントの資格情報を使用できます。

専用ユーザーアカウントは、DNS 動的更新登録用の資格情報を DHCP サーバーに提供するためだけに使用される標準ユーザーアカウントです。 各 DHCP サーバーは、DNS 動的更新を使用して DHCP クライアントの代わりに名前を登録するときに、これらの資格情報を提供します。 専用ユーザー アカウントは、更新するゾーンのプライマリ DNS サーバーが存在するのと同じフォレストに作成されます。 専用ユーザー アカウントは、更新するゾーンのプライマリ DNS サーバーを含むフォレストとの間にフォレストの信頼が確立されている限り、そのユーザー・アカウントが存在するフォレストに別のフォレストに配置することもできます。

ドメイン コントローラにインストールすると、DHCP サーバー サービスはドメイン コントローラのセキュリティ アクセス許可を継承します。 つまり、セキュリティで保護された Active Directory 統合ゾーンに登録されている任意の DNS レコードを更新または削除する権限があります。 Windows Server を実行している他のコンピューター (ドメイン コントローラーなど) は、これらのレコードを安全に登録します。 ドメイン コントローラにインストールする場合は、専用ユーザー アカウントの資格情報を使用して DHCP サーバーを構成し、サーバーがドメイン コントローラの特権を継承したり、誤用されたりしないようにします。

次の状況では、専用のユーザー アカウントを構成し、アカウント資格情報を使用して DHCP サーバー サービスを構成します。

  • ドメイン コントローラは、DHCP サーバーとして機能するように構成されています。
  • DHCP サーバーは、DHCP クライアントの代わりに DNS 動的更新を実行するように構成されています。
  • DHCP サーバーは、セキュリティで保護された動的更新のみを許可するように構成された DNS ゾーンを更新します。

専用ユーザーアカウントを作成したら、DHCP コンソールまたはコマンド netsh dhcp server set dnscredentials を使用して、ユーザーアカウントの資格情報を使用して DHCP サーバーを構成できます。

Note

  • 指定された資格情報が DnsUpdateProxy セキュリティ グループのメンバーであるオブジェクトに属している場合、DNS に同じ名前のレコードを登録する次のオブジェクトがレコードの所有者になります。

  • DHCP クライアント コンピューターを DNS に登録するときに使用する DHCP サーバーの資格情報を指定した場合、これらの資格情報はバックアップされません。 DHCP データベースを復元した後、新しい資格情報を構成する必要があります。

  • Last updated on