Date: Tue, 26 Mar 2002 04:51:55 -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: <20020326105155.GA7902@sleepy.wojomedia.com> In-Reply-To: <3C9FC19E.9BAC6FB8@mindspring.com> References: <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> <20020325234504.GA31239@sleepy.wojomedia.com> <3C9FBE01.DE7FFFB4@mindspring.com> <3C9FC19E.9BAC6FB8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I am responding to two of your posts together. On Mon, Mar 25, 2002 at 04:17:05PM -0800, Terry Lambert wrote: > We can actually consider that the ordering of updates is only > to ensure the availability of DNS records within some minimum > time after instantiation in the database. In fact, we could > really update in any order, and the only effect would be to > widen the maximum update latency window X from X to (2X-1). > This is an artifact of the forwarding of unknown requests to > the primary when the secondary is listed as authroitative and > has no record. This last sentence was the main part I had not considered. I could see that in your particular design that was a very important feature. On Mon, Mar 25, 2002 at 04:32:30PM -0800, Terry Lambert wrote: > It occurs to me that it's not obvious from this discussion so > far what I meant about the number of lines of code in the earlier > discussion of using DNSUPDAT to do zone creation on the secondary. Well I got that part fine. > to a transiently connected server on the customer premesis (these > days, "DSL" qualifies as a transient connection, from my personal > experience with a large customer base). I can agree with that just from my own personal DSL connection! > The djbdns method of achieving this result is to move the > complexity to some out of band mechanism involving per scripts, > rdist, and a human being (that last component is the one with > the lowest MTBF 8-)). Hmm, if you say "or a human being" I'd agree with you. There's nothing in djbdns that prevents you from automating these things. I think it's easier to say that djbdns is INCOMPLETE when it comes to these scenarios than to say there is something inherently wrong with its design (and don't confuse design with features - I understand djbdns still lack many features most of which Brad had pointed out). DNSNOT does not technically have to be part of the DNS server, for example. It could be a separate program. > and it still leaves the update of an > active server to a reload operation, instead of an update. Yes and no. Because of the design of cdb, every update could be considered a reload but you don't really have the penalties associated with a reload. The reload is essentially a rename() system call. cdb() opens/closes on each data serving so actually there is nearly zero penalty that I can think of, other than however long it might have taken to generate the new cdb file. If you have a huge zone file this could be an issue on a remote link - it's certainly not as clean as sending just an empty named.conf file, but you don't have to worry about the complexity of reloading the named.conf with bind either (I know this was back in the older days, but I always thought it was silly that the "recommended" way of running bind was to run it in a tight loop in a sh script just in case it crashes). Now, I also know that you understand filesystem semantics better than most so I am prepared to be englightened again. > Realize that a fully distributed DNSUDAT mechanism capable of zone > creation in both primary and secondary server resolves all race > windows in a way that a manually replicated set of primaries could > never hope to do. Absolutely. What I don't understand is why would you say that this could not be done with djbdns? Again, I think djbdns is incomplete in these type of scenarios, but one could design add on services, without modification to djbdns code, that achieve many of these goals. If you look at djbdns as a small tool in the overall scheme, I don't see anything wrong with it. If you want a tool or a suite of tools that'll do everything, then djbdns is very obviously not the way to go. I have always considered djb programs to be a set of starter tools that one could built upon. That's why I was puzzled when Brad insists it wasn't modular. I do very much agree that very often it lacks features that one wants by default, but I am continually surprised but what one could do with djb tools with a little thought. Thanks, 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?20020326105155.GA7902>