Sigh. I give up. Yes, I was technically being a little inaccurate, and yes, there are a zillion ways I could have explained that entire mess better, such as linking to Rick's excellent explanation of different DNS server types.

It frustrates and annoys me that you are being so dang pedantic about the issue. I think it would do you well to think about why it is that you annoy a lot of people.

Voice-Family: Leo having a conversation with Sheldon in an episode of "The Big Bang Theory".

No, Unbound and NSD do not have HTTP servers. Come on. I was just trying to explain a complicated concept in a half sentence; it's called an analogy.

To make the pedants happy: A DNS server is, if you will, akin to an office suite. Yeah, what's really going on is that there is an "authoriative DNS server" that serves arbitrary name-to-data mappings so that programs called "recursive DNS servers" can give said mapping to a client program and there's also non-recursive forwarding DNS servers and blah blah blah. I think the audience is falling asleep at this point...

Now, when I said above that a DNS server is akin to an office suite, I wasn't saying that there is a spreadsheet and a word processor included with DNS servers. However, if someone were willing to sponsor it, I would be perfectly happy to make a version of MaraDNS that uses SINK RRs and dynamic updates to allow people to perform document collaboration via DNS.

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

From a security perspective, BIND 9 is infinitely better than BIND 8 wasâ"and anyone else who remembers BIND 8's constant remote root exploits knows what I'm talking about.

The security holes in BIND 9 are along the lines of denial-of-service attacks. Worrying about someone being able to stop the DNS is much less to worry about than worrying about someone being able to control machines remotely.

You know, I keep hearing on Slashdot about the need for some kind of non-hierarchical peer-to-peer name resolution to replace DNS. What I haven't seen is a working proposal for such a system; the closest I've seen is Namecoin.

You know, you're not the first person who wants me to do all kinds of work and doesn't want to pay me, and you won't be the last one.

I have blogged about this before, and it comes down to this: If you want to be treated like a customer of MaraDNS, you first must become a customer of MaraDNS.

If you don't want to pay me money, you have the source code. You are free to either submit patches (which I would gladly host), or to make your own fork of the code.

You would be a more productive person by "lighting a candle" -- either paying me or by submitting patches -- than by "cursing the darkness" -- complaining that open source developers are not at your beck and call.

I would hardly call calling a single program bundled with MaraDNS before running it the first time a "stupid convoluted hoop", especially when said program is run by the built-in install.bat script and requires no user-interaction to run.

But, hey, if you would rather have CryptGenRandom() in the MaraDNS and Deadwood binary itself, show me the money and we'll talk.

I no longer implement features just because some anonymous identity on the web wants it, but money talks. Please discuss rates with me in private email before paying me.

While there pretty much isn't anything out there -- besides Windows -- without /dev/urandom, MaraDNS' Deadwood has a built-in default random "magic hash number" that changes for each and every point release of Deadwood.

On Windows, Deadwood includes a program for creating a random entropy pool file which is run when running the Deadwood install scripts. Deadwood will, by default, complain if it doesn't find that entropy on Windows.

You know, I knew this issue would come out of the woodwork one day; I went to some bother to have a randomized hash compression function for MaraDNS 2.0's recursive resolver (Deadwood).

From the relevant man page (this part was last updated in September of 2010):

To protect Deadwood from certain possible denial-of-service attacks, it is best if Deadwood's prime number used for hashing elements in the cache is a random 31-bit prime number. The program RandomPrime.c generates a random prime that is placed in the file DwRandPrime.h that is regenerated whenever either the program is compiled or things are cleaned up with make clean. This program uses /dev/urandom for its entropy; the file DwRandPrime.h will not be regenerated on systems without /dev/urandom.

[...]

If using a precompiled binary of Deadwood, please ensure that the system has /dev/urandom support (on Windows system, please ensure that the file with the name secret.txt is generated by the included mkSecretTxt.exe program); Deadwood, at runtime, uses /dev/urandom (secret.txt in Windows) as a hardcoded path to get entropy (along with the timestamp) for the hash algorithm.

Personally, I think it this is a pretty obvious attack to think of when designing a hash compression function.

Sorry to be completely off-topic, but you once mentioned on Slashdot that you stopped using MaraDNS because Unbound is more snappy for you.

I encourage you to join the MaraDNS mailing list and become an active member of the MaraDNS community. I have been able to get some funding to work on some of MaraDNS' slowdown issues you have complained about.

If you could become a part of the MaraDNS community, you could help us by giving us constructive bug reports where you see MaraDNS 2.0's resolver acting more slowly than Unbound resolver. Indeed, I got reports from over a year ago about Unbound being faster and did fix some bugs which were slowing down its recursive resolution; I closed the bug when MaraDNS was as fast as Unbound on my internet connection.

- Sam

Your information is out of date; I completely, from scratch, rewrote the recursive code of MaraDNS starting four years ago with far cleaner code.

That code was declared stable over a year ago and looking at its source code won't make you blind.

- Sam

Please stop spreading FUD. There have been 0 remote security holes discovered in djbdns.

Please lay off the crack, wake up, and smell the coffee. This kind of denial is flat-out dangerous.

I have a blog entry detailing the three security holes in djbdns and DJB paid the $500 security hole prize for djbdns years ago.

The most dangerous hole in an unpatched djbdns 1.05 install is the TCP "packet of death" that forces dnscache to restart (since SIGPIPE isn't caught by dnscache). I really should file a CVE for that security problem.

There is also CVE-2008-4392 as well as CVE-2009-0858; more information is in Debian's security page on djbdns.

Don't get me wrong, djbdns is an excellent DNS server. Unfortunately, it hasn't been updated for over 10 years and, since then, three different security holes have been discovered the djbdns package, the root server list has been updated, errno has been changed to make Linux more thread safe (requiring a patch to compile it), and so on.

djbdns can work -- but it requires patching by hand or using an unofficial fork like Zinq (which appears to still be supported -- the last release was done this year).

(I can also murmur darkly about the fact that djbdns uses a circular queue instead of a LRU for its cache, its lack of a Windows port, its need to use external helper programs to configure the server, etc., but, then again, its core recursive binary is even smaller than MaraDNS 2.0's tiny recursive binary. And three security bugs in the last decade is better than the 13 security issues in MaraDNS I have had to patch against.)