Sam Trenholme's webpage
Support this website

djbdns 1.05: False security


January 3 2011

I would like to start off this blog posting by pointing out that djbdns' dnscache is an excellent tiny DNS caching solution for *NIX systems. It has a very small footprint and was the pioneer in innovative techniques to improve DNS security (notably source port randomization).

One issue is that it hasn't been maintained in a decade; one has to use an unofficial fork of the code which updates it for the 21st century (One good fork is Zinq N-DjbDNS).

This is not the most serious issue with djbdns. The main issue with djbdns isn't an issue with djbdns per se but an issue with some of its userbase. A number of users are still using an unpatched copy of djbdns-1.05, released a decade ago because they mistakingly believe the software is perfectly secure.

This myth is still told on online discussion forums; for example, just last year two posters on Slashdot (which has not been a very good place to post anything for years, but that is another rant for another day) spouted that djbdns is (nearly) completely bug-free without anyone posting a follow-up correcting their mistake.

This is very dangerous. People spouting on public forums about how djbdns is magically 100% perfectly secure and never need patching need to -- how do I say this -- pull their head out a place where the sun doesn't shine.

A stock install of djbdns-1.05 has security problems. Three, to be exact. Two of them can be resolved with simple, small patches:

*** dnscache.c.orig     Sun Feb 11 13:11:45 2001
--- dnscache.c  Tue Mar 18 17:22:03 2003
*** 1,4 ****
--- 1,5 ----
  #include <unistd.h>
+ #include <signal.h>
  #include "env.h"
  #include "exit.h"
  #include "scan.h"
*** 391,396 ****
--- 392,398 ----
    char *x;
    unsigned long cachesize;
+   signal(SIGPIPE, SIG_IGN);
    x = env_get("IP");
    if (!x)
      strerr_die2x(111,FATAL,"$IP not set");
Patch #2:
--- response.c.orig     2009-02-24 21:04:06.000000000 -0800
+++ response.c  2009-02-24 21:04:25.000000000 -0800
@@ -34,7 +34,7 @@
         uint16_pack_big(buf,49152 + name_ptr[i]);
         return response_addbytes(buf,2);
-    if (dlen <= 128)
+    if ((dlen <= 128) && (response_len < 16384))
       if (name_num < NAMES) {
        name_ptr[name_num] = response_len;
The third one, however, requires some fundamental design changes to properly address; this webpage has more details.

Personally, my solution to this cache spoofing issue with djbdns is to use deadwood (MaraDNS 2.0's recursive resolver) instead; but I am a little biased.

djbdns is an excellent program. I'm not denying that. But it does have security holes and people need to stop claiming otherwise.

Update (January 4, 2011):

To give credit where credit is due, the first patch above comes from Mark Delany in this mailing list posting; the second patch above comes from DJB himself in this posting.

I also forgot about the large packet compression pointer bug, which also has security consequences. More information is in this mailing list posting.

Updated in 2014 to point to N-DjbDNS instead of the now-dead Zinq.

See also: Finally, a CVE-2012-1911 patch and Yet another DjbDNS security hole

To post a comment about this entry, send me an email and I may or may not post your comment (with or without editing; see the blog index for details)