Bind Clustering

Thu Jul 29 11:25:08 UTC 2010

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
> 