One thing you have top remember is the Slave NEVER updates the Master. The updater is always the Master and the receiver is always the Slave. I have posted about using 2 masters. You should be able to do a search on he archive and find the post. In short all you need to do is setup 2 masters and make them a slave of the other that way no matter which is updated everyone gets the update. On Thu 07/29/10 7:25 AM , "Gordon A. Lang" gl...@goalex.com sent: 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" To: "Gordon A. Lang" ; 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 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" >> To: "Gordon A. Lang" >> Cc: >> Sent: Friday, April 09, 2010 5:58 PM >> Subject: Re: Bind Clustering >> >> >>> >>> In message , >>> "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 >>>> >>>> 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: >>> >> _______________________________________________ >> bind-users mailing list >> >> https://lists.isc.org/mailman/listinfo/bind-users >> > > -- > Sent from my mobile device > _______________________________________________ bind-users mailing list https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
