<h2>MaraDNS Advocacy</h2>
This article discusses the advantages and disadvantages of using MaraDNS,
and compares MaraDNS to a number of different DNS servers.
<h3>Table of contents</h3>
<ol>
<li><A href="#maradns">MaraDNS</A>
<li><A href="#posadis">Posadis</A>
<li><A href="#pdnsd">Pdnsd</A>
<li><A href="#dents">Dents</A>
<li><A href="#mydns">MyDNS</A>
<li><A href="#etc">Other abandoned DNS servers</A>
<li><A href="#bind9">BIND version 9</A>
<li><A href="#oldbind">Older versions of BIND</A>
<li><A href="#powerdns">PowerDNS</A>
<li><A href="#nsd">NSD</A>
<li><A href="#nonfree">Commercial DNS servers</A>
<li><A href="#djbdns">Djbdns</A>
</ol>
<A name="maradns"> </A>
<h3>Why use MaraDNS?</h3>
MaraDNS has the following advantages:
<ul>
<li><b>Secure</b>. MaraDNS has a <A
href="security.html">security history</A> as good as or better than any
other DNS server.
<li><b>Supported</b>.
MaraDNS has a long history of being maintained and updated. MaraDNS was
originally created in 2001. MaraDNS 1.0 was released in 2002
and MaraDNS 1.2 was released in December of 2005. MaraDNS has been
extensively tested, both with a SQA process and with over four years of
real-world use. MaraDNS continues to be fully supported: The most recent
release was done on August 14, 2006.
<li><b>Easy to use</b>. A basic recursive configuration needs only a
single three-line configuration file. A basic authoritative configuration
needs only a four-line configuration file and a one-line zone file.
MaraDNS is fully documented, with both easy-to-follow tutorials and a
complete and up-to-date reference manual.
<li><b>Small</b>. MaraDNS is well suited for embedded applications
and other environments where the server must use the absolute minimum
number of resources possible.
MaraDNS' binary is smaller than
that of any other currently maintained recursive DNS server.
<li><b>Open Source</b>. MaraDNS is fully open-source, The license is a
<A href=license.html>two-clause BSD license</A> that is almost
identical to the
<A href="http://www.freebsd.org/copyright/freebsd-license.html">FreeBSD
license</A>.
</li>
</ul>
MaraDNS is the best DNS server to use if you need a lightweight, secure,
and actively maintained DNS solution. Keep in mind that MaraDNS may not
be for you. MaraDNS has the following, ummm, features:
<ul>
<li>MaraDNS currently spawns a thread for every recursive request that
is not in the cache. In other words, MaraDNS needs a good thread
implementation in order to process a large number of recursive
requests. Make sure your operating system has a robust threading
library before using MaraDNS to process a large number of recursive
request. <p>
I do plan on fixing this, but it requires a complete rewrite of
the recursive code, which will take six months to a year to
implement.
<li>In order to change any DNS records, MaraDNS needs to be restarted.
This is because MaraDNS uses a model that pulls DNS records from memory
very quickly. This will not be addressed until I adress the issue
with recursive threads.
<li>MaraDNS has support for BIND zone files only in the beta-test
branch, using a Python script to convert zone files from BIND's format
to MaraDNS' BIND-like format.
</ul>
Many, many DNS server projects have come and gone over the years; to
the extent of my knowledge, only BIND, MaraDNS, NSD, and Power DNS are
still being actively developed. Some other notable DNS server projects
which are not being actively developed:
<A name="posadis"> </A>
<h3>Posadis</h3>
This project showed a lot of promise; its zone file format, for example,
was superior to MaraDNS' 1.0 zone file format. It also has some graphical
programs which MaraDNS doesn't have at all. Alas, there have been some
problems with the program crashing, and some serious security problems with
the underlying code. The last release for this program was in 2004,
so these problems will probably never be resolved.
<A name="pdnsd"> </A>
<h3>Pdnsd</h3>
Pdnsd is an excellent little caching name server that predates MaraDNS.
Years ago, the principal author stopped actively maintaining Pdnsd.
Another person is currently maintaining Pdnsd; the last release was
done in the fall of 2006. I have heard that pdnsd has some stability
problems.
<p>
In terms of security, one of the last updates removed a buffer overflow;
contrast this to MaraDNS, whose design makes buffer overflows
nay-to-impossible.
<A name="dents"> </A>
<h3>Dents</h3>
Dents was a DNS server project which the author one day lost interest in
and stopped developing. It was not a usable DNS server when this
happened.
<A name="mydns"> </A>
<h3>MyDNS</h3>
MyDNS is a one-trick-pony DNS server, which allows people to convert
information from a MySQL database in to DNS records. The last release was
in January of 2006. People who want to use a SQL database with DNS are
probably better off using PowerDNS.
<h3>Djbdns</h3>
Djbdns has enough issues that I have <A href="#djbdns">an entire section</A>
detailing its problems. For now, it's enough to point out that djbdns
hasn't changed one iota for over five years, and that MaraDNS is more
secure than DjbDNS.
<A name="etc"> </A>
<h3>Moodns, oakdns, etc.</h3>
A number of other ideas for open-source DNS server projects have come
and gone over the years. Not one of them is being actively developed.
<hr>
Now that I have gone over the DNS servers that are not being actively
developed, I will compare compare MaraDNS to the servers that are
undergoing active development:
<a name="bind9"> </A>
<h3>BIND version 9</h3>
BIND9 is the emacs of DNS servers: It includes everything but the
kitchen sink. This results in a full-featured DNS server that has
about 5,000 features you will never use.
<p>
BIND is a very large application. On my system, a stripped BIND 9.2.6
binary is some 1,117,348 bytes in size. The maradns binary is only
150,912 bytes in size. The zoneserver binary, if needed, is only
110,912 bytes in size--resulting in a combined size of 261,824 bytes.
This is a fraction of the size of BIND, making MaraDNS more suitable
for embedded applications or on systems with limited resources (such as
heavily loaded web servers).
<p>
BIND's configuration is somewhat cryptic. For example, here a BIND
setup that uses a custom root server; this shell scipt will set up
all the files needed to start up BIND9 and run named in the current
directory:
<pre>
cat > named.conf << EOF
options {
directory "$( pwd )";
pid-file "named.pid";
allow-query { 127.0.0.1/8; };
};
zone "." {
type hint;
file "root.hint";
};
EOF
cat > root.hint << EOF
\$TTL 86400
. IN NS a.root.bogus.
a.root.bogus. IN A 127.0.3.1
EOF
chown root:root .
named -c named.conf
</pre>
Note that this basic configuration needs two different files with two
different syntaxes. Compare this to MaraDNS, which needs just one
simple four-line file:
<pre>
cat > mararc << EOF
chroot_dir = "$( pwd )"
ipv4_bind_addresses = "127.0.0.1"
recursive_acl = "127.0.0.1/8"
root_servers["."] = "127.0.3.1"
EOF
maradns -f mararc
</pre>
One key difference between this simple MaraDNS configuration and
the corresponding simplified named configuration is that the named
server will run as root with full access to the filesystem; the
corresponding simple MaraDNS confiuration will run as "nobody" in
a limited-access chroot() environment. While it is possible to
run BIND as an unprivileged user in a chroot() environment, this
configuration is non-trivial and not fully described in BIND's
documentation.
<P>
Indeed, BIND9 has had one remotely exploitable buffer overflow.
Basically, older versions of BIND9 linked to the OpenSSL library, which
had the offending buffer overflow. This is why MaraDNS has a strong
"not invented here" policy; the only external libraries that MaraDNS
uses are the libc library and the pthreads library. The reason for this
is to minimize security problems that external libraries may cause--a
problem that bit BIND9.
<p>
BIND, to its credit, does have a number of features which I haven't
yet implemented in MaraDNS. BIND supports standard RFC-compliant zone
files. While MaraDNS' csv2 zone file format is mostly BIND-like, there
are differences that make the two zone files incompatible. I have
written a converter and MaraDNS, in the beta-test branch, has BIND
zone file support. BIND, of course, also has full support for being
a DNS slave, including NOTIFY and IXFR support--features which I may
eventually add to MaraDNS.
<p>
One of the reasons why BIND has good RFC support is because the BIND
developers are the people most involved with the DNS standards. For many
years, BIND was the only usable DNS server that existed; as more and
more features were added to BIND, the standards were revised to have the
new features. There are no less than 96 different RFCs which at least
in part discuss DNS; very few, if any, people are familiar with all of
the relevant DNS standards. Not even BIND follows all of the standards;
for example, BIND only supports a QDCOUNT of 0 or 1, but the stadnards
say that a DNS server should support a QDCOUNT between 0 and 65535
(RFC1035 section 4.1.1).
<p>
In conclusion, while BIND9 has better RFC compliance and more features,
it is a far bigger program that is more difficult to configure than
MaraDNS. It is a bigger binary that uses up more memory than MaraDNS.
Its security history is not as good as MaraDNS' security history. The
two DNS servers have different compromises between code size, features,
ease of use, and security.
<A name="oldbind"> </A>
<h3>Older versions of BIND</h3>
If you are using an older version of BIND, such as BIND 4 or BIND 8, please
stop reading this article right now and immediately upgrade your DNS server
to either BIND 9 or to MaraDNS. Older versions of BIND are a security
incident waiting to happen.
<A name="powerdns"> </A>
<h3>PowerDNS</h3>
PowerDNS is a DNS server undergoing active development. The comparison
between PowerDNS and MaraDNS is similar to the comparison between
BIND9 and MaraDNS: PowerDNS has more features, but does not have
as strong of a security history as MaraDNS. For example, the
3.0.1 release had an update fixing a bug where "Certain malformed
packets could crash the recursor", and which could potentially
lead to a buffer overflow.
<p>
PowerDNS is harder to compile than MaraDNS; you need to download two
separate packages (the "Boost" packages and the core PowerDNS package)
to compile it. The Boost packages are easy to download and install, but
are quite big (over 10 megabytes in size) and took hours for me to
compile on my MaraDNS development laptop.
<p>
Even after compiling Boost with "./configure; make" followed by
"make install" as root, the PowerDNS configure script was unable
to find the Boost libraries. I had to manually move the
Boost include files from /usr/local/include/boost-1_33_1/boost to
/usr/local/include/boost.
<p>
After getting Boost installed, I also had to install MySQL on my
system before installing PowerDNS. This required installing some
six different .rpm packages. [<A href="#1">1</A>] <A name=r1> </A>
<p>
PowerDNS is the only actively maintained DNS server with "dependency
hell"--the requiring of external libraries that a baseline UNIX
system will not have. While this makes PowerDNS more feature-rich,
it also makes it harder to install and less secure (see the BIND portion
of this advocacy document for information on how an external library
can result in a remote root compromise).
<p>
PowerDNS' binary is quite big: A stripped binary is 1,055,732
bytes on my system; the pdns_control program is 118,140 bytes
large (again, stripped).
<a name="nsd"> </A>
<h3>NSD</h3>
NSD is an authoritative-only DNS server with BIND zone file support.
For people already using BIND in an authoritative-only mode, this is
a drop-in replacment. Like BIND, NSD has a cryptic configuration
format. There does not appear to be any reported security problems
with NSD, but, then again, making a secure authoritative-only DNS server
is easier than making a secure authoritative + recusive DNS server.
<p>
One interesting feature that NSD has is the separation of the zone file
compiler from the main program. This allows the core DNS server to be
smaller and use less memory resources.
<p>
The NSD binary is divided in four parts; the core nsd daeon is only
69,572 bytes in size (stripped). All four parts of NSD (including
the zone transfer program) have a total size of 237,348 bytes--smaller
than both MaraDNS (150,912 bytes stripped) and the zoneserver (combined
size 261,824 bytes). Then again, MaraDNS has functionality that NSD
doesn't have, including recursive DNS support, a secure random number
generator, and a secure string library.
<hr>
<A name="nonfree"> </A>
<h3>Commercial DNS programs</h3>
There are a number of commercial DNS programs available. Since I can not
freely download any of these programs, I can not fairly describe them. The
most popular commerical DNS server is Microsoft's DNS server, which, as far
as I can tell, is a fork of an older version of BIND. This DNS server
does not appear to be very secure; a couple of years ago, people pointed
out that this DNS server is vulnerable to DNS cache poisoning, a long-known
DNS security issue that has long since been fixed by all the open-source
DNS servers, including BIND version 8.
<p>
Microsoft's DNS server only makes sense if you are working for an
all-Microsoft shop, or have a clueless "pointy hair boss" who only
allows your workplace to use software with the "Microsoft" name on it.
<p>
There are other offerings, of course, but I think it's pretty likely that
all of them have a bigger binary than MaraDNS, and that some of them
have security problems.
<hr>
<A name=djbdns> </A>
<h3>Djbdns</h3>
Now that I have discussed all of the actively maintained open-source
DNS servers and touched on many of the DNS servers no longer being actively
maintained, I will now discuss in depth the most popular DNS server no
longer undergoing active maintainence: Djbdns.
<p>
It is very difficult for me to be critical of djbdns. Djbdns came out at
a time when the only other viable name server was the very insecure BIND8.
It allowed people who needed a DNS server to have a secure solution at
a time when BIND had security patches released almost monthly. I myself
have used it to keep installations I administered at the time secure.
<p>
In addition, Dr. Bernstein, djbdns' author, has written a number of
documents about keeping DNS secure which were very valuable during
the design phase of MaraDNS, and have undoubtably improved MaraDNS'
security. I have a good deal of respect for Dr. Bernstein's coding
abilities.
<p>
That said, djbdns has a number of issues which make it not practical to
deploy on new installations.
<p>
Djbdns has not changed one iota for over five years. In addition, it is
not legal to distribute a changed version of djbdns. This is the number
one problem with djbdns: Djbdns is <b>not</b> open source. Its license is
not compatible with one fundamental pillar of open source: The right to
distribute modified versions of a program.
<p>
This is a very practical problem; DjbDNS has the following known bugs:
<ul>
<li>There are problems resolving some domains with DjbDNS' resolver. This
is the 'akamai djbdns' problem.
<sup><font size=-2><A href="http://marc.theaimsgroup.com/?l=djbdns&m=113733374006571">ref</A></font></sup>
<li>DjbDNS does not correctly periodically check upstream DNS servers to
make sure a given domain has not moved.
<sup><font size=-2><A href="http://marc.info/?l=djbdns&m=113898636032186&w=2">ref</A></font></sup>
<li>The list of root servers included with DjbDNS is out of date.
<sup><font size=-2><A href="http://securepoint.com/lists/html/djbdns/2007-03/msg00001.html">ref</A></font></sup>
<li>DjbDNS can not compile in Linux without using a special
incantation.
<sup><font size=-2><A href="http://djbware.csi.hu/patches/djbdns-1.05.errno.patch">patch</A></font></sup>
<li>There is a denial of service problem where a remote attacker can
clear DjbDNS' recursive cache by sending a single "packet of death"
to a dnscache server.
<sup><font size=-2><A href="http://marc.info/?l=djbdns&m=104796742521473&w=2">ref</A>
<A href="http://marc.info/?l=djbdns&m=104804013229536&w=2">patch</A></font></sup>
</ul>
Installing djbdns is non-trivial; you need to either download and install
no less than three different packages, or hunt on the internet for the
non-official way to install djbdns using less packages. Djbdns will not
even compile on a modern Linux system without knowing the incantation
to make it compile. Compare this to MaraDNS, where installing is as
simple as downloading one package and typing in "make; make install", or
downloading a binary package (packages are available for RedHat/CentOS,
Debian, FreeBSD, NetBSD, Slackware, Windows, and probably other systems).
<p>
Once djbdns is installed, you will find some directories in the root
of your filesystem that weren't there before. This breaks UNIX and
Linux standards on how the filesystem can be organized.
<p>
All of these issues could be fixed if Dr. Bernstein had released djbdns
under an open-source compatible license. I understand that such modified
versions of djbdns may introduce security problems that Dr. Bernstein's
code does not have. The solution is simple: Distribute djbdns under a
LaTeX license, which is open source compatible and would require modified
versions of djbdns to be called something besides djbdns.
<p>
There are a number of programs which are still being actively maintained
long after the original author stopped contributing to the project. The
fvwm project is still thriving even though Rob Nation stopped working
on the project over 12 years ago. When Atheos development stopped,
its users forked the code and started the Syllable project. Both Perl
and Python are no longer being actively worked on by their primary
developers; most, if not all, code changes now come from other people.
It is a shame that Dr. Bernstein does not allow djbdns to have the same
development.
<p>
This wouldn't be so bad if djbdns was being actively manintained and bug
were being fixed. Dr. Bernstein, as far as I can tell, has no intention
to fix any issues with djbdns. He acts too arrogantly to acknowledge
that his programs have bugs, much less fix his bugs--I have never seen
him admit any of his programs has a bug.
<p>
Djbdns's license and the author unwillingness to fix bugs limits the
options for people supporting djbdns. For example, when somone pointed
out the bug with DjbDNS' recursive resolver not checking upstream servers
for moved domains, he was told that it was "[his]
own fault" for having this problem.
<p>
This goes back to the djbdns license; the person who blamed the user for
a djbdns problem really had no other choice. He could not patch djbdns
and distribute a modified djbdns to fix the issue. While he could made
a patch available, the number of djbdns users who would actually apply
the patch is next-to-zero. Since Dr. Bernstein has abandoned djbdns,
there is no system in place to allow people to fix issues with djbdns.
<p>
DjbDNS has a good security record; however, MaraDNS is, in fact, a
more secure DNS server. MaraDNS' codebase has the same level of
security as DjbDNS' codebase: There have been remote denial of service
security problems with both MaraDNS and DjbDNS. The difference is
that, with MaraDNS, all known problems have been patched and the code
has been updated. BIND version 9 also has a solid security record.
<p>
Djbdns was the best DNS option available when it came out. That was
over five years ago. Since then, the internet has changed and djbdns has
not kept up. Now that BIND9 and MaraDNS have a proven security record,
and are both under an open-source license and being actively maintained,
there is little reason to continue using djbdns.
<hr>
<h3>Conclusion</h3>
In closing, a number of DNS server offerings are available. MaraDNS is the
most secure recursive and authoritative DNS server being actively
maintained, and has the smallest footprint of any actively maintained
recursive DNS server.
<hr>
<h3>Footnotes</h3>
<A name=1> </A>
[<A href="#r1">1</A>] I understand that tools like "Yum" automate
this process; however I like to know *exactly* what packages are
on my system and Yum can make some major changes to my system
without my direct knowledge or consent if I am not careful.
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
14e99e777038dd8c1c2308be68fedb83
>
files
>
94
