In this post, we’d like to share our current plans for .. PowerDNS 4.x! We shared this first with the PowerDNS-development community, and after we gathered feedback, we’re now announcing it more broadly.
The tl;dr: For the next few months we will be spring cleaning git master, and stable code and releases can be found in the auth-3.4 and rec-3.7 branches. We’ll also be moving to C++ 2011. Please read on for the whole story.
First some background. PowerDNS is a 15 year old software project, and over these 1.5 decades, we have built up some ‘technical debt’, and it is time for a spring cleaning in our code.
Meanwhile, we are broadening what our code does, to include for example smart, DNS-native, load balancing and further denial of service mitigation. And of course, the major work of bringing carrier-grade DNSSEC to the recursor.
Finally, we’ve fallen in love with C++ 2011, and we would like to start taking advantage of this now 4 year old revision of C++.
All this means some important changes. For one, where it used to be the case that our git ‘master’ was usually fit to run in production (and people actually did this), for the coming few months please consider our master branch a ‘heavy development zone’. While we’ll try to keep things working, it might break for hours or even days at a time. Even though there will be somewhat of a wild-west aspect to development, major changes will be implemented as pull requests from separate branches that can be studied by the community.
Meanwhile, PowerDNS 3.x development and maintenance will continue on separate release branches. The latest 3.x releases will remain actively supported until 4.x is more powerful, more stable, and can be compiled on Debian Stable (more about this later). Active support means more than passive maintenance, if there are pressing things that need to happen, they will happen. But the focus for new things will shift to 4.x.
(as an example of what active support means, we are currently gathering the patches for auth-3.4.3, see here)
Things we will be addressing during our spring cleaning include:
- We treat DNS names as ASCII strings, which we escape and unescape repeatedly. DNS names are not ascii strings, and we keep finding issues related to us treating them like strings.
- The PowerDNS Authoritative Server distributes queries to multiple backends inefficiently
- The PowerDNS Recursor cache is both slower and less memory efficient than it could be
- DNSSEC in the PowerDNS Recursor
- Move our own atomic, locking and semaphore infrastructure to C++ 2011 native
- The Lua APIs use an ascii based interface for domain names and IP addresses, and this could be faster
- One thing we are probably not going to do is change the database format, by the way.
The somewhat bad news about the spring cleaning is that we’ll come out of it as a C++ 2011 project, which means that to compile PowerDNS, you’ll need GCC 4.8 (released in March 2013). Gcc 4.8 is not currently the default in Debian stable or RHEL/CentOS 6, but it is available. (Update May 2015: Debian 8.0 is now stable and 4.9 is default.)
It is the default in RHEL7 and in what will become the next Debian stable (May 2015: now the current Debian stable). GCC 4.8 also ships in Ubuntu 14.04. We will also be targeting clang 3.5. We have chosen C++ 2011 for a variety of reasons, many of which are described in an earlier blogpost.
NOTE: PowerDNS 4.x products WILL run on older distribution releases of course! However, on older distros, compiling with the system default compiler may not work.
To clarify, the 4.x branch will not fundamentally alter PowerDNS. This should not be compared to BIND 9 to BIND 10, for example (or even 8 to 9). Fundamentally we think the PowerDNS design is sound, it just needs a decent spring cleaning. This will come in especially handy when deploying our DNSSEC validation.
So how long will it take until 4.x is production ready? We’ll let you know once we get there, but we are hoping to finish the cleanup in several months, after which we expect further work to iron out remaining issues. In any case, 3.x will remain supported until gcc 4.8 is widely available on currently shipping distributions.
Thanks, and please again let us know your thoughts about this proposed plan. Although this is what we intend to do, we can be change our mind if there are good reasons to do so!
