Date: Mon, 25 Mar 2002 08:00:22 -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: <20020325140022.GA23251@sleepy.wojomedia.com> In-Reply-To: <3C9F1A16.207EA23E@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> If you are adding a domain to a virtual hosting system that > includes DNS service for the domain, and the primary data > source is actually a database, then daemon configuration files > are actually derived data from the database. Yes makes sense. I believe most larger sites do it like this. > The secondary update was staggered to occur after the primary; > what this meant was that there would be an immediate zone > transfer from the primary for the new zone in the secondary, > so the only data that needed updating was the zone record > itself. Everything else happened on the primary. Because > the secondary was subservient in the hierarchy, the replication > of the data to the secondary was automatic, and guaranteed > correctness. In the djbdns case, both would be primary, and > one might contain stale data relative to the other (e.g. a > bad serial number) because the configuration data was derived. First, I am assuming that you serialize the administration script (no parallel scripts going on). If primary/secondary has the exact same zones, then with djbdns it looks like this: database -> ns1 rsync ns1 ns2 ns2 will always be consistent with ns1 (guaranteed by rsync and filesystem semantics) if rsync is triggered after ns1 update. I agree it's more complex, from the administrative script side, if they don't have the exact same zones. The hierarchy must be enforced on the administrative script side. I agree with your points. On the other hand, djbdns solves a specific set of user needs very well (basically, those that maintain n servers each of which containing the same zones). I think it really depends on your needs. Thanks for the clarification. 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?20020325140022.GA23251>