PowerDNS Recursor 4.1

This is a major release containing significant speedups (both in throughput and latency), enhanced capabilities and a highly conformant and robust DNSSEC validation implementation that is ready for heavy production use. In addition, our EDNS Client Subnet implementation now scales effortlessly to networks needing very fine grained scopes (as used by some ‘country sized’ service providers).

4.1 reflects over a year of improvements, cleanups and enhancements – both visible and invisible. Some of the smaller improvements have been backported to 4.0 releases, but most are new.

We are particularly grateful for the help of XS4ALL and Packet Clearing House (Quad9) for their help maturing this release to production readiness. In addition, various very large RFP requirements documents have also been stimulating. Finally, we’d like to thank Akamai for quickly resolving a single bit issue in their DNS responses which led the stricter 4.1-era resolving logic to not cache certain data which caused user noticeable slowdowns.

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!

4.1 has seen an astounding amount of pre-release testing and even full production use, and from this data we know this release is rock solid and represents a significant speedup not only in benchmarks but also in real life.

 

 

DNSSEC

DNSSEC is a complicated protocol, yet operators (rightfully) expect rapid performance that resolves even rare or outlandish signing scenarios, all while not impacting non-DNSSEC enabled domain resolution speed. While Recursor 4.0.7 is suitable for DNSSEC validation, operators have noted that 4.1 delivers superior performance, with no observable errors that are not caused by configuration mistakes by domain owners. In addition, 4.1 works around more issues triggered by non-conforming nameservers and load balancers. Anyone doing DNSSEC validation with 4.0.7 is urged to upgrade.

As part of this DNSSEC work, the central DNS resolving logic of PowerDNS was fully cleaned up and made unit-testable. Large volumes of such unit tests have been added, next to similar large amounts of new regression tests.

After extensive measurements, we are now sure that enabling DNSSEC validation has a negligible impact on user experienced performance.

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/recursor/ and know you can easily edit our documentation via GitHub’s built in editor.

RPZ

RPZ is a standard for retrieving policy through zonefiles, possibly transferred incrementally (IXFR). PowerDNS 4.0 brought support for RPZ, but it was not quite complete and had performance deficiencies on very large RPZ datasets. Some of the 4.1 improvements in this area have already been backported to the 4.0 series. Notable changes in 4.1 are the addition of support for wildcard records, improvements in RPZ reloading & update processing and new debugging facilities (logging of changes and serialization of current RPZ state).

EDNS Client Subnet

EDNS Client Subnet is utilized to transmit (part of) the client IP address to authoritative servers, in the hope that they can provide more relevant answers. ECS is used by large Content Distribution Networks, and can be required to offer good streaming performance for clients within very large operator networks. The 4.0 ECS implementation is running in production in a number of such places, but the 4.1 implementation has been improved to use less CPU cycles and deal better with smaller subnets. In addition, metrics have been added to monitor ECS query loads.

Miscellaneous

SNMP support was added. The built-in authoritative server (which is more important since Authoritative Server 4.1 removed the ‘recursor=’ bypass) gained the ability to serve wildcard CNAMEs. The Lua engine gained a lot of access to relevant data from more places (EDNS Client Subnet details, MAC address, TCP or UDP). CPU affinity can now be specified. Support was added for TCP Fast Open.

There are new performance metrics which track the amount of CPU time used per query, which is useful to study performance isolated from network latencies.