DDNS issues ANSWERED
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
>> thing to be done automagically? Where is the provision for this
>> type of
> 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
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