A Brief History of opendnscache

With the recent discovery by CloudFlare of the ability to exploit CVE-2015-7547 (the glibc vulnerability) via dnscache, we thought it was a good time to talk about the history of our DNS resolver: opendnscache.
Nine years ago, at the birth of OpenDNS, we started by forking dnscache from the djbdns suite by Daniel J. Bernstein (aka djb). At that time, and to this day — in our opinion — djbdns has long been one of the most secure and reliable DNS suites out there. In 2004 it was the second-most popular DNS server, and is still in use by many companies, including Facebook and OpenDNS, for authoritative DNS service. The code base is approachable and runs on most anything with a C compiler (a joke from our team: if you want to run a DNS server on your toaster or coffee pot, djbdns is the way to go).
That said, nine years is a long time, and in that time we have made thousands of modifications to dnscache, averaging a commit a day to master. These commits introduced many features not found in dnscache, such as CacheCheck, category filtering, IPv6 support, and even modifications to how dnscache handles TCP connections. This doesn’t count the number of RFC’s and drafts, like the Global Internet Speedup effort, for which we have added support. We have worked hard, adapting to changing DNS and Internet landscapes.
These days it’s hard to look at opendnscache and see djb’s dnscache. Much like Dorothy in Oz, someone expecting to see dnscache when looking at our code base will have the “We’re not in Kansas anymore” feeling. The ideas are still there, and we take to heart the way that djb wrote his software — security is the most important aspect of what we do. There are still places where djb shines through, but opendnscache is uniquely ours.
We are proud to be based on dnscache. As stated in our comment on the CloudFlare blog, the specific functionality that can lead to exploiting the glibc vulnerability had already been modified. We simply don’t handle TCP the same way the dnscache does. We did our own testing and spent time with Jaime Cochran from the CloudFlare team, investigating new and different potential attack scenarios to make sure we were covered. We are thankful to the CloudFlare team for their willingness to work with us to ensure a great Internet experience for all of our users!
We’ll continue to monitor the situation surrounding the glibc vulnerability and update you on any new discoveries we find.