Date: Mon, 25 Mar 2002 17:45:04 -0600 From: Tim <tim@sleepy.wojomedia.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <20020325234504.GA31239@sleepy.wojomedia.com> In-Reply-To: <3C9FB0CB.C1C0CD89@mindspring.com> References: <p05101505b8c430e28572@[10.0.1.9]> <000c01c1d3ab$6d2c6960$6600a8c0@penguin> <p05101509b8c47b17d088@[10.0.1.8]> <20020325015236.A97552@futuresouth.com> <p0510150eb8c48ba6b1f4@[10.0.1.8]> <3C9EFED0.DB176CB8@mindspring.com> <20020325115207.GA22032@sleepy.wojomedia.com> <3C9F1A16.207EA23E@mindspring.com> <20020325140022.GA23251@sleepy.wojomedia.com> <3C9FB0CB.C1C0CD89@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020325234504.GA31239>