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-us...@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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
