On Thu, 19 Sep 2002, Rick Moen wrote: > Quoting Ian C. Sison ([EMAIL PROTECTED]): > > > I'm too influenced by the 'program that does one thing, and one thing > > only, and does it d@mn well' methodology. That's why i'm not to keen > > on existing monolithic programs like bind and sendmail ( Apache has > > taken the middle ground with it's run time modules). Breaking up a > > service into several independent units makes for a cleaner source code > > (less interdependencies), and well defined and simple interfacing > > rules. The less moving parts in a system, the less things can go > > wrong... Of course they are harder to debug with all the IPC going > > around, but when you perfect the little 'proglets' the resulting > > efficiency is worth the extra time and effort. > > > > DJB has done this not only with the MTA but with the name server as > > well. > > In principle, this is indeed a better approach. (Of course, ultimately > it's results that matter, and modularity exacts its own cost in an > additional layer of structure.) > > > BTW, the 'drop priv' technique is done by both bind and sendmail, both > > notorious for its security problems before, so it's something endemic in > > monolithic designs. > > Whoa there! You're glossing over an absolutely _key_ distinction, > something regrettably common in these discussions: I refer to the > vital distinction between BIND 9.x and prior versions. > > Vixie inherited the codebase that eventually came to be called BIND from > a predecessor package at UC Berkeley. It was already spaghetti code > when he took it over (while at DEC) as of v. 4.9, around 1987. He and > Bob Halley added some enhancements in 1997 to create the parallel v. 8.x > codebase that became the preferred version for a while. But Vixie knew, > even then, that the codebase was hopelessly unmaintainable, and all 8.x > versions from that point on were attempts to stave off disaster while a > from-scratch replacement got built.
Understood. I knew that 9.x was a total rewrite, and didn't share any code with previous 8/4.x codebase (note that in Hacking Linux Exposed, the authors still refer to 4.x as the 'one true bind', but that's a sidebar). but in this case i believe they should have taken the time to split it up the way djbdns has. > So, it is not reasonable to attibute to BIND v. 9.x the security flaws > of the prior release series: There was a fundamental rewrite of a very > radical sort, separating the two. Maybe the vulnerabilities of the old codebase do not apply to 9.x due to the redesign/rewrite, but the principle of monolith design is generally asking_for_an_exploit(tm), and as expected, there has already been 1 security problem in 9.x (which counts) and another in the resolver library (which i think does not count..) I am unsure about MaraDNS, but i believe the little proglets of djbdns are clearly the way to go, if one has a little more time to develop, and debug such a design.. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
