Date: 21 Feb 2001 10:30:02 -0000 From: "D. J. Bernstein" <djb@cr.yp.to> To: arch@freebsd.org Cc: djb@cr.yp.to Subject: Re: DJBDNS vs. BIND Message-ID: <20010221103002.3475.qmail@cr.yp.to>
next in thread | raw e-mail | index | archive | help
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. See http://cr.yp.to/djbdns.html and investigate the facts for yourself. I bet you'll be happy with djbdns. If you have questions, send them to my dns mailing list. 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. 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.'' 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.) 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. 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. 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. 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. ---Dan 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?20010221103002.3475.qmail>