Slashdot Mirror

Maybe I just haven't bothered to look hard enough,

Like maybe an actual search?

but I didn't know there were any other Open Source name servers out there.

You mean, like these?

• CustomDNS
• DENTS
• djbdns
• dnsmasq
• DNSJava
• dProxy
• MaraDNS
• MyDNS
• pDNSd
• Posadis

djbdns doesn't count and we both already know that

Ah, I see. It's not "Open Source" software because it isn't published under an "Open Source" license, right? (sigh) Dan Bernstein is a total security freak. He doesn't trust ANYBODY. He especially doesn't trust anybody to distribute modified, binary versions of his software, ruining his reputation when one of their "enhancements" results in a security hole. This already happened once when a Qmail add-on was discovered to have a security problem, and thereby tarnished Qmail's otherwise perfect security record.

So he ONLY authorizies distribution of his ORIGINAL source code. No modifications allowed, except as diffs to the originals. And if you apply those diffs and something breaks, don't blame him; blame the author of the diff.

You might disagree with Dan; he's a hard-nosed, inflexible so-and-so. But he's got style, and his programs are a beautiful model of efficiency.

The Open Source community could use a few more people like Dan.

and we both already know that so don't bother with beating that dead horse.

Such Style! Such Wit! Such Argument! Such Rhetoric! Such Unquestionable Authority!

Such a sterling example of my sigfile:

• By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
• By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead).
  Indeed, if you want to support TCP under tinydns, you have to configure an optional program called "axfrdns", which was intended to handle zone transfers, but also happens to share the same database as tinydns, and can handle generic TCP queries.
• The suggested method for copying contents of DNS zones is rsync, scp, or other remote copy tools. The DNS standard method of zone transfers (query type "axfr") is only supported as an additional, disrecommended method.
  The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.
• Without a patch from a third party, tinydns does not listen to more than one IP address. If you have a multi-homed server, you have to apply a patch from someone other than they author, before you can get it to listen on more than one address/interface.
• Without a patch from a third party, tinydns does not support the standard "NOTIFY" protocol of informing secondary nameservers that the zone has been updated, and that they need to check the SOA serial number and download a new copy (if they don't already have it).
• Without a third party patch, tinydns does not support standard SRV records (which are intended to ultimately replace MX records, as well as perform similar functions for services other than mail).
• Like tinydns, dnscache will not bind to more than one IP address without a third party patch.
• Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.
  While this is not the recommended mode of configuration, some sites don't have the luxury of having separate authoritative-only and caching/recursive-only server(s), and need to mix them both on one machine (or set of machines). With the BIND 9 "view" mechanism, this is relatively easy to do. With djbdns, this is impossible.
• There aren't even any patches that can get djbdns to implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely to be created (my understanding is that the author is strongly opposed to them).
  Unfortunately, as time goes on and more and more people are doing things like IPv6, VPNs based on IPSec, or people just care about being able to cryptographically prove that their servers are handing out the only correct information and that the clients are able to cryptographically verify this fact (think: electronic banking), these kinds of features are going to become ever more commonplace.
  Note that, with the advent of BIND 9, you can create a caching-only server that will validate cryptographically signed records, and all clients can benefit even if they do not themselves implement any of the new DNSSEC features.
• There are a number of things that djbdns does which I believe to be outright bugs. However, the author of this package simply refuses to accept that his code could be anything less than 100% perfect, and while he claims to have a "bounty" that he will pay for any bug that is found, in reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse to accept some purported bug, but then to quietly fix the code with future releases.
  So, let's look at some of these bugs:
  • When an IQUERY is sent to a djbdns server, it will respond with opcode set to QUERY. (it should simply copy the opcode, not make something up).
  • DNSCACHE (the caching server) does not respond to queries with the RD bit clear in the query. (Instead of simply answering from cache without recursing the dns-tree).
• One argument frequently used to support the use of djbdns over BIND is performance. Upon further investigation, this claim simply does not hold water.
  Benchmarks published by Rick Jones have clearly shown that BIND can scale up to at least 12,000 DNS queries per second, and there is every indication that BIND 9.2 will be able to go considerably higher. The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second, but that is the highest number reported. Other people on the bind-users mailing list have indicated that they have performed their own (as yet unpublished) benchmarks of tinydns, and that it had notable performance problems that BIND did not suffer.
  The best published benchmarks from the author for dnscache report a query handling rate of less than one million records over a 4.5 hour period of time, which works out to an average of less than sixty-two queries per second. Even if you look at numbers of queries per CPU second, the best numbers they can provide are 13.7 million queries over a four week period of time with 128 minutes of CPU time used (an average of slightly less than 1784 queries per CPU second).
  Compare this with the requirement from RFC 2010 "Operational Criteriafor Root Name Servers" (since obsoleted by RFC 2870 "Root Name Server Operational Requirements") is that the machine and software in question be able to handle at least 2000 queries per second, and be scalable to levels higher than that. Indeed, recent reports have indicated that a.root-servers.net (considered by many to be the "primary" root nameserver) is currently handling around 12,000 DNS queries per second at peak.
  Preliminary benchmarks published on the bind-users mailing list have indicated that, on the same hardware, there is little or no performance benefit to using dnscache as opposed to BIND 9.1.2, and when these tests are re-run with BIND 9.2, I'm sure that it will come out even faster.
• Unfortunately, a lot of the reasons the author gives for running djbdns instead of BIND are related to problems in older versions of BIND which have been fixed or are largely non-issues in later releases of BIND 9.
  For example, he makes a big point of tinydns being better than BIND, because while the process is starting up, it still answers queries. While previous versions of BIND would not answer queries during startup, this is no longer a problem with BIND 9.
  Dan also makes a great deal of the fact that the djbdns tools run as a user other than root, and in chroot() environments. While the "monolithic setuid root" situation was an issue with older versions of BIND, even more recent releases of BIND 8 could be easily run as a non-priviledged user in a chroot() environment, and this is the preferred method of running BIND 9.
  Contrariwise, one of the legitimate big complaints about older versions of BIND is that they implemented zone transfers in a separate program. If the database was large, then the fork()/exec() overhead was large, and the system could seriously thrash itself to death as it copied all those pages (for systems without copy-on-write), only to immediately throw them away again when it fired up the named-xfer program. With BIND 9, this problem is solved by having a separate thread inside the server handling zone transfers, and no fork()/exec() is done. However, tinydns/axfrdns goes back to the fork()/exec() model that was so greatly despised.

Suffice it to say that there is absolutely nothing that djbdns does that I believe can't be done at least as well (or considerably better) with BIND, and there are no security benefits it provides that cannot be provided at least as well (or much better) by a proper installation of a modern version of BIND.

I believe in the "security through diversity" scheme as much as anyone, but I'd take root nameservers running a program written in Bourne shell over djbdns. Hell, I'd rather fall back to using HOSTS.TXT than use djbdns.

Unfortunately, the other alternative of DENTS is also unsuitable for use as a production nameserver.

Show me something that is sufficiently better than BIND (and open source), and I'm sure that everyone will quickly gravitate towards it. Until then, BIND is the best we've got.

kindbud wrote:

I can hardly say enough good things about Dan's suite of DNS servers and client programs.

Having gone through the annoyance of administering a qmail site, I don't suffer from this disability.

dnscache, dnsfilter, tinydns, pickdns, walldns, rbldns, axfrdns, axfr-get, and the sundry associated libraries are just yet more screwball non-free software from Bernstein: He can keep 'em, and all his other non-FHS-compliant offerings. If I switch to anything, it'll be the GPLed Dents package.

Rick Moen
rick@linuxmafia.com

I for one will be quite happy when Dents is a suitable replacement for BIND. BIND seems to be quite old and crufty at this point, and Dents has a very nice design so far. Modular everything, and CORBA for administration. No more overloading of signals and crap like that. Whee!

A lot of people are bringing up DENTS. It's an alternate DNS implementation, dedicated to remaining 100% Free Software, and it's technically superior too! Take a look, it's a really cool project. It's important to have another Free Software alternative to BIND, even if BIND is itself Free Software, just because DNS is so critical to the entire Internet.

It's a mistake to put proprietary elements in IETF standards (and non-IETF standards as well). If RSA isn't willing to open this up, we're just going to have to develop an alternative to the standard (which is already in progress) and a way to gateway between the two standards.

And last, this is one of the more mature Slashdot discussions concerning Open Source that I've seen in a while. Good going, folks!

Thanks

Bruce Perens

Yes, Dents is a replacement for BIND. It is currently in active development.

If you havn't looked at Dents yet, you should. It's a nifty modular DNS server. And, AFAIK, there is no "non free" code.