Bind Clustering
mlists at zoominternet.net
mlists at zoominternet.net
Tue Aug 3 12:07:46 UTC 2010
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" glang at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100803/8c4bb5ff/attachment.html>
More information about the bind-users
mailing list