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
