Multiple DHCP Servers with DDNS Best Practice/Workaround?

[Colin Simpson]

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


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.