Date: Thu, 22 Feb 2001 04:21:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: djb@cr.yp.to (D. J. Bernstein) Cc: arch@FreeBSD.ORG, djb@cr.yp.to Subject: Re: DJBDNS vs. BIND Message-ID: <200102220423.VAA05547@usr05.primenet.com> In-Reply-To: <20010221103002.3475.qmail@cr.yp.to> from "D. J. Bernstein" at Feb 21, 2001 10:30:02 AM
next in thread | previous in thread | raw e-mail | index | archive | help
Hi; I stand by my evaluation. I don't think it's suitable code for many applications which I find interesting or necessary. People pressed me for my reasons above and beyond just the license; I gave them. Unlike others, I have not attacked you personally, either on this list, nor on the namedroppers list (the IETF DNSEXT working group, for those of you on the sidelines). As always, ignoring the emotional loading, your comments are interesting and thought provoking. > 1. Ever heard of citysearch.com? All their DNS records are published by > djbdns. Thousands more sites have switched to djbdns. One site is using > djbdns to publish records for hundreds of thousands of *.com's. > > But Terry claims that djbdns is suitable only for ``trivial uses.'' Wow. Your example shows volume, not reconfiguration complexity. Trivial is the opposite of complex; I use it as a technical term to describe the problem space for which DJBDNS is capable of mapping soloutions. BIND and Sendmail are large and complex, but in that complexity lies the majority of their utility. For what I was building, DJBDNS could not work without modification, and the modified code could not be distributed or sold afterward. I accept your right to license your code how you see fit, of course, but for me, that constrint was a show-stopper. > 2. It takes just a few seconds for tinydns-data to rebuild a typical > 10000-zone database and for rsync to push new data to secondaries. > > In contrast, for the same number of zones, BIND waits an average of > about 7 _minutes_ before it sends NOTIFY. Terry is wrong when he claims > that there's no latency with BIND; there is, in fact, massive latency. The design uses DNSUPDAT; I am _not_ engaging in rebuilds of the zones. I can not do this with DJBDNS, since it does not support DNSUPDAT. As discussed on namedroppers, I have relaxed the unjustified restriction against zone creation via DNSUPDAT, and I have a workable approach using a DNSSEC based security association for zone creation in the secondary, via DNSNOT. If I merely poke new data into the server, the NOTIFY is sent immediately, without a HUP, and without incurring a delay (on the system I was using, a 10,000 domain reload was ~45 seconds in BIND, not 7 minutes; since I'm not reloading, though, it really doesn't matter). > 3. The necessary use of rsync is a straightforward one-line command in > /service/tinydns/root/Makefile, as shown in the djbdns documentation. > Terry is wrong when he claims that ``synchronization is left as an > exercise for the student.'' The problem with this is not the method, it's the scripting necessary to synchronize multiple servers, and to retry in the case of a point to point connectivity failure between one system which has been updated, and one which has not. There were additional constraints on what ports would be passed through a state maintaining firewall, but that was an administrative barrier for me alone, and not really germane to the discussion. > 4. A new tinydns database atomically replaces the previous database. > The server switches to the new database for the next query. > > Terry is wrong when he claims that tinydns ``must be restarted for the > updates to take effect.'' He is wrong when he claims that frequent > updates would result in the server being ``largely unavailable.'' > > (Terry is also wrong when he implies that restarts are slow. Starting or > restarting tinydns takes a tiny fraction of a second. But this is a side > issue; there is _no_ outage when a database is updated.) 1200 machines calling in once an hour, with an update on connection setup and an update on connection teardown. is an update every 1.5 seconds. This assumes that the traffic is non-bursty. Using your numbers, which differ significantly from my benchmarks of the code on AIX, I still can't solve my update problem with DJBDNS. A large ISP trying to do something similar with their RADIUS IP assignments has only one choice at present, Microsoft's IAS (Internet Access Server), which integrates IP address assignment with DNS updates. For relatively static data, DJBDNS is probably fine; for more dynamic data, it's not. > 5. I have gone to great lengths to support DNS administration protocols. > For example, I designed the tinydns data format to be very easily > editable by external programs. Terry is wrong when he claims that I am > ``opposed to protocol level modification of DNS server contents.'' > > However, I do oppose Microsoft-style ``embrace and extend'' tactics. The > big problem with the BIND modification protocol is that the protocol was > (deliberately!) wedged into port 53. This is extremely inconvenient for > modular servers. This is actually the first time I've seen this objection tendered. It's a valid technical objection: most extensions, including DNSUPDAT _do_ operate over port 53. My suggestion, which you are probably not going to like, would be to use UNIX domain sockets and do descriptor passing; the alternative would be to set close on exec for all but the connection of interest, and exec a second program to do the work, or to rearchitect the server so that the modularization was on shared object, rather than programatic boundaries. Yes, I realize that these approaches would not work on some platforms where running DJBDNS might be desirable. As an ugly hack, you could make a connection from the "owner" of port 53 to the other program, and proxy the traffic. I wish you had raised this objection this baldly when DNSUPDAT was being discussed on namedroppers, rather than just calling it a bad idea. I think the other people would have been receptive to the idea of permitting the use of an alternate port as well as a port 53 piggyback. I certainly would have. I personally _must_ have the piggyback, due to firewall constraints on other traffic. I think it would be easy to seperate this out, still, if you wanted to bring this up in terms of DNS extensions having the possibility of different SRV records. A lot of your past arguments make a lot more sense in this context; frankly, I've never bought the "more programs are automatically more secure than less programs" philosophy, and it never really occurred to me that this would end up having implications for some implementation, when adding more operations over port 53. I personally stand by my namedroppers statements to the effect that I think all DNS data should be manipulable and retrievable over a single chokepoint, but I have sympathy for your problem, and I don't think it reasonable to architect a design which precludes a particular approach, with justification. > 6. I designed the djbdns server architecture so that one could easily > write servers using different types of databases. Look at tinydns and > rbldns and walldns (and pickdns, though tinydns now has the same > features) in the package. Or look at Bruce Guenter's sqldjbdns. > > Terry is wrong when he claims that I am ``strongly opposed to offering > alternate back ends.'' There is no truth to Terry's insinuations that I > rejected Terry's SQL ideas. There is also no truth to the similar > insinuations from Jack Rusher and Wes Peters. In fact, as far as I can > tell, these people have _never_ sent any email to the dns mailing list. Let me put this in context; my own servers that I care about these days are running out of an LDAP directory, not an SQL database; I'm personally not interested in using an SQL server. I think this would meet your "not in the protocol" objection an ability to programmatically update the data being served. Something which would result in people taking you much more seriously would be if the license was relaxed on the default back end or a stubbed out back end. > 6. Before tinydns (or dnscache) sees any untrusted data, it chroots and > drops privileges. Inserting an exec at this point would have no security > benefits and would turn installation into a chroot-BIND-style nightmare. > Terry is being silly when he says that ``you have to wonder'' about the > lack of an exec. When security is at issue, the less actual code that has privileges (even if they are later dropped), the better. My point was one of "in for a penny, in for a pound". I was not trying to be silly, I was attempting to express cynicism about where the line was drawn. > 7. djbdns is highly modular. Almost all of the program-level modules, > and many of the internal C functions, are thoroughly documented on my > web pages; Matt is wrong when he says ``the code is uncommented.'' > > For further discussion of code readability, see my bugtraq postings on > the Dijkstra phenomenon. Note that I did not complain about the readability of the code; I personally don't mind running "indent", and would have been happy had FreeBSD integrated it into the CVS checkin process so that people could quit complaining about where other people put their braces. I'd actually appreciate a pointer to the postings on bugtraq, if you have one; otherwise it will take me a while to get around to searching them out myself. Regards, 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?200102220423.VAA05547>