From owner-freebsd-chat Tue Mar 26 12:22:31 2002 Delivered-To: freebsd-chat@freebsd.org Received: from sleepy.wojomedia.com (sleepy.wojomedia.com [216.107.102.3]) by hub.freebsd.org (Postfix) with SMTP id 5674E37B419 for ; Tue, 26 Mar 2002 12:22:22 -0800 (PST) Received: (qmail 16394 invoked by uid 1000); 26 Mar 2002 20:22:21 -0000 Date: Tue, 26 Mar 2002 14:22:21 -0600 From: Tim To: Terry Lambert Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <20020326202221.GA16201@sleepy.wojomedia.com> References: <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> <20020326105155.GA7902@sleepy.wojomedia.com> <3CA0D227.3511A2C4@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA0D227.3511A2C4@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 > If this were the case, then it would be non-interoperable, unless > you specifically dedicated a VIP to the task; the problem is that > you'd have to bind multiple programs to the same port/IP pair. > About the only way you could do this would be to use the BPF, as > seperate programs don't allow for the idea of a MUX based on the > query type within the packet. This is considered a security > feature of djbdns. Yes I agree this is a design limitation. I always figure djb would one day write a mux in front of all his *dns programs or figure out another way. Maybe not. ;-) > But... > in the case of the close semantics, items maked for update are > required to be updated on final close, and so you eat the full > overhead, even if you play fast and lose with the POSIX compliance > and comply with the lesser semantics of the SUS2. > Overall, opening and closing a file each time is a very bad thing, > performance-wise, even though it resolves a number of ordering > issues. Hmm, I always thought cdb is operating under these principles: 1) the file is never updated (so close() shouldn't be too costly, if at all. You certainly understand under the hood better than I on this) 2) the rename() operation occurs fairly infrequently (i.e. once every minute or 5 minutes at most). 3) the OS is reasonably smart about caching the file so repeatedly open(), 2 seeks(), 1 read(), and close() is relatively lightweight. So I would not have guessed close() is a big problem. > I think we are back to the port/IP pair conflict for listens for > incoming requests. The djbdns really can't support an overall > framework without modification. I am in full agreement here and the rest of your e-mail. Tim > As implementations, they are somewhat easier to understand,if you > can get around the coding style, which make them good examples of > minimal implementations, as long as you are aware of the inherent > limitations they have with respect to the RFCs, up front. They > would be a lot more useful as an educational tool, if there was > accompanying documentation that explained those limitations up > front. > > For deployment, especially large systems deployment, where your > ability to sell in place of a competitor comes as a result of > service availability and turnaround time, I think that djbdns can > not be a first choice. > > The ISC implementation (bind) has historically been more prone to > security problems; on the other hand, I think these have been > addressed in bind 9: the original code was not intended for a > deployment into an actively hostile network environment, while > the new code is. There's no reason to throw the baby out with > the bathwater. > > -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message