Re: several master ip's for a slave zone
In article mailman.5.1320639019.68562.bind-us...@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. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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
--
a...@clegg.com | acl...@infoblox.com
1.919.355.8851
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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 a...@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
--
a...@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-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Best regards.
Felix New
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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. AlanC -- a...@clegg.com | acl...@infoblox.com 1.919.355.8851 signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
several master ip's for a slave zone
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, ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: several master ip's for a slave zone
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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
