several master ip's for a slave zone

[hugo hugoo]

Hello,

I have seen that for a slave zone, it is possible to configure several master IP's.
Why this possibility?
How does it works if several master zone can be used for the zone transfer?


Thanks for any feedback,

Hugo,

[Anand Buddhdev]

On 03/11/2011 23:14, hugo hugoo wrote:

Hi Hugo,

> I have seen that for a slave zone, it is possible to configure several master IP's.
> Why this possibility?
> How does it works if several master zone can be used for the zone transfer?

This allows for resiliency. In case one of the master servers is
unreachable, BIND can try the next master in the list.

Anand Buddhdev
RIPE NCC

[kalpesh varyani]

How does this feature address the risk that data provided by one master might get overwritten by another?

 

Regards,

Kalpesh

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Anand Buddhdev]

On 05/11/2011 09:21, kalpesh varyani wrote:

> How does this feature address the risk that data provided by one master
> might get overwritten by another?

Why would anyone run multiple masters with differing zone contents?

Anand

[Phil Mayers]

On 11/05/2011 08:21 AM, kalpesh varyani wrote:
> How does this feature address the risk that data provided by one master
> might get overwritten by another?

The zone serial number is checked, and a transfer is only done if the
serial is higher than the local one. It is assumed the zone admin won't
be silly enough to then create a zone with a higher serial, but wrong data.

[Alan Clegg]

On 11/5/2011 4:21 AM, kalpesh varyani wrote:
> How does this feature address the risk that data provided by one master
> might get overwritten by another?

The use of the word "masters" in the configuration of a slave zone is a
bit misleading. Under most circumstances, you list the authoritative
servers, not "multiple masters".

I have long advocated (for clarity sake) that it should be:

slave example.com {
type slave;
authoritatives { 192.0.2.12; 203.0.113.53; };
};

instead of:

slave example.com {
type slave;
masters { 192.0.2.12; 203.0.113.53; };
};

But that would break lots of configuration files. :)

AlanC
--
al...@clegg.com | acl...@infoblox.com
1.919.355.8851

[Lyle Giese]

On 11/05/11 03:21, kalpesh varyani wrote:
> How does this feature address the risk that data provided by one master
> might get overwritten by another?

> Regards,
> Kalpesh
>
> On Fri, Nov 4, 2011 at 4:08 AM, Anand Buddhdev <ana...@ripe.net
> <mailto:ana...@ripe.net>> wrote:
>
> On 03/11/2011 23:14, hugo hugoo wrote:
>
> Hi Hugo,
>
> > I have seen that for a slave zone, it is possible to configure
> several master IP's.
> > Why this possibility?
> > How does it works if several master zone can be used for the zone
> transfer?
>
> This allows for resiliency. In case one of the master servers is
> unreachable, BIND can try the next master in the list.
>
> Anand Buddhdev
> RIPE NCC
> _______________________________________________

When you have more than one master, the serial number is used to
determine which Master has the most current version of the zone by the
slaves. The slaves actually ask for the SOA record from each Master
when refreshing.

Lyle Giese
LCR Computer Services, Inc.

[Felix New]

if i have several master servers, whether i must ensure that all the master server's serial  are the same? i think this is a little complex, in particular zone is updated by dynamic update(In such a scenario, the serial number is controled by every single bind).

is it correct?

 

2011/11/5 Alan Clegg <al...@clegg.com>

On 11/5/2011 4:21 AM, kalpesh varyani wrote:
> How does this feature address the risk that data provided by one master
> might get overwritten by another?

The use of the word "masters" in the configuration of a slave zone is a
bit misleading.  Under most circumstances, you list the authoritative
servers, not "multiple masters".

I have long advocated (for clarity sake) that it should be:

slave example.com {
       type slave;
       authoritatives { 192.0.2.12; 203.0.113.53; };
};

instead of:

slave example.com {
       type slave;
       masters { 192.0.2.12; 203.0.113.53; };
};

But that would break lots of configuration files.  :)

AlanC
--
al...@clegg.com | acl...@infoblox.com
         1.919.355.8851

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

--
Best regards.
Felix New

[Alan Clegg]

On 11/5/2011 9:32 AM, Felix New wrote:
> if i have several master servers, whether i must ensure that all the
> master server's serial are the same? i think this is a little complex,
> in particular zone is updated by dynamic update(In such a scenario, the
> serial number is controled by every single bind).
>
> is it correct?

You have an odd setup.

You _should_ only be doing updates on a single "master" with all of the
other servers being defined as slaves. If you have dynamic updates
going to multiple "masters" in one zone, you may want to consider
breaking it up into multiple zones, each with one master, or looking
into "allow-update-forwarding".

Sounds like you may want to look at re-engineering at some level.

[Phil Mayers]

On 11/05/2011 01:32 PM, Felix New wrote:
> if i have several master servers, whether i must ensure that all the
> master server's serial are the same? i think this is a little complex,
> in particular zone is updated by dynamic update(In such a scenario, the
> serial number is controled by every single bind).

That's a bad architecture (multiple masters with no coordination). Don't
deploy it.

Either use a single master, or deploy one of the solutions which
actually makes multi-master work, and coordinates changes and zone serial.

Having said that - you can set the zone serial via dynamic update. Just
add a SOA record with the required serial.

[Chris Thompson]

On Nov 5 2011, Alan Clegg wrote:

>On 11/5/2011 4:21 AM, kalpesh varyani wrote:
>> How does this feature address the risk that data provided by one master
>> might get overwritten by another?
>
>The use of the word "masters" in the configuration of a slave zone is a
>bit misleading. Under most circumstances, you list the authoritative
>servers, not "multiple masters".

Although Alan doesn't say so, this might suggest to some that you should
list *all* the authoritative servers. That's a very bad idea - you need
to arrange that the directed graph of "A can fetch from B" is acyclic.
Otherwise servers can get into the state that A thinks its copy of the
zone is up to date because B told it so, and B thinks so because A told
it so (or longer loops, of course), while neither of them are true masters
for it.

--
Chris Thompson
Email: ce...@cam.ac.uk

[Barry Margolin]

In article <mailman.1.13206216...@lists.isc.org>,

I don't think it's a problem. As long as ANY of the servers in the
masters list have a higher serial number, you'll fetch from it.

So if you have three servers, A, B, and C, A will check the serial
numbers on both B and C, and pull from whichever has a higher serial
number than the serial A already has.

--
Barry Margolin
Arlington, MA

[Mark Andrews]

In message <barmar-1BAA23....@news.eternal-september.org>, Barry Mar

golin writes:
> In article <mailman.1.13206216...@lists.isc.org>,
> Chris Thompson <ce...@cam.ac.uk> wrote:
>

> I don't think it's a problem. As long as ANY of the servers in the
> masters list have a higher serial number, you'll fetch from it.
>
> So if you have three servers, A, B, and C, A will check the serial
> numbers on both B and C, and pull from whichever has a higher serial
> number than the serial A already has.

Transfer graph loops prevent expire working as a safeguard against
loss of connectivity to the master source. They are not a issue
with respect to gettting the latest version of the zone.

If M is the ultimate master and A and B transfer from each other
and M, when M dies, the SOA queries A to B and B to A succeed causing
each of A and B to believe the its current zone contents as they
will both be serving the zone with the same serial.

I proposed a solution but couldn't get traction with the dnsext
working group. http://tools.ietf.org/html/draft-andrews-dnsext-expire-00

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Barry Margolin]

In article <mailman.5.13206390...@lists.isc.org>,

Mark Andrews <ma...@isc.org> wrote:

> Transfer graph loops prevent expire working as a safeguard against
> loss of connectivity to the master source.

Some people may consider that a feature.

Of course, they could also just set the expire time really high.