[Pdns-users] PowerDNS development plans: 4.x DNSSEC, C++ 2011!

Mon Feb 23 16:52:14 UTC 2015

This is exciting news, Bert!

Some follow-up questions/comments:

- Will 3.x development end on the 3.4 track, or is there still a plan for
3.5? If 3.4 is it, what's the plan for features (such as ALIAS) that were
scheduled for 3.5? Are they delayed to 4.0 (if so, sad face)?

- Currently, PowerDNS Authoritative and PowerDNS Recursor share a
repository (https://github.com/PowerDNS/pdns). This can make things
especially confusing, since there are recursor development branches,
authoritative development branches, recursor version branches,
authoritative version branches, recursor release tags, and authoritative
release tags all within the same repository. During all this work being
done on master, can the opportunity be taken to move shared code into X
repository and then have a repo for Recursor and a separate repo for
Authoritative? It seems like it would be a much cleaner arrangement.

Good luck in this new challenge!

Nick

On Mon, Feb 23, 2015 at 8:58 AM, bert hubert <bert.hubert at powerdns.com>
wrote:

> 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’
> (http://en.wikipedia.org/wiki/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, we are currently gathering the patches for auth-3.4.3, see
> https://twitter.com/powerdns/status/569872447757025280 )
>
> 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.
>
> It is the default in RHEL7 and in what will become the next Debian stable.
> It also ships in Ubuntu 14.  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
> (
> http://bert-hubert.blogspot.nl/2015/01/on-c2011-quality-of-implementation.html
> ).
>
> 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!
>
>         PowerDNS
>
>
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20150223/44eb182f/attachment-0001.html>