<div><br></div>One solution that was floated recently around here was to use dynamically loaded zones (<a href="http://bind-dlz.sourceforge.net/">http://bind-dlz.sourceforge.net/</a>) 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). <div>
<br></div><div><br></div><div> -DTK<br><div><br></div><div><br><br><div class="gmail_quote">On Thu, Jul 29, 2010 at 6:25 AM, Gordon A. Lang <span dir="ltr"><<a href="mailto:glang@goalex.com">glang@goalex.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>
<br>
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.<br>
<br>
Better yet, I would like add update-forwarding for master zones -- perhaps it could be called update-replication.<br>
<br>
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.<br>
<br>
Or else maybe a new zone type called backup-master that acts like a slave 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 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.<br>
<br>
Thanks.<br><font color="#888888">
<br>
--<br>
Gordon A. Lang<br>
<br>
----- Original Message ----- From: "Chris Buxton" <<a href="mailto:chris.p.buxton@gmail.com" target="_blank">chris.p.buxton@gmail.com</a>><br>
To: "Gordon A. Lang" <<a href="mailto:glang@goalex.com" target="_blank">glang@goalex.com</a>>; <<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>><br>
Sent: Wednesday, July 28, 2010 11:22 PM</font><div><div></div><div class="h5"><br>
Subject: Re: Bind Clustering<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Updates are always forwarded to the zone masters, as configured in the<br>
zone statement itself. And yes, the update is only forwarded<br>
(successfully) once.<br>
<br>
BIND assumes that each zone has exactly one "primary master". That's<br>
why updates are forwarded only once. If you want a true multi-master<br>
setup, you'll need to look at other options. For example:<br>
<br>
- BIND with modifications or additional software.<br>
- Microsoft DNS and AD-integrated zones.<br>
<br>
There are other options.<br>
<br>
Regards,<br>
Chris Buxton<br>
Bluecat Networks<br>
<br>
On 7/28/10, Gordon A. Lang <<a href="mailto:glang@goalex.com" target="_blank">glang@goalex.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This reply is a few months delayed, but this issue is still very important<br>
to me, and I'm hoping you can take a few minutes to help out.<br>
<br>
I finally took some time to read through the code, and unfortunately I was<br>
unable to identify where forward target(s) are obtained in the update<br>
forwarding action. There's a lot of structure to reverse engineer -- too<br>
much for a casual effort. So perhaps you can tell me where I can find the<br>
pertinent code... ?<br>
<br>
My belief was that somewhere in the code, the SOA record is obtained, and<br>
the MNAME is used as the forward target -- this belief was based on trial<br>
and error observations.<br>
<br>
What you suggested is that the update forwarding actually uses the masters<br>
list from the named.conf file for forwarding targets.<br>
<br>
I was unable to find clues one way or another.<br>
<br>
But another thing about your response that leaves me wondering if I fully<br>
understand your response is that you say it "walks the list of masters<br>
trying each one in turn," and with the word "trying" in there, it suggests<br>
that it walks the list only until the first successful update. Perhaps I am<br>
incorrectly reading into it, but if you could clarify that point, I would<br>
appreciate it. --- I would expect that if the masters list is used, then<br>
ALL masters should always get the updates.<br>
<br>
Thanks in advance.<br>
<br>
--<br>
Gordon A. Lang<br>
<br>
----- Original Message -----<br>
From: "Mark Andrews" <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>><br>
To: "Gordon A. Lang" <<a href="mailto:glang@goalex.com" target="_blank">glang@goalex.com</a>><br>
Cc: <<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>><br>
Sent: Friday, April 09, 2010 5:58 PM<br>
Subject: Re: Bind Clustering<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In message <<a href="mailto:A2E77ADF810A44D1B6AA8AB760ABDB80@CORP.FSROOT.FLAGSTAR.COM" target="_blank">A2E77ADF810A44D1B6AA8AB760ABDB80@CORP.FSROOT.FLAGSTAR.COM</a>>,<br>
"Gordon<br>
A. Lang" writes:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regarding my wild idea for synchronizing mulitiple dynamic masters..<br>
my idea is flawed.<br>
<br>
Evidently, the "allow-update-forwarding" only forwards to the MNAME<br>
configured in the SOA. I was thinking it forwarded to the masters<br>
configured in the conf file. Oh well. I guess we'll just have to<br>
wait for ISC to implement multi-master replication. Anyone know<br>
when this might occur?<br>
</blockquote>
<br>
What makes you say that? If you look at the implementation it walks<br>
the list of masters trying each one in turn.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<br>
Gordon A. Lang<br>
_______________________________________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>
--<br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: +61 2 9871 4742 INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
<br>
</blockquote>
_______________________________________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
<br>
</blockquote>
<br>
-- <br>
Sent from my mobile device<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><br>david t. klein<br><br>Cisco Certified Network Associate (CSCO11281885)<br>Linux Professional Institute Certification (LPI000165615)<br>Redhat Certified Engineer (805009745938860)<br>
<br>Quis custodiet ipsos custodes?<br><br><br><br>
</div></div>