AD連携を行う上でのセキュリティAD連携を行う上でのセキュリティDNSをAD統合している場合、DNSのレコードもADオブジェクトとして管理されることは前述した通りである。ドメイン管理者のみ変更可能である。クライアント-DDNSの場合はクライアントPCのSystemアカウント(=AD上ではそのコンピュータアカウント)が実行するので、管理者が手動で実行するようなケースを除いて特に気にすることはないのだが、問題はDHCP-DDNSである。セキュリティで保護された更新のみ許可されたゾーンで、DHCPサーバをフェールオーバーさせた場合、切り替え前のサーバでリースしたクライアントのDNSレコードが切り替え後のサーバで更新不可能(これはIPアドレスの変更だけでなくタイムスタンプの更新も含む)になってしまう。そこで、DnsUpdateProxyというビルトイングループがADに用意されている。グループを使用する」このセキュリティグループに、すべてのDHCPサーバのコンピュータアカウントを登録することで、DHCPサーバのフェールオーバー時に発生しうるアクセス権の問題は解決できる。メンバーが作成したDNSレコードはオブジェクトのアクセス権保護が設定されない。従って後からクライアント-DDNSでレコードが更新された場合、所有権は自然にそのコンピュータアカウントに設定されるという具合である。これは、DnsUpdateProxyメンバーのサーバでDHCP-DDNSにより作成したレコードは好き放題に書き換えられることになることを示している。DHCPサーバがドメインコントローラ上に構築されている場合は、DHCPサービスがドメインコントローラのコンピュータアカウントで実行されていることになり、かなり高い権限を持つことになる。以下のような状況の場合は、更新専用IDを作成することを推奨している。動的更新を実行するように構成されている。ゾーンが、セキュリティで保護された動的更新だけを許可するように構成されている。目的の場合にはこの対処が必要だと思われる。バックアップされないため、切り替え後に手動で入力する必要がある。逆に言えば、オブジェクトのセキュリティ保護にこだわらないのであればこの作業は不要ということになる。DHCPクライアントPCにサーバと同じ名前を付けてWorkgroup状態でネットワークに繋ぐとどうなるか...。間違いなくDHCPサーバからの更新でDNSレコードは上書きされるだろう。更新専用IDを作成したとしても、あかの他人がレコードを(故意にせよ事故にせよ)書き換えられることには変わりないわけで、どこまで固執する必要があるのかは各サイトによってもっとしっかり議論されるべき問題であると思う。レコードが消えて困るものについてはクライアント-DDNSをOFFにしておく方がよい。トラブルの元は最初から断ち切っておくのが基本である。マルチホームなサーバがいる場合には、よほどの理由がない限りすべてのインタフェースでクライアント-DDNSを切っておくことを強くオススメしたい。