Quoting Steve Litt (sl...@troubleshooters.com): > Which of the preceding is best? I've always been partial to > dnscache/tinydns, but installing it is a long cumbersome procedure > giving Arch installation a run for its money. I've never heard of > Unbound, PowerDNS Recursor, or Deadwood.
The question you ask is very debatable. As you probably know, BIND9 is of questionable architecture, being a single monolithic all-singing/all-dancing binary, slow, large, overfeatured. I would rule it out on grounds of being not _just_ a recursive nameserver. PowerDNS Recursor is the recursive-server matching element to PowerDNS Authoritative Server from the same folks. Both are back-ended into SQL databases (default MySQL). Consequently, it's also a bit heavy-weight, so I'd rule it out on those grounds. (I've used both PowerDNS codebases at a large Internet firm where I was the DNS guy. I also did a migration of the company's external and internal DNS including many hundred domains from BIND9 to PowerDNS. PowerDNS is reliable but I don't like it overmuch.) Deadwood is by Sam Trenholme, author of MaraDNS, who is (fair disclosure) like you a friend of mine. He wrote it as the from-scratch replacement for the recursive-server daemon in the antecedent MaraDNS suite, i.e., if you install the currently-maintained MaraDNS 2.x suite, you get Deadwood as its recursive-server component rather than the original implementation -- but Sam also decided to package Deadwood separately for people who want _just_ recursive functions. As noted in my http://linuxmafia.com/faq/Network_Other/dns-servers.html#deadwood writeup, in a comparative test by Sam of compiling stripped binaries with the same compiler optimisation, Deadwood weighed in as the second smallest binary. Advantage: has good security history. Disadvantage: maintained by just one guy, and part-time at that. Unbound was the second effort by the .nl TLD people, NL Labs, after they wrote NSD, an authoritative server so successful it's now used by many TLD nameservers and root nameservers. Advantages: clean design, extremely well maintained, good security history. And it Just Works.[tm] Disadvantages: can't think of any offhand. To discuss dnscache (the recursive server from djbdns), you must discuss whose fork and with what patchsets, because DJB's version djbdns 1.06 codebase that was his final release cannot itself be recommended because of unpatched problems. Maintained forks: o zinq-djbdns by Mark Johnson o Debian djbdns/dbndns by Debian developer Gerrit Pape (both binary packages cited being built from single Debian source package djbdns). o N-DJBDNS by Red Hat developer Prasad J. Pandit There used to be a fourth, by Joshua Small, named LolDNS, but he orphaned his effort soon after he started it in 2013. (If you're an optimist, you could say it's completed and mature rather than orphaned. You be the judge.) The big question about any update of the historic djbdns 1.06 codebase is whether the maintainer has applied _enough_ patches to fix its many documented problems. Also, quality of the patches applied is something you could judge if you wanted to make a hobby of this. Advantages: Patched dnscache from zinq-djbdns was the smallest compiled binary in Sam Trenholme's comparison. Security history is good. Disadvantage: Original coder (by one of the world's most contentious personalities in software) is famously eccentric in his coding style along with everything else, and what he writes is FHS-hostile by strong default tendency unless the package works at it. According to djbware expert Jonathan de Boyne Pollard, some functionality problems remain even in patched dnscache compared to competitors, such as frequent failure to resolve Akamai and some other companies' DNS that do baroque delegations without glue records. Fair disclosure: Author Daniel J. Bernstein (DJB) back around 1999 adopted me as the official chief hate-object of his software cult, which was very amusing, although I've subsequently been supplanted by Theo de Raadt. For a decade, I had the distinction of being the only person mentioned by name in a major software licence, because Dan calls me an idiot on the Web page where he asserted the former proprietary non-licensing terms he specified for djbdns, qmail, etc. He called me this because of a 1999 Web page entry, now at http://linuxmafia.com/~rick/faq/warez.html#djb, where I discussed Dan's then-licensing and several other reasons why I chose to to not use or recommend Dan's software at the time. (Dan made legal threats in e-mail against me for having that essay on the Web. When I wasn't impressed and politely referred him to my attorney, he called me an idiot on his Web page. I link to a preserved copy of this, for its entertainment value.) In 2007, Dan yielded to criticism (mostly to OpenBSD throwing out all ports of his software because they got tired of his non-licensing[1]) by declaring most of his code including qmail and djbdns to be 'public domain' by fiat -- the only common licensing regime more-problematic than his former proprietary non-licence, e.g., has problems of non-deterministic legal effect, but good enough for those who like his software. I'm still called an idiot on the page for Dan's former non-licence, but it no longer applies to most djbware since 2007. ('Non-license' is a small joke: It's actually a licence, one that is/was proprietary through omission, the aspect I commented on on my Web essay, which I posted in 1999 after one too many people asked me why I disliked administering qmail for a living, and I decided to FAQ the answers so I could stop having that conversation.) [1] See http://linuxmafia.com/pub/humour/dan-versus-theo for the popcorn-worthy clash between Dan and Theo de Raadt, over this. (As a bonus, some OpenBSD people decided they really liked me a lot after noticing that Dan hates me. It's weird, but I'll take it.) _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
