Well, we use two masters in different locations, w/o DLZ. Files for signed zones are being generated from databases and uploaded to servers. What we need here - is propagating of DDNS plus periodical synchronizing of zones, journals etc.
Regarding zone templates - I'm using it with NSD4 and I'm totally happy. Actually I don't have words to emphasize how I love those templates! 2014-05-08 2:06 GMT+04:00 Lawrence K. Chen, P.Eng. <lkc...@ksu.edu>: > > > On 05/06/14 13:39, Evan Hunt wrote: >> On Tue, May 06, 2014 at 06:20:11PM +0000, Baird, Josh wrote: >>> Hi, >>> >>> For those of you who operate at multiple sites or datacenters, are you >>> doing any HA for your BIND masters? Ideally, we would have a master in >>> each datacenter; maybe not an active one, but one that is standing by in >>> case your primary master becomes unavailable. >>> >>> Do you have multiple "active" masters and list them as master in each of >>> your slave's zone definitions? This seems like it could get rather >>> messy. One thought is to use a technology like VMWare SRM which will >>> spin up a master/virtual machine automatically in a second datacenter if >>> your primary master goes down. This coupled with Layer2 connectivity >>> between your sites could make things fairly simple. The >>> standby/secondary master would retain the same IP address as your >>> primary, so everything should just *work*. >>> >>> What are others doing? Any thoughts, ideas or advice is much >>> appreciated. >> >> Thank you for bringing this up. As it happens, high-availability/ >> multi-master support in BIND is something we've been seriously considering >> for a future release. There's been a lot of internal discussion of use >> cases, requirements, and possible design approaches. >> >> I don't want to influence the conversation here by saying too much about >> the ideas we've had so far, but I wanted to say: if anyone has specific >> thoughts on how to make this sort of thing easier in BIND -- even just at >> the level of "boy, it irritates me that I can't make BIND do <X>" -- >> such comments will fall on welcoming ears. >> > > I hadn't thought of doing multi-master...but the issue of promoting a slave to > master for DR had come up. At the time the problem was DNSSEC. Its one thing > for the slave to become master, its another when it needs to change entries in > the zone file to redirect key web-services to DR instances. (at the time, it > was create two signed zone files each time...and secure transfer the second > one out of band....but no DR web servers were ever setup, so both were > identical files and eventually got scrapped. The issue of raw vs text on > secondaries came up after abandonment. But, DR comes up now and > then...recently its using DNS appliances and cloud... > > OTOH, the idea of multi-master is intriguing.....the only down side I see, is > that I have one really powerful server for my current master....(Sun Fire > X4170)....and my other servers are weak leftovers....just passed EOL last > year. And, have all the servers doing full DNSSEC signing could be > interesting. > > It also raises the question of how does the outside world cope with all the > servers having identical zones...signed on slightly different times, etc. > (especially since I'm using unix timestamp for zone serial....avoids issues of > multiple admins incrementing serial without noticing others and/or collisions > with DNSSEC's incrementing of serials.) > > But, it shouldn't be too hard to implement since, our nameservers are managed > by CFEngine. And, it makes possible for all my name servers to have both > internal and external views. Instead of having to have separate external > slaves and internal slaves. (and other issues that I'm still working through > with having this....namely my recursive caching servers hitting external > slaves instead of internal slaves...) > > Things have gotten more complicated since we started allowing vanity internal > names....before it was one subdomain that only existed on internal, and > everybody had to put their host in there, as <dept>-host.<subdomain>.ksu.edu > ....but then certain VIPs wanted host.<dept>.ksu.edu to work even though its a > 10.x.x.x address. > > It would also mean one of our satellite campuses that refuses to use our > caching servers (and even sent our server that was providing the service for > their campus back, which they had firewalled their users from using while it > was there)...can have their own caching servers work without needing to > understand that our whois record doesn't list our stealth/internal > nameservers...which is why they can't resolve any internal services and need > to track down somebody to give them the 10.x.x.x IP and having their users use > that, etc. > > Wonder if they know about the change in forwarding on my caching resolvers to > AD? > > -- > Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator > For: Enterprise Server Technologies (EST) -- & SafeZone Ally > _______________________________________________ > 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 -- Is there any problem Exterminatus cannot solve? I have not found one yet. _______________________________________________ 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
