端末からの動的更新リクエスト端末からの動的更新リクエスト端末側から能動的に動的登録(以下「クライアント-DDNS」と称することにする)を実現するには、DNSサーバ側の設定とクライアント側の設定が必要である。DNSサーバ側では、動的更新を受け付けるゾーンごとに許可設定を行う。動的更新の欄は「なし」「非セキュリティ保護とセキュリティ保護」「セキュリティ保護のみ」の3種類から選択できる。「なし」はActiveDirectory連携しない場合のデフォルト、「セキュリティ保護のみ」はActiveDirectory連携している場合のデフォルトである。AcitveDirectory連携を行う上でのセキュリティ」で述べることにする。端末側の設定は主に1か所。TCP/IPのプロパティの詳細設定のDNSタブである。ややこしい場所にあるが、デフォルトはONである。動的更新を構成する」を参照。アドレスが追加、削除、または変更されたとき。アドレスのリースが変更または更新されたとき。コマンドが使用されたときに、この更新が発生します。手動で強制的に更新したとき。コンピュータの電源がオンになったとき。コントローラに昇格したとき。clientサービスが更新を要求する点に注意が必要。clientサービスが必須であることにもまた注意が必要である。DHCPサーバがリクエストを受け付けるわけではないので、固定IPの場合には当然ながらDHCPサーバのログには何も残らない。この「クライアント-DDNS」では、PCが更新要求を発する相手のサーバはそのPCに設定された(あるいはDHCPサーバから取得した)、通常最も優先度の高いプライマリDNSサーバになる。従って、プライマリDNSサーバが「端末の属しているActiveDirectoryのドメインコントローラ」でない場合、期待した結果は得られないことになる。(DDNSリクエストまで含めてフォワードしてれば別だが。)非常に使い道の限られた「クライアント-DDNS」なのだが、DHCPサーバがActiveDirectoryのドメインコントローラである場合(ActiveDirectory連携する場合は通常この構成になる)、ドメインコントローラ間のレプリケーションで輻輳して反映が遅くなるリスクを回避するにはある程度有効であろう。クライアントからの直接DDNS更新を行わず、後述するDHCP連携だけを利用する場合にもサーバ側で動的更新を受け入れる設定だけは必要である。単体ではセキュリティ保護した状態でのクライアント-DDNSがちゃんとエミュレーションができない様子。2009年の情報だが以下のブログが参考になった(こちらで検証まではしていないが)。いうことは、NASなどでこの動作を期待するのはムリであると考えた方がよさそうだ。