Date: Tue, 26 Mar 2002 11:55:19 -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: <3CA0D227.3511A2C4@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> <20020326105155.GA7902@sleepy.wojomedia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim wrote: > > 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. 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. One way to deal with this might be to use the SRV records for differentiated service types to move the DNS server components themselves to a different port. There are two problems with this scenario: o There is no official support for this via the RFC process defining differential service types for DNS (this is easily overcome). o There is an intentional failure to support SRV within djbdns (this is not easily overcome).. Another way to deal with this would be local forwarding of unknown request types. This might be possible, but would need modification of the djbdns. It's also a case of the intentional failure to support, so doing this could have an adverse effect on the security model of djbdns, as well. > > 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. The overhead is predominantly in the system call processing; the open/read/close is threee sets of protection domain crossings. There is also file system semantic overhead (as you imply) in the close operation. The Single UNIX Specification has relaxed many of the "SHALL be updated" semantics into "SHALL be marked for update" semantics. This lets an FS compliant with the SUS2 and non-compliant with POSIX (e.g. almost any log-structured FS in use today) make a number of semantic shortcuts which take away much overhead. 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. > > 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 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 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. 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?3CA0D227.3511A2C4>