It's ironic this is a front page story, because a few months ago I got in a pointless flame war over here at Slashdot over this very point (when, after going to a lot of effort to make a useful comparison of DNS servers, some pedant got upset that I used an analogy treating the Internet like the World Wide Web):
If you want DNSSEC and don't want BIND, your only other open-source option is Unbound; MaraDNS doesn't have DNSSEC either, and PowerDNS only has it for the authoritative code.
It's akin to an office suite because -- except for BIND, which is monolithic -- you have two distinct programs with different functions: The authoritative and recursive program. Just like you have a word processor and spreadsheet in an office suite.
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
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
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
