Version 4.1 is a major upgrade for the Authoritative Server, delivering improvements and speedups developed and tested over the past 12 months. Many large scale deployments have already migrated to this release because even unreleased, it was a better nameserver than 4.0.x (although the recently released 4.0.5 has fixed a number of relevant issues).
This release features prominent contributions from our community. We’d like to highlight the tireless work of Kees Monshouwer in improving the Authoritative Server based on his huge experience scaling PowerDNS to millions of DNSSEC production zones. Christian Hofstaedtler and Jan-Piet Mens contributed massively as well in many different places. Also a round of thanks to Grégory Oestreicher for revamping and reviving the LDAP backend. Wolfgang Studier, “#MrM0nkey”, Tudor Soroceanu and Benjamin Zengin delivered the DNSSEC management API, as part of their studies at TU Berlin.
We have tried to list everyone else in the full changelog, and we are very grateful for all the work and testing PowerDNS has received from the community!
Improved performance: 4x speedup in some scenarios
More than a year ago, the RIPE NCC benchmarked several nameserver implementations, and found PowerDNS was not a performant root-server. Although PowerDNS is great at serving millions of zones, we’d like to be fast on smaller zones as well. Results of this optimization spree are described here, and also in this longer article “Optimizing optimizing: some insights that led to a 400% speedup of PowerDNS”. Kees Monshouwer’s cache (re)work has been vital to attaining this performance improvement.
Crypto API: DNSSEC fully configurable via RESTful API
Our RESTful HTTP API has gained support for DNSSEC & key management. This API is “richer than most” since it is aware of DNSSEC semantics, and therefore allows you to manipulate zones without having to think about DNSSEC details. The API will do the right thing. This work was contributed by Wolfgang Studier, #MrM0nkey, Tudor Soroceanu and Benjamin Zengin as part of their work over at TU Berlin.
Database related: reconnection and 64 bit id fields
Database servers sometimes disconnect after shorter or longer idle periods. This could confuse both PowerDNS and database client libraries under some quiet conditions. 4.1 contains enhanced reconnection logic that we believe solves all associated problems. In a pleasing development, one PowerDNS user has a database so large they exceeded a 32 bit id counter, which has now been made 64 bit.
Improved documentation
Our Pieter Lexis invested a ton of time improving not only the contents but also the appearance and search of our documentation. Take a look at https://doc.powerdns.com/authoritative/ and know you can easily edit our documentation via GitHub’s built in editor.
Recursor passthrough removal
This will impact many installations, and we realize this may be painful, but it is necessary. Previously, the PowerDNS Authoritative Server contained a facility for sending recursion desired queries to a resolving backend, possibly after first consulting its local cache. This feature (‘recursor=’) was frequently confusing and also delivered inconsistent results, for example when a query ended up referring to a CNAME that was outside of the Authoritative Server’s knowledge. To migrate from a 3.0 or 4.0 era PowerDNS Authoritative Server with a ‘recursor’ statement in the configuration file, please see Migrating from using recursion on the Authoritative Server to using a Recursor.
Miscellaneous
Support was added for TCP Fast Open. Non-local bind is now supported. pdnsutil check-zone will now warn about more errors or unlikely configurations. Our packages now ship with PKCS #11 support (which previously required a recompilation). Improved integration with systemd logging (timestamp removal).
The full changelog can be read here.
The tarball is available on downloads.powerdns.com (signature) and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Artful, Trusty, Xenial and Zesty are available from repo.powerdns.com.
Please send us all feedback and issues you might have via the mailinglist, or in case of a bug, via GitHub.
