In article ,
Mark Andrews 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.
--
Barry Margolin
Arlington, MA
__
In message , Barry Mar
golin writes:
> In article ,
> Chris Thompson wrote:
>
> > 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?
> > >
In article ,
Chris Thompson wrote:
> 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 o
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 circumsta
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 b
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 sin
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 Cle
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 mailto:ana...@ripe.net>> wrote:
On 03/11/2011 23:14, hugo hugoo wrote:
Hi
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
s
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
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
___
Please visit https:
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 wrote:
> On 03/11/2011 23:14, hugo hugoo wrote:
>
> Hi Hugo,
>
> > I have seen that for a slave zone, it is possible to confi
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 ser
13 matches
Mail list logo
