<HTML>
<br>
One thing you have top remember is the Slave NEVER updates the Master.<br>
The updater is always the Master and the receiver is always the Slave.<br>
<br>
I have posted about using 2 masters. You should be able to do a search on he <br>
archive and find the post.<br>
<br>
In short all you need to do is setup 2 masters and make them a slave of the <br>
other that way no matter which is updated everyone gets the update.<br>
<br>
<br>
<span style="font-weight: bold;">On Thu 07/29/10 7:25 AM , "Gordon A. Lang" glang@goalex.com sent:<br>
</span><blockquote style="border-left: 2px solid rgb(245, 245, 245); margin-left: 5px; margin-right: 0px; padding-left: 5px; padding-right: 0px;">I know BIND does not currently support multi-master. And I understand that <br>
trying to strap together my own pseudo-multi-master implementation using <br>
BIND, bubble gum, and tape isn't a sustainable solution. But, nevertheless, <br>
I don't really need a true multi-master implementation -- I just need to <br>
keep my backup master relatively up to date without relying on frequent <br>
freeze-copy-thaw operations. I would be happy to have the updates go to one <br>
slave, and then be replicated to both the active master and the backup <br>
master. I would deal with drift via brute force i.e. I would have the <br>
active master copy over to the backup master on a once or twice a day basis, <br>
not once every 5 minutes.<br>
<br>
I think it would be great if there were a new config construct added whereby <br>
the update-forward target(s) are explicitly specified. In the case where <br>
the masters are slaves of a hidden master that is directly reachable, it <br>
would allow for the updates to be directly forwarded to the primary master <br>
instead of being forwarded twice. And if multiple update-forward targets <br>
are specified, then all targets always get an update. This could be used to <br>
maintain a duplicate (hidden) master and/or eliminate the failure-delay when <br>
the multiple masters "switch over," take turns being the master. And <br>
possibly the specified update-forward target construct could also have an <br>
optional behavior of "forward-to-all" or "stop-on-first-success." if current <br>
behavior is preferred, but with a different list than then zone-transfer <br>
master list.<br>
<br>
Better yet, I would like add update-forwarding for master zones -- perhaps <br>
it could be called update-replication.<br>
<br>
I guess what I would really like to see is multiple MNAME targets <br>
accommodated right in the SOA, but I imagine that would have a serious <br>
compatibility challenge.<br>
<br>
Or else maybe a new zone type called backup-master that acts like a slave <br>
until an rndc control flips its operation state.<br>
<br>
I would like to get see some more comments on this.<br>
<br>
And I would really appreciate it if someone could tell me where in the <br>
source code I should look to find where the update-forward targets are <br>
obtained so that I can evaluate what it would take for me to write my own <br>
modifications.<br>
<br>
Thanks.<br>
<br>
--<br>
Gordon A. Lang<br>
<br>
----- Original Message ----- <br>
From: "Chris Buxton" <<a href="javascript:top.opencompose('chris.p.buxton@gmail.com','','','')">chris.p.buxton@gmail.com</a>><br>
To: "Gordon A. Lang" <<a href="javascript:top.opencompose('glang@goalex.com','','','')">glang@goalex.com</a>>; <<a href="javascript:top.opencompose('bind-users@lists.isc.org','','','')">bind-users@lists.isc.org</a>><br>
Sent: Wednesday, July 28, 2010 11:22 PM<br>
Subject: Re: Bind Clustering<br>
<br>
<br>
<span style="color: rgb(102, 102, 102);">> Updates are always forwarded to the zone masters, as configured in the</span><br>
<span style="color: rgb(102, 102, 102);">> zone statement itself. And yes, the update is only forwarded</span><br>
<span style="color: rgb(102, 102, 102);">> (successfully) once.</span><br>
<span style="color: rgb(102, 102, 102);">></span><br>
<span style="color: rgb(102, 102, 102);">> BIND assumes that each zone has exactly one "primary master". That's</span><br>
<span style="color: rgb(102, 102, 102);">> why updates are forwarded only once. If you want a true multi-master</span><br>
<span style="color: rgb(102, 102, 102);">> setup, you'll need to look at other options. For example:</span><br>
<span style="color: rgb(102, 102, 102);">></span><br>
<span style="color: rgb(102, 102, 102);">> - BIND with modifications or additional software.</span><br>
<span style="color: rgb(102, 102, 102);">> - Microsoft DNS and AD-integrated zones.</span><br>
<span style="color: rgb(102, 102, 102);">></span><br>
<span style="color: rgb(102, 102, 102);">> There are other options.</span><br>
<span style="color: rgb(102, 102, 102);">></span><br>
<span style="color: rgb(102, 102, 102);">> Regards,</span><br>
<span style="color: rgb(102, 102, 102);">> Chris Buxton</span><br>
<span style="color: rgb(102, 102, 102);">> Bluecat Networks</span><br>
<span style="color: rgb(102, 102, 102);">></span><br>
<span style="color: rgb(102, 102, 102);">> On 7/28/10, Gordon A. Lang <<a href="javascript:top.opencompose('glang@goalex.com','','','')">glang@goalex.com</a>> wrote:</span><br>
<span style="color: rgb(102, 102, 102);">>> This reply is a few months delayed, but this issue is still very </span><br>
<span style="color: rgb(102, 102, 102);">>> important</span><br>
<span style="color: rgb(102, 102, 102);">>> to me, and I'm hoping you can take a few minutes to help out.</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> I finally took some time to read through the code, and unfortunately I </span><br>
<span style="color: rgb(102, 102, 102);">>> was</span><br>
<span style="color: rgb(102, 102, 102);">>> unable to identify where forward target(s) are obtained in the update</span><br>
<span style="color: rgb(102, 102, 102);">>> forwarding action. There's a lot of structure to reverse engineer -- too</span><br>
<span style="color: rgb(102, 102, 102);">>> much for a casual effort. So perhaps you can tell me where I can find </span><br>
<span style="color: rgb(102, 102, 102);">>> the</span><br>
<span style="color: rgb(102, 102, 102);">>> pertinent code... ?</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> My belief was that somewhere in the code, the SOA record is obtained, and</span><br>
<span style="color: rgb(102, 102, 102);">>> the MNAME is used as the forward target -- this belief was based on trial</span><br>
<span style="color: rgb(102, 102, 102);">>> and error observations.</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> What you suggested is that the update forwarding actually uses the </span><br>
<span style="color: rgb(102, 102, 102);">>> masters</span><br>
<span style="color: rgb(102, 102, 102);">>> list from the named.conf file for forwarding targets.</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> I was unable to find clues one way or another.</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> But another thing about your response that leaves me wondering if I fully</span><br>
<span style="color: rgb(102, 102, 102);">>> understand your response is that you say it "walks the list of masters</span><br>
<span style="color: rgb(102, 102, 102);">>> trying each one in turn," and with the word "trying" in there, it </span><br>
<span style="color: rgb(102, 102, 102);">>> suggests</span><br>
<span style="color: rgb(102, 102, 102);">>> that it walks the list only until the first successful update. Perhaps I </span><br>
<span style="color: rgb(102, 102, 102);">>> am</span><br>
<span style="color: rgb(102, 102, 102);">>> incorrectly reading into it, but if you could clarify that point, I would</span><br>
<span style="color: rgb(102, 102, 102);">>> appreciate it. --- I would expect that if the masters list is used, </span><br>
<span style="color: rgb(102, 102, 102);">>> then</span><br>
<span style="color: rgb(102, 102, 102);">>> ALL masters should always get the updates.</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> Thanks in advance.</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> --</span><br>
<span style="color: rgb(102, 102, 102);">>> Gordon A. Lang</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>> ----- Original Message -----</span><br>
<span style="color: rgb(102, 102, 102);">>> From: "Mark Andrews" <<a href="javascript:top.opencompose('marka@isc.org','','','')">marka@isc.org</a>></span><br>
<span style="color: rgb(102, 102, 102);">>> To: "Gordon A. Lang" <<a href="javascript:top.opencompose('glang@goalex.com','','','')">glang@goalex.com</a>></span><br>
<span style="color: rgb(102, 102, 102);">>> Cc: <<a href="javascript:top.opencompose('bind-users@lists.isc.org','','','')">bind-users@lists.isc.org</a>></span><br>
<span style="color: rgb(102, 102, 102);">>> Sent: Friday, April 09, 2010 5:58 PM</span><br>
<span style="color: rgb(102, 102, 102);">>> Subject: Re: Bind Clustering</span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">>>></span><br>
<span style="color: rgb(102, 102, 102);">>>> In message <<a href="javascript:top.opencompose('A2E77ADF810A44D1B6AA8AB760ABDB80@CORP.FSROOT.FLAGSTAR.COM','','','')">A2E77ADF810A44D1B6AA8AB760ABDB80@CORP.FSROOT.FLAGSTAR.COM</a>>,</span><br>
<span style="color: rgb(102, 102, 102);">>>> "Gordon</span><br>
<span style="color: rgb(102, 102, 102);">>>> A. Lang" writes:</span><br>
<span style="color: rgb(102, 102, 102);">>>>> Regarding my wild idea for synchronizing mulitiple dynamic masters..</span><br>
<span style="color: rgb(102, 102, 102);">>>>> my idea is flawed.</span><br>
<span style="color: rgb(102, 102, 102);">>>>></span><br>
<span style="color: rgb(102, 102, 102);">>>>> Evidently, the "allow-update-forwarding" only forwards to the MNAME</span><br>
<span style="color: rgb(102, 102, 102);">>>>> configured in the SOA. I was thinking it forwarded to the masters</span><br>
<span style="color: rgb(102, 102, 102);">>>>> configured in the conf file. Oh well. I guess we'll just have to</span><br>
<span style="color: rgb(102, 102, 102);">>>>> wait for ISC to implement multi-master replication. Anyone know</span><br>
<span style="color: rgb(102, 102, 102);">>>>> when this might occur?</span><br>
<span style="color: rgb(102, 102, 102);">>>></span><br>
<span style="color: rgb(102, 102, 102);">>>> What makes you say that? If you look at the implementation it walks</span><br>
<span style="color: rgb(102, 102, 102);">>>> the list of masters trying each one in turn.</span><br>
<span style="color: rgb(102, 102, 102);">>>></span><br>
<span style="color: rgb(102, 102, 102);">>>>> --</span><br>
<span style="color: rgb(102, 102, 102);">>>>> Gordon A. Lang</span><br>
<span style="color: rgb(102, 102, 102);">>>>> _______________________________________________</span><br>
<span style="color: rgb(102, 102, 102);">>>>> bind-users mailing list</span><br>
<span style="color: rgb(102, 102, 102);">>>>> <a href="javascript:top.opencompose('bind-users@lists.isc.org','','','')">bind-users@lists.isc.org</a></span><br>
<span style="color: rgb(102, 102, 102);">>>>> <a target="_blank" href="parse.php?redirect=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users"><span style="color: red;">https://lists.isc.org/mailman/listinfo/bind-users</span></a></span><br>
<span style="color: rgb(102, 102, 102);">>>> --</span><br>
<span style="color: rgb(102, 102, 102);">>>> Mark Andrews, ISC</span><br>
<span style="color: rgb(102, 102, 102);">>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia</span><br>
<span style="color: rgb(102, 102, 102);">>>> PHONE: +61 2 9871 4742 INTERNET: <a href="javascript:top.opencompose('marka@isc.org','','','')">marka@isc.org</a></span><br>
<span style="color: rgb(102, 102, 102);">>>></span><br>
<span style="color: rgb(102, 102, 102);">>> _______________________________________________</span><br>
<span style="color: rgb(102, 102, 102);">>> bind-users mailing list</span><br>
<span style="color: rgb(102, 102, 102);">>> <a href="javascript:top.opencompose('bind-users@lists.isc.org','','','')">bind-users@lists.isc.org</a></span><br>
<span style="color: rgb(102, 102, 102);">>> <a target="_blank" href="parse.php?redirect=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users"><span style="color: red;">https://lists.isc.org/mailman/listinfo/bind-users</span></a></span><br>
<span style="color: rgb(102, 102, 102);">>></span><br>
<span style="color: rgb(102, 102, 102);">></span><br>
<span style="color: rgb(102, 102, 102);">> -- </span><br>
<span style="color: rgb(102, 102, 102);">> Sent from my mobile device</span><br>
<span style="color: rgb(102, 102, 102);">> </span><br>
<br>
_______________________________________________<br>
bind-users mailing list<br>
<a href="javascript:top.opencompose('bind-users@lists.isc.org','','','')">bind-users@lists.isc.org</a><br>
<a target="_blank" href="parse.php?redirect=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users"><span style="color: red;">https://lists.isc.org/mailman/listinfo/bind-users</span></a><br>
<br>
</blockquote><BR></HTML>