Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.42!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!198.186.194.247.MISMATCH!news-out.readnews.com!transit3.readnews.com!panix!usenet.stanford.edu!not-for-mail From: Mark Andrews Newsgroups: comp.protocols.dns.bind Subject: Re: several master ip's for a slave zone Date: Mon, 07 Nov 2011 15:09:58 +1100 Lines: 48 Approved: bind-users@lists.isc.org Message-ID: References: <4EB317F9.9010808@ripe.net> <4EB533E8.3000101@clegg.com> NNTP-Posting-Host: lists.isc.org X-Trace: usenet.stanford.edu 1320639019 14240 149.20.64.75 (7 Nov 2011 04:10:19 GMT) X-Complaints-To: action@cs.stanford.edu Cc: comp-protocols-dns-bind@isc.org To: Barry Margolin Return-Path: X-Original-To: bind-users@lists.isc.org Delivered-To: bind-users@lists.isc.org In-reply-to: Your message of "Sun, 06 Nov 2011 22:54:40 CDT." X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org X-BeenThere: bind-users@lists.isc.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: BIND Users Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: x330-a1.tempe.blueboxinc.net comp.protocols.dns.bind:45 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? > > > > > >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