DDNS issues ANSWERED

Alex Moen alexm at ndtel.com
Tue Mar 23 18:03:06 UTC 2010


On Mar 23, 2010, at 12:05 PM, David W. Hankins wrote:

> On Mon, Mar 22, 2010 at 02:33:01PM -0500, Alex Moen wrote:
>> So, I can do it manually, but why can't the DHCP server request the  
>> same
>> thing to be done automagically?  Where is the provision for this  
>> type of
>> process?
>
> What you are running up against is IETF standard domain name
> conflict resolution process.  The typical way for this to resolve
> itself is for the old address to expire, DDNS updates perform the
> teardown, and the new client receives the name on its next renewal.
>
> One easier workaround would be when you detect a situation like this,
> to simply use BIND 9's 'nsupdate' utility to remove all RR's from the
> name in question from DNS, and then cause (or wait for) the client to
> renew its new lease.  Although this leaves the client's previous
> active binding (on the old client identifier) active in the DHCP
> server, and there will be an expiration event for it to teardown DDNS,
> the updates are carefully crafted so that clients with multiple
> addresses are not affected when multiple DHCP servers are performing
> updates potentially over the same name, and so it will safely fail
> (it will not remove the client's new DNS binding).
>
> Another solution would be to disable update-conflict-detection (see
> 'man dhcpd.conf'), but this is not the most desirable outcome because
> any client will be able to take any name at whim (so you need to think
> carefully about where you get FQDN value configuration and how much
> you trust it is not nefarious ("WPAD.domain", "www.domain", etc)).
>
>
> This is probably more of a DHCP issue than a BIND issue, so we should
> direct any additional followups to dhcp-users please.
>
> -- 
> David W. Hankins	BIND 10 needs more DHCP voices.
> Software Engineer		There just aren't enough in our heads.
> Internet Systems Consortium, Inc.		http://bind10.isc.org/
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

Awesome explanation.... It even makes sense, when taking into account  
the possibility of *more than one* DHCP authority.  I didn't consider  
that possibility initially.

We are (I believe) going to use our workaround in a progressive  
manner, and get all of our devices changed over to their new client  
ID, eliminating the problem.

Thanks all for the advice, on-list and off-list... I am marking this  
as answered, as there really isn't a solution per se...  Everything  
works as it was designed, and my situation is at fault. I'll deal with  
that on my own.

Thanks again all!

Alex





More information about the dhcp-users mailing list