best practices for two-location DDNS for a single domain

[Chris McCraw]

On Thu, Jan 12, 2012 at 5:28 PM, Doug Barton <dougb at dougbarton.us> wrote:
> On 01/12/2012 17:04, Chris McCraw wrote:
>> Hi there,
>>
>> Due to a variety of semi-political issues in our environment, we're
>> looking for a way to implement the following:
>>
>> - 2 locations with standalone-capable local nameservers which serve
>> the same domain (ie, in case of network failure between them, we want
>> them both to go on working as authoritative for the domain for local
>> clients.)
>> - using dynamic dns (client updates) in two locations for that same
>> domain.  Updates from either master need to be visible to clients of
>> each master, though a slight lag in syncing would be acceptable.
>
> To the extent that I understand what you're trying to accomplish, the
> safest solution is to use a separate master server with reliable
> connectivity to both locations, and have the authoritative servers at
> the locations slave the zone from it.

I should have been more clear;  what we are actually looking to
protect against is a site going offline entirely--we want that site to
be able to continue to operate (accept and serve local DDNS updates to
local clients).  That's why I was leaning towards a master in both
places--I'm not sure what the failure mode of a slave that can handle
DDNS is, but I'd read some rumblings that the allow-update-forwarding
against a slave which cannot reach its master has some issues
(https://lists.isc.org/pipermail/bind-users/2009-April/076109.html and
others).  Perhaps those rumblings are out of date and that will
actually work fine for us now?


> If you cannot guarantee reliable connectivity then the alternate
> solution would be to have each location dynamically update a subzone,
> and then they slave from each other.

Perhaps I've misunderstood--I didn't think I could have two zones for
the same domain (rather than subdomains)?  I am open to suggestion if
there's some way to do this with a master/slave paradigm, even if it's
a master/slave <=> slave/master setup.  Or really open to any
suggestion =)

Here's a use case:

Network X has local Nameserver X and Client A who sends an update to
become A.domain.com to Nameserver X
Network Y has local Nameserver Y and Client B who sends an update to
become B.domain.com to Nameserver Y

Network Y loses its internet connectivity and during this outage has
Client C send an update to become C.domain.com to NS Y.  B.domain.com
needs to be able to resolve C.domain.com before the network is
restored.

Meanwhile, Network X clients still need to be able to resolve
A.domain.com using NS X and send updates to NS X themselves.  It'd be
great if they could still resolve B.domain.com (even though it will be
unreachable).  Obviously they'll have no idea about C.domain.com and
that's fine.  However, once the network resumes, they need to be able
to resolve C.domain.com ASAP.

We are not concerned with the failure mode of ending up with 2 clients
in different locations attempting to become E.domain.com while the
networks are out of touch.

Hopefully that clarifies things.

Thanks very much for your consideration!