Bind Clustering

Tue Aug 3 13:38:16 UTC 2010

To all,

The term "master" has different meanings in different contexts.  Each zone
is configured with a "type" of master or slave, etc, and in this context
the term "master" refers to a functional paramater of this zone on this
server.  But within the configuration of a zone that is of type "slave,"
there is a "masters list" specifying the servers from which zone transfers
might be obtained for the zone, and in this context the term "master"
refers to the IP address of a server.  Quite often in dialog, the context
is not equally understood amongst the parites hence the communication is
confounded.

I personally think the term master should ONLY refer to the zone attribute,
and the use of the word "master" or "primary master" to refer to the IP
address of a server should be abolished.  Either that or we need to change
the zone configuration to no longer define a zone type as a "master" or a
"slave" and instead have a zone-data-source of "files" or "xfr" or "sql"
or whatever else might be possible.  It is excessively annoying when
ambiguous terminology makes it difficult for smart and knowledgeable
people to communicate efficiently.

To Robert,

Thanks for you response.  I think your idea would be good for some other
need, but my concern is about "dynamic updates," which has different
requirements.  Nevertheless, I have a couple questions:

Is you suggestion to run two instances of BIND (or a single instance of
BIND with two views) on each of the two servers you call Master A and
Master B, and have all the zones in one instance of BIND be configured
as masters and all the zones in the other instance of BIND be configured
as slaves, with both instances sharing the same db files?  If so, how
did you split each server i.e. did you use distinct ports or distinct
ip addresses or both?  If not, then how did you manage to get a slave
zone to accept what you call "updates," which I presume you mean non-
dynamic updates, from any source other than zone transfers?

Thanks.

--
Gordon A. Lang  /  313-819-7978
----- Original Message ----- 
From: mlists at zoominternet.net
To: Chris Buxton ; bind-users at lists.isc.org ; Gordon A. Lang
Sent: Tuesday, August 03, 2010 8:07 AM
Subject: Re: Re: Bind Clustering

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" <chris.p.buxton at gmail.com>
To: "Gordon A. Lang" <glang at goalex.com>; <bind-users at 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 <glang at 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" <marka at isc.org>
>> To: "Gordon A. Lang" <glang at goalex.com>
>> Cc: <bind-users at lists.isc.org>
>> Sent: Friday, April 09, 2010 5:58 PM
>> Subject: Re: Bind Clustering
>>
>>
>>>
>>> In message <A2E77ADF810A44D1B6AA8AB760ABDB80 at 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 at 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: marka at isc.org
>>>
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
> -- 
> Sent from my mobile device
>

_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users 