Multiple DHCP Servers with DDNS Best Practice/Workaround?

[Glenn Satchell]

On 05/12/11 19:52, Colin Simpson wrote:
> Ah a new option "update-conflict-detection", thanks for that I should
> have checked.
>
> On Wed, 2011-05-11 at 20:54 +0100, Simon Hobson wrote:
>> Colin Simpson wrote:
>>
>>> Or has anyone got a cunning way round this?
>>
>> One cunning idea that comes to mind is to look in the source code and
>> see how the TXT record is created - ie where the data comes from. For
>> a closed setup you could modify the servers so they use the same base
>> information, and thus generate the same TXT record contents.
>> In this way, any server in the group could update the A record
>> regardless of which server created it.
>> That would just leave the issue of server deleting the records when
>> the lease expires. The only easy way round that which comes to mind
>> is to modify the code to not delete them at all. That does mean your
>> zones will slowly fill up with old cruft, and the only way I can see
>> round that is to either periodically delete the lot and wait for the
>> real entries to re-appear*, or to write some scripts that will parse
>> the leases file to find active leases and delete everything else, or
>> another cunning plan**
>> * Devices which renew an existing lease won't trigger a DNS update,
>> but devices getting new ones will. Unless you set the flag to do
>> updates for every renew.
>>
> I like this idea, though I don't like having to bespoke the source code
> for maintainability reasons.
>
> Would the best approach to this not be to provide a hashing option
> (secret) somewhere in the config file ? This could be used to generate a
> consistent TXT field across all DHCP servers in the environment, but in
> a secure way (presuming the dhcpd.conf files aren't world readable).
>
> I hadn't realised the full effect of TXT registration and the protection
> of non-TXT tagged A records. It would be nice to maintain this.
>
> I'd assume cruft build up wouldn't be an issue in such a situation. I'd
> hope even now with "update-conflict-detection", the original server
> would realise that the A record doesn't match the IP it allocated and
> not delete that A record (but just clear up his PTR reverse)? Is that
> how it behaves?
>
> Thanks for the information.
>
> Colin

A single dhcp server managing multiple subnets can detect this if you 
use 'one-lease-per-client true'. If a client turns up on another subnet 
it will release any previous lease and subsequently remove any DNS 
entries before handing out the new lease and doing a DNS update.

With separate dhcp servers it really needs some inter-server 
communication to release the old lease and remove the DNS entries. The 
ISC server doesn't have that facility.

Note that there are options you can set in the dhcp response to cause 
windows clients to release any leases on shutdown. Search the archives 
for full details. So if you have windows laptops (for example) this 
might be able to work.


-- 
regards,
-glenn