Software review: djbdns

For years, the de facto standard for DNS has been BIND. In the recent years, other DNS programs have appeared. Most of these newcomers are targeted at big corporations that must manage thousands of zones. These programs often use a database backend. djbdns is different in that it is designed with security in mind. In this article I explain how I see the principles that are the foundation of djbdns and their implications.

The Unix way

The Unix philosophy has always been to make small and specialized programs and to pipe the information from one to the other. On the opposite is the Microsoft approach to make the only program you'll ever need where a spreadsheet, a database and a graphics program are bundled with a word processor.

djbdns follows the Unix philosophy in dividing the task in as much different programs as possible. To have all the features of BIND with djbdns, you'll need 6 different processes running (without counting their child): supervise, multilog, svscan, tinydns, dnscachex and axfrdns. This is a good thing, since these processes don't trust each others, if dnscachex gets corrupted, tinydns will remain sane. This is different with BIND where several attacks are based on corrupting the cache portion of the program to affect the DNS data served.

There's only one way to do it

You may know perl's motto There's more than one way to do it which shows the democratic and freedom values embedded in perl's culture. When I started playing with djbdns, I realised that its motto could be There's only one way to do it. At first sight it might seem like a sad thing to say, but you'll realise that is what the army as been doing all along. And well, the army is known to be secure.

You'll never see an army manual saying:

If you want to clear your rifle, you can start by removing the cartridge, you could also check out if there's a bullet in the chamber. If you feel like it, it is possib le to remove the powder in the chamber or oil the rifle. etc.

This sound pretty awkward and certainly pretty dangerous. As any army soldier will tell you that there is a strict procedure to clean a rifle and not following this procedure can result in lots of trouble for you.

It's the same thing for djbdns, for example, you need to use daemontools to drive you daemon, not TCP wrappers (inetd) or a stand alone daemon. Yep, only one way.

Security wise this really does make sense. Imagine five sequential operations, if there are three ways to do each, then there are 243 (3^5) different possible paths. Each one of these paths must be inspected and tested by the programmer to make sure that it's not possible to abuse it. Most of the times you'll end up with a couples of esoteric paths that have not been correctly tested and end up being exploited. On the other hand, if you only have one path through these five operations, you can expect that the programmer has thoroughly tested it. That's why IPv6 support is still only available as a patch while about every other program has IPv6 support built in. The fact is that IPv6 support build in would only be used by less than 2% of the users and adding complexity to the program for 100% of the users.

I believe that there's only one way to do it is a good thing, it may not be the way that you want to use, but if you're ready to make the sacrifice and use it, you can be sure that it's a pretty safe path.

Disclaimer: I don't know much about guns, so my cleaning procedure is really inaccurate.

No freedom

As with any army, if you're a soldier, you can't tell your Sergeant what you think would be a better way to do something, you must listen to his orders or quit the army. This is the same for djbdns, if you don't agree with a way of doing things, you can write to the mailing list to offer your opinion, but I doubt that it will be incorporated in the main source code. It goes against the there's only one way to do it philosophy, because it would require a lot of efforts to incorporate that change. Of course, this is not as strict as a real army, you can always modify the code source yourself and publish a patch, but you can't publish a modified djbdns. I talk about the strange licensing later.

As long as you trust D. J. Bernstein as your General, you'll be happy in djbdns army. As said differently by some people, djbdns is a good program if you're ready to accept Mr. Bernstein's way of seeing things.

The there's only one way of doing it philosophy can really reduce the excitement and synergy of open-source software, where several people contribute to a program to make it better. That's the price to pay to use this philosophy.

Ingenuity

The traditional way of doing DNS replication of your primary server is using zone transfers. Zone transfers are requests done by secondary servers to the primary server. In order to know when to request a new version of a zone, a serial number polling mechanism has been designed in the protocol. Every couple hours, the secondary servers request, using UDP DNS, the zone's serial number on the primary server. If the serial number is bigger than the one on the secondary server, a DNS zone transfer is requested. Because of size limitations of the UDP datagram, zone transfers have to be done in TCP. As you can see, this procedure is quite awkward and can lead to a lot of problems, including outdated zones on the secondary servers and security vulnerabilities during the zone transfer.

When creating djbdns, instead of blindly implementing the zone transfer mechanism, Dan Bernstein studied what was needed to replicate the primary DNS server on the secondary servers. He realized that the existing polling mechanism was working upside down and that the good way of doing replication was by a push mechanism. The push mechanism can easily be implemented using existing UNIX tools: rsync and ssh.

When the DNS administrator modifies a zone on the primary server, he types make to have it compiled and loaded into tinydns. If there are secondary servers, two lines have been added to the Makefile to launch rsync and send the binary differences immediately to the secondary servers. Since rsync is tunnelled into ssh, the data is encrypted and authentified. The replication is done in seconds, simply, reliably and securely. Absolutely brilliant. Bernstein at his best.

Licensing

djbdns distribution restrictions are quite exotic: you can download djbdns source code free of charge at cr.yp.to (cool address!), you can modifiy that source code at your will, but cannot distribute a modified version of djbdns. You are allowed, however to distribute a patch for people to apply over the unmodified djbdns. My guess is that these distribution restrictions are made to prevent software manufacturer from distributing a broken version of djbdns.

The problem is that most software manufacturers have standard naming procedures, so they often need to modify programs that they distribute so that they respect these standards. They can't do that under that license, that's why RedHat refuses to distribute a djbdns RPM(1). The debian people found a solution to this distribution restriction, they distribute a script that downloads djbdns unmodified from cr.yp.to, applies a patch, then compiles and installs it. This is indeed a very smart trick that completely bypasses the distribution restriction.

I really don't understand why Mr. Bernstein does not release djbdns under a less restrictive license, the debian script really show that this license is easy to bypass, making it totally ineffective. I guess that there's something that I don't understand here, because it seems to me that this licensing only results in problems. In my humble opinion, this restrictive license is the worst problem with djbdns right now.

1: Several individuals have released djbdns RPM, but at the time of writing RedHat has not.

Conclusion

djbdns is a real secure program. Everything has been designed with security in mind. There's even a US$ 500 reward if you can find a security hole in the latest version. To this date, none was found. (Lots of you will say that 500 bucks is worth not much for a security audit, but some people have a lot of free time on their hands these days.) Security has been chosen at the expense of other things, like experimentations and even some parts of the protocol. If you're looking for a production program that is secure and not going to change much, then djbdns is for you. If you want to experiment with DNS and try esoteric sections of the protocol, djbdns will not let you do it.