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!


More information about the dhcp-users mailing list