[ddns] "update-conflict-detection" and co-existing DHCPv4/v6 servers

[Chris Buxton]

On Mar 21, 2012, at 4:58 PM, Peter Rathlev wrote:

> On Wed, 2012-03-21 at 16:43 +0100, Nicolas C. wrote:
>> The problem is the follow : when "update-conflict-detection" is 
>> disabled, a client can indirectly update and even delete A records by 
>> booting on the network with the same name of a server for example.
> 
> Place client hosts in different domains than servers. I have an idea
> that Microsoft Windows "Active Domain" doesn't support this, but that's
> a limitation of their implementation.

That's not true. Windows admins routinely put clients into a subdomain of the AD domain.

> AFAICT current Windows DHCP
> servers face the exact same issue you describe.

Yes, but MS DNS offers a solution. If you permit client updates but require use of GSS-TSIG (secure updates only), then the originator of the hostname (by kerberos ID) "owns" the hostname until it is actually deleted. And since Windows clients generally do not delete their A records, this leaves the permissions in place.

>> Alternatively, is it possible to "lock" some records to prevent update?
> 
> You could control this on the DNS server. I know BIND allows for a
> rather granular update policy.

Precisely. You can use update-policy to restrict access to certain names within the zone, and even to require that the kerberos ID of a GSS-TSIG-signed update match the hostname being updated. This last is a bit tricky, though. There's a similar restriction available for TSIG, although most DDNS update clients (other than dhcpd itself) do not use TSIG.

For unsigned updates, you can still put sanity limits on what can be updated, such as requiring them to be in a subdomain (which need not be separated into a subzone).

Regards,
Chris Buxton
BlueCat Networks