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) {
byte_copy(name[name_num],dlen,d);
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)