Bind Clustering

Thu Jul 29 12:06:30 UTC 2010

One solution that was floated recently around here was to use dynamically
loaded zones (http://bind-dlz.sourceforge.net/) 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).

 -DTK

On Thu, Jul 29, 2010 at 6:25 AM, Gordon A. Lang <glang at goalex.com> wrote:

> 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
>

-- 

david t. klein

Cisco Certified Network Associate (CSCO11281885)
Linux Professional Institute Certification (LPI000165615)
Redhat Certified Engineer (805009745938860)

Quis custodiet ipsos custodes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100729/57cda4a3/attachment.html>