MaraDNS
A security-aware DNS server

Erre con erre cigarro Erre con erre barril Rápido ruedan los carros En el ferrocarril

Main Documentation FAQ Download Changelog Roadmap Contact

## MaraDNS Advocacy

This article discusses the advantages of using MaraDNS, and compares MaraDNS to a number of different DNS servers.

### Table of contents

1. MaraDNS
2. Posadis
3. Pdnsd
4. Dents
5. Other abandoned DNS servers
6. BIND version 9
7. Older versions of BIND
8. PowerDNS
9. NSD
10. Commercial DNS servers
11. 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; while someone else started maintaining the software, there hasn't been a release for over half a year. I have heard that pdnsd has some stability problems; since it appears to be not actively maintined, these stability problems may never be addressed.

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. No stable version of MaraDNS on a non-Linux system has ever had an exploitable security problem. The one and only denial-of-service problem was caused by Linux's broken TCP/IP stack and not by MaraDNS, and has long since been fixed.

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.