MaraDNS - a security-aware DNS server

MaraDNS A security-aware DNS server |  |
Erre con erre cigarro Erre con erre barril Rápido ruedan los carros En el ferrocarril
Main Download Changelog Documentation Search Blog Security
## 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.