DHCP Failover DDNS leases file issue or bug?

[David Hankins]

On Mon, Feb 14, 2011 at 4:55 AM, Colin Simpson <Colin.Simpson at iongeo.com>wrote:

> I have been playing with using failover DHCP. We also use dynamic DNS
> updating. I'm using RHEL 6 with dhcp-4.1.1-12.P1.el6 which I'd guess is
> just 4.1.1
>
> The scenario I have been testing is Primary server down and secondary
> up.
>
> What will now happen to DNS when the lease expires?
>
> Does the Secondary handle this and remove this entry from DNS properly?
>

Yes.  The primary will move the lease to expired.  When the secondary
acknowledges this change, it will tear down the dns names on its end.


> And what if the secondary is now goes down, we'll presumably just end up
> with lots of stale DNS entries that won't get removed ever? Or will they
> remove when/if the secondary comes back and sees it has DNS entries it
> needs to now expire (or isn't it that clever).
>

If the secondary goes down, then the lease cannot expire unless the primary
server is moved to partner-down.

Probably, because the secondary is down, the primary will nail up its own
DDNS state for the same client.

Is this a bug? Shouldn't it send all the fields across when they resync?
>

A missing feature.  'Binding scopes' are not synced across the failover
channel.  The failover protocol channel actually doesn't (closely) resemble
dhcpd's lease structure, so you can't look at it like a 1:1 mapping.

It looks like the leases file does get updated on both for dns items if
> both are up when a renew comes from the client. Strange.
>

More likely that is a rebind, and both servers are answering in that case.

Any thoughts?
>

The failover protocol as specified (draft-ietf-dhc-failover-12 (or 13?)) has
the primary doing all ddns teardown work (because the primary initiates all
expirations except a secondary in partner-down).  This is inefficient, which
is one small problem, but mainly it doesn't work well unless you support the
specification-defined failover ddns options to transfer state, or as I said
find a way to sync binding scopes ("set var = value;") across the channel.

I sat down to try and provide binding scope transfers in the last few
iterations of work before 4.2, and unfortunately it was sufficiently
complicated (not impossible) that it didn't make it.

-- 
David W. Hankins
SRE
Google, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20110214/6744f48c/attachment.html>