Hackszine.com: DJBDNS, DNS exploits, Bernstein, Schneier, and security by design

DJBDNS, DNS exploits, Bernstein, Schneier, and security by design

If you haven't been living under a rock, you've probably heard of the DNS vulnerability that Dan Kaminsky announced about a half year ago. The plan was that Kaminsky would be working with DNS server vendors to provide a patch, giving ample time for administrators to upgrade before the details of the exploit were released later this year. Unfortunately the exploit was leaked prematurely, causing a general freak-out mode amongst people that administer DNS systems.

When I read the article on Slashdot, the "all name servers should be patched as soon as possible" quote dropped a bit of scare on me too. What about my sad little DNS server? I envisioned spending an evening working through a time consuming process of patching and reconfiguring things that I haven't had to touch in years. Much to my pleasant surprise, djbdns, D. J. Bernstein's DNS server, was not vulnerable. My decision to use djbdns a number of years ago was primarily due to his vocal philosophy of engineering security by design instead of by response.

Bruce Schneier's analysis of things is spot on as usual. It's a solid case study for hygienic software engineering practices and the design of secure systems.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

The djbdns server wasn't pre-installed on the Linux distro I based my poor old server on. DJB's deamontools package, which manages the startup and shutdown of the service, was annoying to deal with when every other application just uses a normal init rc script. The dns server configuration and setup was also unfamiliar to me, having previously only worked with BIND zone files.

There's one other thing that has really been different with djbdns than any other DNS server I've ever administered: I've never had to patch it. I've only had one other software experience like this, with the qmail mail transfer system. Qmail is also designed by Bernstein. Hmm.

If you're upgrading your DNS server anyway, maybe now is the time to start thinking about your alternatives.

Daniel J. Bernstein's djbdns server
Schneier - The DNS Vulnerability
DJB on DNS forgery
Slashdot - Kaminsky's DNS Attack Disclosed, Then Pulled

Posted by Jason Striegel | Jul 29, 2008 08:52 PM
Cryptography, Network Security, Software Engineering | Permalink | Comments (6)

Comments

Newest comments listed first.

Posted by: netcrusher88 on July 29, 2008 at 10:41 PM

Personally I'd just patch and not bother with going to djbdns right now - you're going to need to switch back to BIND or something when you roll out DNSSEC, since djbdns has been abandoned (although it is public domain) and BIND already has DNSSEC support (though certain features aren't implemented yet).

Posted by: Anonymous Joe on July 30, 2008 at 5:39 AM

Why don't you marry him?

Holy crap, while I'm a fan of this site, the last time I've seen someone gets stroked like that was in a porno. Dan Bernstein has an over-inflated ego, and with editorial like this, it's no wonder.

Make sure you use plenty of lube.

Posted by: Matt on July 30, 2008 at 7:03 AM

Be careful

Since I have to deal with djbdns on a daily basis - as well as qmail, I would suggest that you fully evaluate these systems before you make a switch. It's a great system if you don't mind if your dns just stops working for unknown reasons now and then. Also, if you like reading m4, you'll really enjoy reading zone files and logs.

To get qmail to function as a "good email citizen" requires some patching. Sure, qmail is open source now. Ring me up in 1998 when it would have mattered.

I don't know DJB, but I've heard the rumors - but I figured some honest feedback from someone who administers these kinds of systems in a medium-sized environment might be useful. They work fairly well, but they make my life more difficult than it needs to be.

Posted by: Jason Striegel on July 30, 2008 at 7:38 AM

I think the point of this post is that here's a great case study for security by design. Here's an application created 8 years ago that remains secure against a modern day attack, an attack to which pretty much every other implementation fell victim.

It's no news to anyone that DJB is caustic, and that's probably done more to reduce the adoption of his software over the years than anything else. Thing is, we _should_ be choosing software because it was designed well, not because we want to marry the designer.

I don't choose my DNS server because the creator had a slick website or a pleasant attitude. I'm not going to switch to an inferior filesystem just because the creator was a jerk in the community for 10 years and then murdered his wife. Full disclosure: I actually switched to ext3 a while back, but hell, you get my point.

Bernstein isn't really the subject here. Rather, his software is the example. What's important to take away from this is that there is a software development model that works. Software should be crafted with a specific goal in mind: security.

Matt, you make a valid point regarding ease of use and simplicity. That's certainly a consideration, but I don't think it trumps security and solid design on its merits alone. When I started using qmail and djbdns, it wasn't because I liked administering it (I didn't), it was because it was highly recommended by a decent sized ISP administrator that I trusted, and I could see that some care had been taken with the design of the software. Folks should use what they are comfortable with. It doesn't matter who made it—I'm most comfortable with secure software.

Posted by: Jeff on July 30, 2008 at 4:55 PM

Jason

I agree with many of your points, but believe that we should strive for the best of both worlds. Everytime I think we have turned the corner and achieved the next best thing with regard to security, ease of use and integration, someone drinking cases of redbull and smoking cartons of cigarettes in their basement proves us wrong.

Posted by: Russell Nelson on July 30, 2008 at 6:22 PM

never had a problem with djbdns

I have no idea what Matt is talking about. I've never had djbdns stop serving records except when I've filled up the file system. Djbdns wouldn't be the only thing that pauses when the filesystem is full. And when you free up space it continues without any problems.

Netcrusher88 is blowing smoke. DNSSEC doesn't work; it's never worked; and it will never be implemented, because it can't work. Crypto software doesn't fall on its face because the crypto gets broken. It fails because key distribution doesn't work. Anyway, now that djbdns is in the public domain, we can add DNSSEC when (if) it's been demonstrated to work and have value. In the meantime, implemented but unused features are a SECURITY HOLE waiting to be discovered.

djb is only caustic to fools. If you've seen that side of him, wear your dunce cap proudly.