On Thu, Jan 12, 2012 at 5:28 PM, Doug Barton <do...@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! _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
