From owner-freebsd-chat Mon Mar 25 15:46:49 2002 Delivered-To: freebsd-chat@freebsd.org Received: from sleepy.wojomedia.com (ns2.wojomedia.com [216.107.102.3]) by hub.freebsd.org (Postfix) with SMTP id 5FB6D37B41B for ; Mon, 25 Mar 2002 15:45:05 -0800 (PST) Received: (qmail 31421 invoked by uid 1000); 25 Mar 2002 23:45:04 -0000 Date: Mon, 25 Mar 2002 17:45:04 -0600 From: Tim To: Terry Lambert Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <20020325234504.GA31239@sleepy.wojomedia.com> References: <000c01c1d3ab$6d2c6960$6600a8c0@penguin> <20020325015236.A97552@futuresouth.com> <3C9EFED0.DB176CB8@mindspring.com> <20020325115207.GA22032@sleepy.wojomedia.com> <3C9F1A16.207EA23E@mindspring.com> <20020325140022.GA23251@sleepy.wojomedia.com> <3C9FB0CB.C1C0CD89@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C9FB0CB.C1C0CD89@mindspring.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 25, 2002 at 03:20:43PM -0800, Terry Lambert wrote: > > First, I am assuming that you serialize the administration > > script (no parallel scripts going on). > > No. Database updates are atomic at the record level, and > derived data is a snapshot of a collection of records. So > the record is not there, it's there and it's old, or it's > there and it's new. I understand that. What happens if: database -> ns1 somebody mucks with the database (updates a serial # for zone for example) database -> ns2 From your previous description, I had assume that it was important for you to have consistency between ns1 and ns2 (and ns2 never has newer information than ns1). > This means that you can treat any record creation/update as > if it happened either before or after the derivation, and > the derived state is always consistent. > > If you couldn't do parallel updating, there'd really be no > reason to use a database instead of a big honking file lock. I am talking about serializing updates of named.conf in ns1 and ns2. > There are man problems with this. The first is that the > assumption of the primary and secondary machines having the > same zones. No argument there. > The third and final problem here is that this form of > replication is still subject to the negative caching > problem with the update latency, because the servers do > not maintain a hierarchical relationship. Thus, if you > have a domain delegation to your DNS servers, and one of > the DNS servers doesn't know about it, it's not going to > forward the request to a server which is updated earlier > (the primary) when it can't find the record locally. OK you got me on this point. That's a scenario I had not realized. > All of the top level DNS servers (the servers for "." and the > servers for the "in-adder.arpa.", "com.", "net.", etc. > delegations from "." run bind. > Form that perspective along, > you are taking your career in your hands if you run anything > else, should an interoperability issue pop up. Hey no arguments there. There is a reason I buy Cisco. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message