Date: Tue, 26 Mar 2002 14:22:21 -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: <20020326202221.GA16201@sleepy.wojomedia.com> In-Reply-To: <3CA0D227.3511A2C4@mindspring.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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020326202221.GA16201>