DDNS issues

[David W. Hankins]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100323/c19aee6b/attachment.bin>