One solution that was floated recently around here was to use dynamically loaded zones (http://bind-dlz.sourceforge.net/) with an underlying storage mechanism that does bidirectional replication (a directory service like LDAP or a database) for the masters, this way, whichever one gets the update, the others get. The downside is that DLZ is basically a rearchitecture of your DNS setup, and will require the two extra pieces to maintain (the DLZ portion and the underlying replicating source).
-DTK On Thu, Jul 29, 2010 at 6:25 AM, Gordon A. Lang <gl...@goalex.com> wrote: > I know BIND does not currently support multi-master. And I understand that > trying to strap together my own pseudo-multi-master implementation using > BIND, bubble gum, and tape isn't a sustainable solution. But, nevertheless, > I don't really need a true multi-master implementation -- I just need to > keep my backup master relatively up to date without relying on frequent > freeze-copy-thaw operations. I would be happy to have the updates go to one > slave, and then be replicated to both the active master and the backup > master. I would deal with drift via brute force i.e. I would have the > active master copy over to the backup master on a once or twice a day basis, > not once every 5 minutes. > > I think it would be great if there were a new config construct added > whereby the update-forward target(s) are explicitly specified. In the case > where the masters are slaves of a hidden master that is directly reachable, > it would allow for the updates to be directly forwarded to the primary > master instead of being forwarded twice. And if multiple update-forward > targets are specified, then all targets always get an update. This could be > used to maintain a duplicate (hidden) master and/or eliminate the > failure-delay when the multiple masters "switch over," take turns being the > master. And possibly the specified update-forward target construct could > also have an optional behavior of "forward-to-all" or > "stop-on-first-success." if current behavior is preferred, but with a > different list than then zone-transfer master list. > > Better yet, I would like add update-forwarding for master zones -- perhaps > it could be called update-replication. > > I guess what I would really like to see is multiple MNAME targets > accommodated right in the SOA, but I imagine that would have a serious > compatibility challenge. > > Or else maybe a new zone type called backup-master that acts like a slave > until an rndc control flips its operation state. > > I would like to get see some more comments on this. > > And I would really appreciate it if someone could tell me where in the > source code I should look to find where the update-forward targets are > obtained so that I can evaluate what it would take for me to write my own > modifications. > > Thanks. > > -- > Gordon A. Lang > > ----- Original Message ----- From: "Chris Buxton" < > chris.p.bux...@gmail.com> > To: "Gordon A. Lang" <gl...@goalex.com>; <bind-users@lists.isc.org> > Sent: Wednesday, July 28, 2010 11:22 PM > > Subject: Re: Bind Clustering > > > Updates are always forwarded to the zone masters, as configured in the >> zone statement itself. And yes, the update is only forwarded >> (successfully) once. >> >> BIND assumes that each zone has exactly one "primary master". That's >> why updates are forwarded only once. If you want a true multi-master >> setup, you'll need to look at other options. For example: >> >> - BIND with modifications or additional software. >> - Microsoft DNS and AD-integrated zones. >> >> There are other options. >> >> Regards, >> Chris Buxton >> Bluecat Networks >> >> On 7/28/10, Gordon A. Lang <gl...@goalex.com> wrote: >> >>> This reply is a few months delayed, but this issue is still very >>> important >>> to me, and I'm hoping you can take a few minutes to help out. >>> >>> I finally took some time to read through the code, and unfortunately I >>> was >>> unable to identify where forward target(s) are obtained in the update >>> forwarding action. There's a lot of structure to reverse engineer -- too >>> much for a casual effort. So perhaps you can tell me where I can find >>> the >>> pertinent code... ? >>> >>> My belief was that somewhere in the code, the SOA record is obtained, and >>> the MNAME is used as the forward target -- this belief was based on trial >>> and error observations. >>> >>> What you suggested is that the update forwarding actually uses the >>> masters >>> list from the named.conf file for forwarding targets. >>> >>> I was unable to find clues one way or another. >>> >>> But another thing about your response that leaves me wondering if I fully >>> understand your response is that you say it "walks the list of masters >>> trying each one in turn," and with the word "trying" in there, it >>> suggests >>> that it walks the list only until the first successful update. Perhaps I >>> am >>> incorrectly reading into it, but if you could clarify that point, I would >>> appreciate it. --- I would expect that if the masters list is used, >>> then >>> ALL masters should always get the updates. >>> >>> Thanks in advance. >>> >>> -- >>> Gordon A. Lang >>> >>> ----- Original Message ----- >>> From: "Mark Andrews" <ma...@isc.org> >>> To: "Gordon A. Lang" <gl...@goalex.com> >>> Cc: <bind-users@lists.isc.org> >>> Sent: Friday, April 09, 2010 5:58 PM >>> Subject: Re: Bind Clustering >>> >>> >>> >>>> In message <a2e77adf810a44d1b6aa8ab760abd...@corp.fsroot.flagstar.com>, >>>> "Gordon >>>> A. Lang" writes: >>>> >>>>> Regarding my wild idea for synchronizing mulitiple dynamic masters.. >>>>> my idea is flawed. >>>>> >>>>> Evidently, the "allow-update-forwarding" only forwards to the MNAME >>>>> configured in the SOA. I was thinking it forwarded to the masters >>>>> configured in the conf file. Oh well. I guess we'll just have to >>>>> wait for ISC to implement multi-master replication. Anyone know >>>>> when this might occur? >>>>> >>>> >>>> What makes you say that? If you look at the implementation it walks >>>> the list of masters trying each one in turn. >>>> >>>> -- >>>>> Gordon A. Lang >>>>> _______________________________________________ >>>>> bind-users mailing list >>>>> bind-users@lists.isc.org >>>>> https://lists.isc.org/mailman/listinfo/bind-users >>>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>>> >>>> _______________________________________________ >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >>> >> -- >> Sent from my mobile device >> >> > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes?
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
