An eulogy for DNScurve

OpenDNS is probably the strongest DNScurve proponent out there. So, when they start making moves to look for a DNSSEC engineer (as an aside, the position is no longer open; they finally convinced one of their own engineers to implement DNSSEC, probably while holding their nose), you know that DNSSEC has won.

DNScurve, with all due respect, never had a chance. It didn’t have a chance when I last talked about it a year ago. It’s downright moribund today.

Sure, on a technical level it has some really cool technology—in particular, I really like the (2^(255)) - 19 curve it uses for cryptography; a “stock” DNS packet can only fit 512 bytes of information (we can make the packet about 1280 bytes in size if we use EDNS), so a public key cryptographic primitive that offers strong security without needing to push around 3072-bit RSA signatures (the approximate size needed with RSA to get the same level of security as DJB’s “25519” curve) is very appealing.

But, unfortunately, standards are not judged solely on their technical merits. They are also judged on how well the people who work on the standards get along and are willing to make compromises.

DJB, as far as I can tell, was never willing to work with other people on DNScurve. He wanted it to be an end-to-end DJB-exclusive invention: His own “25519” curve for public key cryptography, his own Salsa20 stream cipher for encryption (a nice enough cipher, but it uses 32-bit words everywhere and doesn’t have a mode using 64-bit words), and his own “Poly1305”.

To top it off, DJB didn’t even implement a reference implementation of DNScurve. He wasn’t even willing to walk far enough outside of his ivory tower to make an implementation, make said implementation public, and allow people to see how it ran in the real world.

And, indeed, no one else implemented DNScurve either. The most notable implementation of DNScurve was GbDNS, but that was replaced by something called “QRP” a year ago. OpenDNS was the only other place that implemented DNScurve, but they’re now looking to implement DNSSEC.

DNScurve also suffered from being a solution looking for a problem. The only real issue DNScurve solved was the problem of being able to sniff DNS traffic and spoofing replies based on the traffic seen. It didn’t solve the problem of an upstream DNS server sending spoofed traffic. Quite bluntly, this is a problem OpenDNS’ current business model doesn’t want to see solved (they make their money from NX redirects and from having google.com point to their own web page), so it’s no surprise they advocated DNScurve for as long as they did.

DNSSEC, on the other hand, is already seeing wide adoption. BIND has always supported it, of course, and Unbound supports it. GbDNS also now has gone from supporting DNScurve to support DNSSEC. PowerDNS is getting DNSSEC support.

If things in my life ever change and I got a six-month paid sabbatical, I would also implement DNSSEC and make it part of Deadwood; I regret the fact I don’t have time to make a compact pure-C implementation of DNSSEC.

If you want to make a standard real, work with standards committees. I know DJB can do this; his excellent Salsa20 cipher is part of the eSTREAM portfolio (but, again, I’d like to see a 64-bit Salsa20, or, even better, a 64-bit version of Cha-Cha I would call Merengue, or even Merequetengue). It’s a shame he didn’t do the same with DNScurve. Hopefully, the 25519 curve can become a public key algorithm used in future revisions to the DNSSEC standard.

- Sam

There is no such thing as a perfectly secure program

Back in 2007, I posted this criticism of DjbDNS on their mailing list. As you can imagine, the people on the mailing list were not happy.

What has changed with DjbDNS since I wrote this criticism:

• DjbDNS has finally been made open-source
• Three security holes have been discovered in DjbDNS
• The DjbDNS tarball on the official download page is still the outdated 1.05 version of DjbDNS

I can not help but observe that, ever since those three security holes have been discovered in DjbDNS, DJB advocates have been a lot more quiet about how ultra-secure DjbDNS is.

In comparison, MaraDNS has had 12 security problems in its near-decade of existence. OK, so I have four security problems for every security problem DjbDNS has. Then again, of those 12 holes:

• Four were only in unstable development releases of MaraDNS
• One was caused by broken behavior in the Linux kernel and not by MaraDNS
• Two were patches against theoretical problems in AES that do not have any real-world exploits
• The remaining five problems only allowed an attacker to perform a denial of service against MaraDNS; the one I patched yesterday only works in the unusual case of an attacker being able to give MaraDNS a csv2 zone file

To make this an apples-to-apples comparison, there have only been five practically exploitable security problems in stable releases of MaraDNS caused by my own coding errors. None of them have been worse than denial of service.

I should also point out the hole I patched yesterday only exists because I decided it was good to have a more attractive zone file format for MaraDNS.

The idea that there exists an uber-genius programmer who can magically make code without any security problems that never needs to be updated was a myth DJB advocates liked to present in the first decade of the 2000s. This is nothing more than a myth, shattered by the three security holes people have discovered in DJBdns (not to mention the backscatter spam problem in Qmail, which is a security problem).

Security is a process. Programmers, no matter how experienced or skilled, make errors. To criticize a programmer for making a mistake is unreasonable and unrealistic. The best we can do is make a program with a coding style that minimizes security problems; considering that MaraDNS has had only four (maybe five) practically exploitable security problems in stable releases is a very good record.

If you want security, you want to use a program that the programmer stands behind and continues to support. Which is what I have been doing with MaraDNS for nearly a decade and which I have no plans to stop doing.

Why I will not implement DNS curve

I will not implement DNS curve.

Sorry, guys. It's just, over the years, I have had too much bad blood with DJB and with DJB advocates. Back in 2001, I supported DJB on his "lets flame all of the BIND developers" crusade.

Despite this, he had this childish response to my 2002 Bugtraq announcement of MaraDNS. In addition, I have had a number of unpleasant experiences with DjbDNS zealots over the years.

I understand that DJB has partially addressed the issues I brought up back in 2007 by making DjbDNS public domain instead of its old "useless unless you like patching like crazy" license it used to have.

I find DJB advocates loud-mouthed and unpleasant. DJB's behavior in the early 2000s with BIND developers on mailing lists like Namedroppers was unacceptable, and the fact is that DJB has never apologized for his behavior there.

If DJB wants to have a DNS standard that other DNS implementors will want to implement, he needs to have more respect for the DNS standards process and for other people who have implemented DNS, including the BIND developers.

Deadwood minor update; djb software rant

I have made a minor update to Deadwood; I have updated the DwMain man page (manual page; "man page" is *NIX-ese for "manual") and added a Makefile to automatically convert the man pages from MaraDNS' internal documentation format to text files and *NIX's standard documentation format.

It can be downloaded at maradns.org/deadwood.

---

Using DJB software is harmful.

If you're looking to use a DNS server, use anything besides DjbDNS. DjbDNS sucks, frankly.

The first problem is that it hasn't been able to compile on Linux for years. Yeah, there's a fix for it, but what use is it to download a program where you have to look online for help just to compile the program.

The second is that the program has a nasty remote denial of service security bug. It is possible to remotely restart DjbDNS' cache unless you apply the security fix.

The third problem is the userbase. DjbDNS advocates do not acknowledge the remote denial of service problem, and go out of their way to cover it up and pretend the problem does not exist. Instead, they will continue to repeat the same lies about how DjbDNS is "100% secure" and "has never had a security problem".

Indeed, I got in a nasty edit war on the Wikipedia when I unsuccessfully tried to put accurate information about DjbDNS' security problems there; the Wiki's acceptance of these kinds of lies getting published there disgusted me so much I have left the Wikipedia. The Wikipedia entry still has the same old BS about about DjbDNS is "highly secure".

DjbDNS has a number of other problems, which I have detailed in older blog entires (just look for older entries tagged "DjbDNS"), which its advocates respond to by either blaming the user for DjbDNS' problem, or by pretending the problem doesn't exist.

Don't waste your time with a program with security problems (that DJB and DJB advocates try and cover up instead of acknowledging and patching) and that won't even compile unpatched. There are a lot of other currently maintained DNS offerings, such as BIND, such as Power DNS, such as Unbound, such as dnsmasq, and, yeah, such as my own MaraDNS (and Deadwood).

On a related topic, Qmail has a nasty security problem called "Backscatter spam". Netqmail, which is the maintained branch of Qmail, doesn't fix this problem. Yes, there are fixes, but they require people to go out of their way to find and install patches. Which is something people shouldn't have to do in 2009.

Just use sendmail, postfix, exim, courier MTA, or another currently maintained MTA that doesn't pretend issues like backscatter spam aren't security problems.

Some interesting links: Rick Moen on DJBware How one person handled legitimate criticism of DJB's software

Chortle hotfix; kerning; More on DjbDNS

---

OK, I thought I was done with the Chortle font for now. I was wrong. It seems that a fontforge bug ate all of the non Latin1 characters in the Chortle typeface I released yesterday. Hence, I have a hotfix to restore these characters. In addition, I have improved the metrics with the italic letters a little, and have updated the font version number in that field. As always, it's at http://www.samiam.org/Chortle. Now, hopefully, I have a version of Chortle that doesn't need to be updated for a while.

---

It would seem that Microsoft Word 2000 doesn't use the kerning tables included with a font. Hence, I have to make the metrics of the letters as good as possible without using kerning. There does seem to be a way of changing the kerning in Microsoft Word, however. I'll have to experiement with this when making pages with really large text, such as title pages.

---

A DjbDNS user very politely asked me to detail the bugs that I pointed out in yesterday's blog. I will detail the first two bugs here and the other three in later blog entries.

• Djbdns has the 'akamai djbdns' problem where the DjbDNS resolver can not resolve some domains.
  
  In January of 2006, there were known issues with resolving www.edmunds.com and www.infiniti.com with DjbDNS. They may or may not work today; djbdns certainly hasn't fixed the issue that caused the problem.
  
  reference
  
  
• DjbDNS is broken when someone has to change their hosting provider, and their current hosting provider refuses to help.
  
  In more detail, djbdns does not periodically check the upstream DNS servers for a given domain to make sure that the domain in question is still using the same name servers. This is a problem when someone changes hosting providers, and the old hosting providers keeps the outdated DNS records in their DNS server. DjbDNS will continue pointing to the old provider until either the old ISP deleted their records, or DjbDNS is restarted.
  
  reference

I have had two very unpleasant experiences with DjbDNS advocates over the years, and one unpleasant experience with DJB himself. In more detail

• The first email I got when I first announced MaraDNS in 2001 was a flame from a DjbDNS advocate, telling me it was not worth my time to write MaraDNS because DjbDNS is a good DNS server.
• I once got in an edit war in Wikipedia over whether DjbDNS is open source. This person wanted to redefine the term "open source" to make DjbDNS open source, even though the Open Source Definition is unambiguous and doesn't cover licenses that forbid redistribution of modified programs.
  
• DJB flamed the Bugtraq moderator for approving a posting describing MaraDNS on that list

So, yes, I have had some rather unpleasant experiences with DjbDNS advocates and even DJB, even though I supported DJB in some of his flame wars against the BIND developers in 2001.

Note that I'm not counting the flames I got for posting my DjbDNS rant there; I was asking for flames and I did get some productive discussion, which I feel is worth getting flamed over.

- Sam

MaraDNS 1.3.04 released; Chortle update

---

I have just released MaraDNS 1.3.04. This has a number of bug fixes and improvments in the development branch of MaraDNS compared to the last last release. From the changelog:

• Remco pointed out that MaraDNS is not RFC4074 section 4.2 compliant. Fixed.
  
• Update of recursive server to make it more robust against certain DOS attacks.
  
• The port range that the recursive resolver binds to can now be changed in the mararc file.
  
• FAQ and SQA updates
  

---

DjbDNS is harmful

DjbDNS is harmful to use because the code has not been updated for over five years. This, in spite of the fact DjbDNS has the following bugs:

• There are problems resolving some domains with DjbDNS' resolver. This is the 'akamai djbdns' problem.
  
• DjbDNS does not correctly periodically check upstream DNS servers to make sure a given domain has not moved.
  
• The list of root servers included with DjbDNS is out of date.
  
• DjbDNS can not compile in Linux without using a special incantation.
  
• There is a denial of service problem where a remote attacker can clear DjbDNS' recursive cache by sending a single "packet of death" to a dnscache server.
  

It is not feasable for a third party to fix any of these bugs because of DjbDNS' restrictive non-open-source license, and DJB appears to have no intention of fixing the bugs in his program.

In fact, MaraDNS has a better security record than DjbDNS. MaraDNS also has had denial of service problems. The difference between MaraDNS and DjbDNS is that the bugs in MaraDNS are fixed.

More information about DjbDNS' problems can be found in the MaraDNS advocacy document.

There is also a problem with the DjbDNS user base, who have all the fanatism of Jihadists.

---

To be fair, here are some criticisms about MaraDNS that I added to the MaraDNS Wikipedia article:

MaraDNS has limited support for being a slave DNS server. While MaraDNS includes a tool that can receive zone files, this process needs to be automated via an external program, such as crontab, and MaraDNS needs to be restarted to load the zone in question.

While MaraDNS can resolve almost any site that other DNS servers can resolve, it does not resolve all names the same way other DNS servers do. CNAME and ANY records, in particular, are resolved differently.

MaraDNS spawns a thread for each recursive DNS request that is not already cached.

---

I have updated the Chortle font, and have released version 0.21 of this font today. I'm hitting the point where I'm looking at this font too much and starting to second-guess myself. So, I'm taking a break from my embedded Linux project and will be working on MaraDNS (and my day job as an English teacher) for the time being.