Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.protocols.dns.bind > #45
| From | Mark Andrews <marka@isc.org> |
|---|---|
| Newsgroups | comp.protocols.dns.bind |
| Subject | Re: several master ip's for a slave zone |
| Date | 2011-11-07 15:09 +1100 |
| Message-ID | <mailman.5.1320639019.68562.bind-users@lists.isc.org> (permalink) |
| References | (1 earlier) <4EB317F9.9010808@ripe.net> <CAAWTBVx4J5GpxkvE-SyvAiCcW-EyXzgcCVut0tMZv9uE2yG6Gw@mail.gmail.com> <4EB533E8.3000101@clegg.com> <mailman.1.1320621651.68562.bind-users@lists.isc.org> <barmar-1BAA23.22544006112011@news.eternal-september.org> |
In message <barmar-1BAA23.22544006112011@news.eternal-september.org>, Barry Mar golin writes: > In article <mailman.1.1320621651.68562.bind-users@lists.isc.org>, > Chris Thompson <cet1@cam.ac.uk> 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 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. > > 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: marka@isc.org
Back to comp.protocols.dns.bind | Previous | Next — Previous in thread | Next in thread | Find similar
Re: several master ip's for a slave zone Chris Thompson <cet1@cam.ac.uk> - 2011-11-06 23:20 +0000
Re: several master ip's for a slave zone Barry Margolin <barmar@alum.mit.edu> - 2011-11-06 22:54 -0500
Re: several master ip's for a slave zone Mark Andrews <marka@isc.org> - 2011-11-07 15:09 +1100
Re: several master ip's for a slave zone Barry Margolin <barmar@alum.mit.edu> - 2011-11-07 21:03 -0500
csiph-web