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
9 thoughts on “DJBDNS, DNS exploits, Bernstein, Schneier, and security by design”
there is no ethernet or 802.11 anything onboard.
DVI-D through an HDMI plug
1USB mini-A port
1 DC barrel-type plug
1 Stereo audio output
1 stereo audio input
1 serial port (needs a header/plug adapter)
1 “expansion” port with several general I/O pins but no declared/announced daughterboards yet
Comments are closed.