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 bind-users
mailing list