Date: Mon, 19 Feb 2001 10:12:05 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: josb@cncdsl.com Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <200102191012.DAA17412@usr05.primenet.com> In-Reply-To: <20010218233916.J28286@lizzy.bugworks.com> from "Jos Backus" at Feb 18, 2001 11:39:16 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I can't help getting the impression that people don't care to give djbdns a > proper look because of the way they perceive its author. Who cares what kind > of personality the author has, as long as the code works and is > well-supported? I looked at DJBDNS in serious detail, for use on a datacenter project within IBM. I found it wanting. Before that, I looked at it on each of its major releases, at least those which Dan posted to the IETF DNSEXT working group, where I was a participant. I found it wanting on each of these occasions. Unfortunately, it requires static configuration; in other words, every DJBDNS server believes that it's the primary. This would have cause significant problems for dynamic updates, which were needed for email relay by dynamic IP customers wanting to send email. Patching the server to permit these updates to occur automatically would not work, due to the license. This could maybe be lived with. Because all servers are "primary", and they have the same weight, as far as being authoritative servers, this means that updates to one server's data must be made to both servers. Worse, both must then be restarted for the updates to take effect. Even if I could ignore the problem with not being able to update a single server and have the secondaries "just work" because of NOTIFY, the need to shoot all my name servers in the head when I do an update is simply unacceptable. I can't rely on one server being up while another is reloading. With BIND, I only have to worry about this on zone creation, and I can stagger the reload on zone creates, so it's not really a problem. With DJBDNS, my hands are tied, and the frequency of update events when you have 500 customers doing an update each time they dial in, and dialing in once an hour or even more frequently, with another update on teardown, means that my DNS servers would be largely unavailable. No thank you. Philosophically, DJBDNS is Dan's baby; Dan is opposed to protocol level modification of DNS server contents. Philosophically, I want all of the operations on the server to occur over the protocol link, including zone creation in secondaries (it's trivial to permit zone creation in the primary in BIND; there is an over-zealous conditional test that should only be enforced on secondaries, since on a primary, there is a sufficient security association). Dan is strongly opposed to offering alternate back ends. There are patches to BIND 4.x to make it serve data out of an SQL database; for a recent project of my own, I've made BIND 8.4p<something> (I'm not using the areas with the recent security hole, but I supposed I should update the changes to make them run in BIND 8.5) serve its data out of an LDAP directory. Dan wouldn't let me do this with his code. If his stated philosophy is still the same, he would oppose it on the basis of his license, and he would not integrate patches I sent him on the basis of LDAP servers not being up to his security standards, and, since permitting non-static configuration, he would consider it a security hole that someone could modify the server contents over a protocol level link. I definitely buy into the basic idea that minimal servers with discrete roles can lend themselves to better security; I don't really buy the idea that having this architecture automatically results in better security, instead of just a false sense that there's better security. You have to wonder why DJBDNS isn't run from a program that opens the listen socket, relinquishes credentials, and then exec's the actual program, with close-on-exec unset only on the descriptors to the socket and data files (pened read-only before the exec, naturally). As to hackability: the other posters are right: why I want to hack it is up to me, and it doesn't matter why, only whether or not I can. As a service, I could probably hack the code (assuming I never wanted to license it out, and only ever sold service, which is the revenue model used by most of the failing ASP's and B2B's in the exchange business). I would be at risk, though: I wouldn't be able to go public, or be acquired, since that would constitute sale of the business, and therefore sale of the code. When I brought up the issue of the old Soft Updates license being a problem for Best Internet, I wasn't joking: technically, they were using Soft Updates legally, but sale of their business when they were acquired could have triggered the license clause which prohibited FreeBSD from being shipped with the code compiled into the kernel and enabled by default. Even ignoring my own hacking of the code, just like I can compile GPL code into the kernel, and use it myself, the patches on the DJBDNS port to make it work with FreeBSD have the same "binary nerve gas" effect, which would technically require that, before the sale of my business, the code be removed, and after the sale of the business, the code be recompiled and reinstalled by the new owners, since I can't distribute it that way, and still have a legal license to use the code. It's too much of a headache, and, from my personal point of view, and in accordance with the philosophy of an integrated, uncached control store (so that configuration changes take effect immediately), his code is seriously lacking. PS: on a similar note, I think there should be a 10 second or so timer in inetd, and it should stat the inetd.conf file for changes, so we no longer have to put up with cached state until we HUP the thing. I think "init" should have a similar thing for /etc/ttys; cached state data is inherently bad everywhere, not just in DNS servers. PPS: I think that reverse record updates should be permitted on the basis of having a forward record, and a request from the IP address of the machine the forward record points to, so I have some problems with BIND, as well, but at least they are limited to IPv6 stateless autoconfiguration and zone creation via DNSUPDAT in secondaries. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102191012.DAA17412>