Multiple DHCP Servers with DDNS Best Practice/Workaround?

[Tim Maestas]

By default dhcpd  will NOT add an A record if one of the same name
already exists, unless a TXT record it recognizes as having placed
there itself is present.  So a malicious/clueless user can not simply
name their machine "www" and break things.  Addition of random TXT
records to your static entries is not necessary.

That being said, I read the manpage for the update-conflict-detection
option and I'm not sure whether or not the above would still apply if
this is set to false.
-Tim


On Wed, May 11, 2011 at 12:49 PM, Shawn Routhier <sar at isc.org> wrote:
> You may want to review the update-conflict-detection
> option.  It may provide the functionality you are
> requesting.
>
> On 05/11/2011 10:16, Colin Simpson wrote:
>>
>> Hi
>>
>> I'm just looking for some advice on the best practice for multiple ISC
>> DHCP servers with DDNS updates (each one on a different subnet). The
>> issue I have is that machines switching subnets are stuck with the old
>> names in DNS.
>>
>> Now I realise this is by design (by use of the TXT with the A records).
>> But if a laptop user disconnects from one network (which they invariably
>> do without de-registering) and reconnect to a new network, their
>> hostname will not get updated in DNS until the DHCP lease expires in
>> DHCP on the original server. This is causing issues (particularly for
>> Linux laptops, where people expect to reach them by SSH and NFS servers
>> that don't like a client that isn't properly setup in DNS (A and PTR))
>>
>> I'm presuming for most situation this is acceptable so that DHCP servers
>> don't tread on each others DNS allocations. But can you force them to
>> (maybe in such a way that the original DHCP server won't delete the new
>> DNS record from a second server (for example by checking that it's not
>> in the range he manages)?
>>
>> I saw a thread about this from several years ago:
>>
>> https://lists.isc.org/pipermail/dhcp-users/2006-August/001335.html
>>
>> Has anything changed since then (or moved forward)? The only approach in
>> here involved source codes changes, which from a maintainability point
>> of view isn't great for us.
>>
>> Or has anyone got a cunning way round this?
>>
>> I thought of a bit of a hack that could remove a machines DHCP
>> allocation from all other DHCP servers in the environment if it appears
>> on a new DHCP server. Or maybe just a very short lease time (but
>> obviously issues with that too).
>>
>> I realise there are risks to this, but we are sure (as it's possible to
>> be) there are no overlapping name allocations at this site (they are
>> assigned by us).
>>
>> And this argument against stamping on each other's toes, would be more
>> relevant if a malicious/stupid user couldn't already screw up say a
>> server, by giving their machine a server's name. I'd presume that DHCPD
>> would happily overwrite the static DNS entry (for the server's static
>> IP), esp if say a Windows DC that adds DNS entries itself to DNS (but no
>> TXT entries attached to them). Should I be adding my own random TXT
>> entries to static DNS entries if they share a zone with DHCP manage
>> DNS?
>>
>> Sadly the subnets in our situation don't all share a switching
>> infrastructure so a single server with DHCP relaying is not an option.
>> And does this work properly with de-registering from an existing subnet
>> and re-registering on a new one (out of interest)?
>>
>> Any thoughts very welcome.
>>
>> Thanks
>>
>> Colin
>>
>> This email and any files transmitted with it are confidential and are
>> intended solely for the use of the individual or entity to whom they are
>> addressed.  If you are not the original recipient or the person responsible
>> for delivering the email to the intended recipient, be advised that you have
>> received this email in error, and that any use, dissemination, forwarding,
>> printing, or copying of this email is strictly prohibited. If you received
>> this email in error, please immediately notify the sender and delete the
>> original.
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>