Quoting Steve Litt (slitt@???):

> 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.)