MaraDNS Advocacy
This article discusses the advantages and disadvantages of using MaraDNS,
and compares MaraDNS to a number of different DNS servers.
Table of contents
- MaraDNS
- MaraDNS in the press
- Posadis
- Pdnsd
- Dents
- MyDNS
- Other abandoned DNS servers
- BIND version 9
- Older versions of BIND
- PowerDNS
- NSD
- Other DNS servers
- Commercial DNS servers
- Djbdns
Why use MaraDNS?
MaraDNS has the following advantages:
- Secure. MaraDNS has a strong security history.
For example, MaraDNS has always randomized, using
a secure random number generator, the Query ID and source port of DNS queries;
and
was never vulnerable to the "new" cache poisoning attack.
- Supported.
MaraDNS has a long history of being maintained and updated.
Actively developed since 2001,
MaraDNS continues to be supported: The most recent
release was done on February 5, 2011. Deadwood, the recursive code that is
part of MaraDNS 2.0, is stable code.
- 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.
- 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. Keep in mind that MaraDNS may not
be for you. MaraDNS has the following, ummm, features:
- 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.
- MaraDNS support for BIND zone files uses a Python script to convert
zone files from BIND's format to MaraDNS' BIND-like format.
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:
MaraDNS in the press
MaraDNS has been praised in the press. Here are some examples of books,
articles, and papers which discuss MaraDNS:
- Mens, Jan-Piet (2008). Alternative DNS Servers: Choice and
Deployment, and Optional SQL/LDAP Back-Ends (Paperback).
UIT Cambridge Ltd. ISBN 0954452992.
This book devotes an entire chapter to MaraDNS
- Danchev, Dancho. How OpenDNS, PowerDNS and
MaraDNS remained unaffected by the DNS cache poisoning vulnerability
ZDNet.
This article affirms MaraDNS' excellent security design, pointing out
that MaraDNS was never vulnerable to the 2008 cache poisoning attacks.
- Schroder, Carla (2007). Linux Networking Cookbook (Paperback).
O'Reilly. ISBN 0596102488.
This book, on page 545, endorses MaraDNS,
stating that "My recommended combination is [...] MaraDNS for a public
authoritative server"
- João Antunes; Nuno Ferreira Neves; Paulo Veríssimo (2007), Finding Local
Resource Exhaustion Vulnerabilities, 18th IEEE International
Symposium on Software Reliability Engineering, Trollhättan, Sweden
http://homepages.di.fc.ul.pt/~nuno/pubs.html
This article discussion MaraDNS' denial-of-service resistance, pointing
out that "Figure 2, for instance, shows that the BIND server performs worse
than MaraDNS under the same attack, which means that the later is able to
sustain a larger number of attacks than the first"
- Rutherford, Matthew J. (2006), Adequate System-Level Testing of
Distributed Systems, Department of Computer Science, Boulder, CO,
http://mjrutherford.org/node/11
This PhD thesis mentions MaraDNS several times.
MaraDNS is used by a number of ISPs to serve thousands of domains. MaraDNS
is used by Boeing. MaraDNS is ready to be used by your business or
enterprise.
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 last release for this program was in 2004,
so these problems will probably 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 in the fall of 2006. 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.
MyDNS
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. (
Update: The software seems
to be updated with
MyDNS-ng)
Djbdns
Djbdns is now public domain code; note that there are at three
security holes in the most recent (2001) DjbDNS tarball that need
to be patched before compiling and installing DjbDNS.
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 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.
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).
(Update: It appears PowerDNS has made some effort to minimize
"DLL hell", and the PowerDNS recursor is now its own package)
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 than 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.
Other DNS servers
There are other DNS servers out there, such as
Unbound and
GbDNS.
I have not had a chance to properly evaluate these DNS servers.
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
This is a very polarizing nameserver; people either love
DjbDNS or hate it.
I have always felt it was an excellent piece of
software hapmered by a not-quite-Open Source license. DJB, however,
made DjbDNS public domain in late 2007, so I no longer
have any real issues with the package.
Note that DJB himself
hasn't updated the software for over seven years (except for the license).
The software, notably, has three unpatched security bugs (see below), and
its list of root servers is out of date.
One issue I have with DjbDNS is that it is a little more difficult
to set up than it should be. Three packages have to be downloaded (less
if you install DjbDNS in a non-standard way) and set up before you can
run DjbDNS. In addition, DjbDNS has to be patched. The security holes
have to be patched, of course, and another
patch has to be applied before it can compile in Linux.
The configuration process is sometimes difficult and requires a
different way of looking at software--a lot of people don't care
for it.
The authoritative nameserver emphasizes simplicity in the C code; in
particular, the parser for zone files isn't too sophisticated and the zone
files are unattractive for people used to BIND zone files. Unlike BIND,
the zone file allows arbitrary RRs not directly supported by tinydns
(the name of DjbDNS' authoritative half) to be added to zones. (MaraDNS
also has this capability).
The recursive server (dnscache) is somewhat unique among DNS servers.
It was, for many years, the only DNS server I know of that has a small
footprint and
doesn't use threads to make recursive queries. Deadwood finally became
feature complete in July of 2010 with the same capability, allowing people
choice in which small, non-threaded recursive DNS server to use.
One nice thing is that there are
a lot of third party patches for DjbDNS available. Want support for
the LOC record? It's not available (in a human-readable form) in tinydns'
zone file format, but there is a patch to change that. Want IPv6? Again,
it's available as a patch.
Many patches can be found at tinydns.org.
Here are some known bugs that DjbDNS has:
- There are problems resolving some domains with DjbDNS' resolver. This
is the 'akamai djbdns' problem.
ref
- DjbDNS does not correctly periodically check upstream DNS servers to
make sure a given domain has not moved.
ref
- The list of root servers included with DjbDNS is out of date.
ref
- DjbDNS can not compile in Linux without using a special
incantation.
patch
- 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.
ref
patch
- It is possible to send spoofed DNS packets to DjbDNS ref
- Subdomains can overwrite zone information with the AXFR client
ref
There are a number of unofficial forks of DjbDNS with patches to fix
some (or all) of these issues; one worth looking at is
Zinq.
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.