Date: Mon, 25 Mar 2002 15:20:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Tim <tim@sleepy.wojomedia.com> Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim 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. 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. > 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. There are man problems with this. The first is that the assumption of the primary and secondary machines having the same zones. In the stealth primary configuration, this is not the case, because having the primary and the secondary be identical is not adequate to do load splitting, only load sharing. For example, say I have 30,000 domains, to pick a small number. My load has reached the point that I want to divide it up, since the load on a signel machine is too high. So I break it into 3 pieces, and I have 3 secondary servers, and one primary. Let's call these pieces (A,B,C) of 10,000 records each. Let's call my primary p and my secondaries (q,r,s). I now distribute my load; the result is: p (A,B,C) 30,000 records q (A,B) 20,000 records r (B,C) 20,000 records s (A,C) 20,000 records Using this approach, I can scale to any number of records, maintain redundancy in perpetuity, and limit the load on every machine. If the primary is not in the rotation for answering user requests directly, then it can handle a much higher load. The second problem with this is that it assumes that the firewall administration will allow a firewall hole for the rsync operation. In general, firewall holes are only made when they have to be, and any hole has to have incredible justification. Any machine that can be contacted through such a hole has to be, at best, in a DMZ, with two more firewalls between it and the corporate network. Even assuming you can get permission for the firewall hole for rsync (you won't be able to; the protocol has not gone through the vetting process, and neither has the software), you have a 3 month wait. There's actually an entire infrastructure which has grown up around getting through firewalls without the cooperation of the firewall administrators: it's called "XML". 8-). 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. > 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. Sure. If you are a small user, and aren't responsible for a large chunk of the Internet, and you don't have to worry about scalability, and don't have service availability issues, then djbdns is OK. 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. Frankly, risking my career on my own skills and knowledge is no real risk (IMO, of course); I do it daily. Risking it on the interoperability of software I haven't personaly burned a lot of time on, though doesn't seem quite sane. And risking it on software where I *know* there is going to be introduced update windows is quite insane. 8-). > Thanks for the clarification. No problem. -- Terry 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?3C9FB0CB.C1C0CD89>