MaraDNS Advocacy
This article discusses the advantages of using MaraDNS, and compares
MaraDNS to a number of different DNS servers.
Table of contents
- MaraDNS
- Posadis
- Pdnsd
- Dents
- Other abandoned DNS servers
- BIND version 9
- Older versions of BIND
- PowerDNS
- NSD
- Commercial DNS servers
- Djbdns
Why use MaraDNS?
MaraDNS has the following advantages:
- Secure. MaraDNS has the best security history of
any currently maintained DNS server; there have been no exploitable
security holes found in a stable release of MaraDNS that were caused by
MaraDNS' code.
- Supported.
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.
- Easy to use. 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.
- Small. 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.
- Open Source. MaraDNS is fully open-source, The license is a
two-clause BSD license that is almost
identical to the
FreeBSD
license.
MaraDNS is the best DNS server to use if you need a lightweight, secure,
and actively maintained DNS solution. 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:
Posadis
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 program does not appear to be actively developed
any more, so these problems may never be resolved.
Pdnsd
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 fairly recently. I have heard that pdnsd has some stability problems.
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.
Dents
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.
Djbdns
Djbdns has enough issues that I have
an entire section
detailing its problems. For now, it's enough to point out that djbdns
hasn't changed one iota for over five years.
Moodns, oakdns, etc.
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.
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:
BIND version 9
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.
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).
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:
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
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:
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
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.
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.
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 am
writing a converter and MaraDNS will soon have full RFC
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.
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).
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.
Older versions of BIND
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.
PowerDNS
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.
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.
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.
After getting Boost installed, I also had to install MySQL on my
system before installing PowerDNS. This required installing some
six different .rpm packages. [1]
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).
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).
NSD
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 thank making a secure authoritative + recusive DNS server.
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.
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.
Commercial DNS programs
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.
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.
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.
Djbdns
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.
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.
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.
That said, djbdns has a number of issues which make it not practical to
deploy on new installations.
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 not open source. Its license is
not compatible with one fundamental pillar of open source: The right to
distribute modified versions of a program.
This is a very practical problem: There are high profile internet
sites that djbdns' recursive resolver simply can not resolve. In order to
make djbdns' recursive resolver resolve these sites, after downloading
djbdns, you need to find the patch that fixes the broken recursive
resolver, apply the patch, and hope the patch doesn't break anything.
This isn't the only problem with djbdns' recursive resolver. Its list
of root servers is out of date by five years; two root servers have
changed since then. This makes the recursive server less reliable;
fixing this requires changing the configuration by hand, or by applying
yet another third-party patch.
Installing djbdns is non-trivial; you need to download and install no
less than three different packages. Djbdns will not compile on a modern
Linux system; you need to find 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".
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.
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.
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.
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.
Djbdns's license and the author unwillingness to fix bugs limits the
options for people supporting djbdns. For example, when somone pointed
out yet another bug with djbdns' recursive resolver on the djbdns mailing
list, he was told that people who have this problem that it was "their
own fault". In more detail, if someone has a domain with an provider
and, for whatever reason, wants to change providers without their current
provider's help, djbdns' cache will incorrectly point to the old provider
until the cache program is restarted.
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.
djbdns has a good security record; however, it is not the only dns
server with good security. MaraDNS has never had a priviledge escalation
security hole.
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 no longer any reason to use djbdns.
Conclusion
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.
Footnotes
[
1] 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.