The PowerDNS Spring Cleaning

Hi everybody,

In this post we’d like to update you on what has been achieved in the development of the PowerDNS 4.x products: Authoritative, Recursor and dnsdist. First, I am very proud that we managed to do a “spring cleaning”. As mentioned earlier, over time any software project picks up so called “technical debt“. Things that looked good at the time, shortcuts to quickly get to a new feature, whole features that weren’t fully thought through: it all piles up.

It is very wise for any piece of software to periodically take a step back and do a cleanup, but it rarely happens. Some projects do go for the “grand redesign”, but this frequently does not lead to a product that is actually better in production (“Second system effect“).

We’re grateful for our customers and users that allowed us the time for the cleanup, and happy that the PowerDNS community itself too had the discipline to work on these invisible improvements. It is always more fun to add new features than to break down things that were working to make them better!

So what happened under the hood? Quite a lot of things.

C++ 2011

PowerDNS is mostly written in C++, and since 2011 this monumental language has been available in a new revision. C++ 2011 makes life a lot easier on programmers, which in turn means you can deliver more functionality in the same time, or perhaps the same functionality but then with higher quality.

C++ 2011 has merged a lot of functionality from the equally monumental Boost libraries, and we’ve taken the opportunity to move PowerDNS to the ‘native’ versions of these functionalities: range-for instead of BOOST_FOREACH, std::shared_ptr instead of boost::shared_ptr, std::to_string instead of boost::lexical_cast, for example.

Taking this step required revamping our entire build & regression testing infrastructure because the environments on which we test did not support the recent versions of the C++ compilers and libraries we required.


Within PowerDNS hid a sin. DNS names frequently look like “ascii strings”. But they are anything but. DNS names compare case insensitively. Also, there is the issue of the trailing dot. “” and “” are the same from a DNS perspective. Life becomes even more complicated when we realize that DNS names are ‘8-bit clean’. You can put any binary string in DNS and it should work. But how do we encode “some”? As some\ Some\

There is only one worthy answer to these questions: we don’t. DNS is internally not stored as ascii but as a series of labels with specified lengths. So “” is stored as the value 3, followed by www, followed by the value 8, followed by powerdns, followed by 3, by com and finally the zero value. This is the right way to store DNS names.

To achieve this, we wrote the DNSName class which stores DNS values in this way, and also offers ways to parse DNSNames straight from packets, and to output them in “human friendly” form. Over the course of 4.0 development, DNSName got reimplemented a few times as we learned more, finally taking a shape where we could do canonical ordering very fast. This gave us the benefit of cleaning up a lot of ugly reversal code, and allowing all relevant caches to be purged not just name-by-name, but for whole zones in one go.

Finally, we’ve equipped DNSName with many methods that are useful in a DNS context like isPartOf() and chopOff(), removing lots of redundant code from PowerDNS.

Ridding PowerDNS from “DNS Names as ASCII” was a monumental undertaking that would not have been possible without extensive help from the community, specifically Kees Monshouwer and Aki Tuomi.


On a related note, for a long time, the PowerDNS Recursor showed its heritage as a spin-off from PowerDNS Authoritative Server. In the Authoritative Server, backends store DNS details as ASCII. So to encode the AAAA record 2001:888:2000:1d::2, we actually have that string “2001:888:2000:1d::2” of 19 characters in the database. This is not the most efficient thing to do, but for databases it is ok. They are good with strings.

However, INTERNALLY, it makes very little sense to drag these ASCII representations around and convert them into binary addresses and back again for processing. This is the sort of technical debt you build up over 15 years.

With great effort, we’ve been able to purge the PowerDNS Recursor of the DNSResourceRecord struct which carried those ASCII strings, and move everything to the DNSRecord class. We’ve checked, no bits of ASCII are hurt when answering questions in the Recursor anymore!

Netmask & Domain trees

Frequently, PowerDNS products need to check an IP address or domain name against a long list of possible matches. Based on the DNSName, ComboAddress and Netmask classes, Aki Tuomi and we have built generic structures that allow for high speed lookups of domain names & IP addresses against domain suffixes and netmasks, using Patricia Tries. These rapid lookups are now used within all three PowerDNS products, and are also available from Lua.

We can now safely disclose that our previous method for testing an IP address against many netmasks consisted of trying each one in order. Sorry for that.

Malloc Tracer

C++ is a wonderful language, we think, especially if you don’t turn it into a circus. A big problem of C++ however is the astounding amount of memory allocations that happen under the hood. And while memory allocators have gotten better over the years, we discovered we were doing hundreds of mallocs per packet in some circumstances.  We’ve found that Heaptrack was helpful in getting a statistical overview of where our allocations were coming from, but we got very high per-packet precision using a very simple built-in (optional, turned off by default) malloc tracer. Using this, we’ve been able to reduce the allocation traffic by over 60% so far.

As an example, in the common case, the PowerDNS Recursor will now only issue two small mallocs per packet.

Configuration State

We try and succeed in getting a performance boost out of using multiple CPUs. This is not straightforward. No two threads can alter the same memory simultaneously, or bad things would happen. The easy solution against that is to lock the data. It turns out that when you sprinkle locks all over your code, any performance boost is gone. Performance might in fact go down with more threads.

A common case however is where a piece of memory rarely if ever changes and we can spare the memory to give each thread its own copy to read from. Only if something changed in the ‘master’ should each thread get a new copy. This idea is roughly what is known as Read Copy Update within system programming, and is for example also used by the great Knot DNS server. We created a set of classes called ‘State Holders‘ to bring this technology to PowerDNS as well.

Package Builder, Repositories

Although we loved Jenkins and we are mostly happy with Travis, we have gotten a lot of power from our ‘buildbot’ building engines. We now build PowerDNS for more and more platforms automatically, and push out those packages to our repositories on These repositories allow you to install the latest and greatest builds of PowerDNS using apt or yum, and get native packages. This makes testing 4.0 really easy.

So what did we do with all those improvements?

Once this better new infrastructure was in place, we’ve implemented many new things:

  • RPZ aka Response Policy Zone, as outlined here
  • IXFR slaving in the PowerDNS Recursor for RPZ
  • DNSSEC processing in Recursor (authoritative has had this for years)
  • DNSSEC validation
  • EDNS Client Subnet support in PowerDNS Recursor (authoritative has had this for years)
  • GEOIP backend supporting custom netmasks, “fields” in answers
  • Newly revived ODBC backend for talking to Microsoft SQL Server & Azure
  • Lua asynchronous queries for per-IP/per-domain status
  • Caches that can now be wiped per whole zone instead of per name
  • An astounding amount of dnsdist features (check out the movie & the presentation!)
  • And much more

We’ll outline what is in 4.x more completely in an upcoming post, including details on when and how it will be released. For now, it may be good to know you can test these new features via the package builder and repo service as outlined above.

Good luck!

PowerDNS Security Advisory 2015-03

  • CVE: CVE-2015-5311
  • Date: November 9th 2015
  • Credit: Christian Hofstaedtler of Deduktiva GmbH
  • Affects: PowerDNS Authoritative Server 3.4.4 through 3.4.6
  • Not affected: PowerDNS Authoritative Server 3.3.x and 3.4.7 and up
  • Severity: High
  • Impact: Degraded service or Denial of service
  • Exploit: This problem can be triggered by sending specially crafted query packets
  • Risk of system compromise: No
  • Solution: Upgrade to a non-affected version
  • Workaround: run the process inside the guardian or inside a supervisor

A bug was found using afl-fuzz in our packet parsing code. This bug, when exploited, causes an assertion error and consequent termination of the the pdns_server process, causing a Denial of Service.

When the PowerDNS Authoritative Server is run inside the guardian (--guardian), or inside a supervisor like supervisord or systemd, it will be automatically restarted, limiting the impact to a somewhat degraded service.

PowerDNS Authoritative Server 3.4.4 – 3.4.6 are affected. No other versions are affected. The PowerDNS Recursor is not affected.

PowerDNS Authoritative Server 3.4.7 contains a fix to this issue. A minimal patch is available here.

This issue is unrelated to the issues in our previous two Security Announcements (2015-01 and 2015-02).

We’d like to thank Christian Hofstaedtler of Deduktiva GmbH for finding and reporting this issue.

PowerDNS Authoritative Server 3.4.7 released

We’re pleased announce the release of the PowerDNS Authoritative Server version 3.4.7. This release fixes several bugs and has a bunch of improvements onboard.

The biggest fixes are improved negative caching and preventing a crash that could happen during the AXFR of a zone with many MX records of different priorities.

Tarballs and packages are available on:
* Soon:
(RHEL/CentOS, with the usual huge thanks to Kees Monshouwer).

The changelog can be found on our documentation website.

PowerDNS Security Advisory 2015-02

A bug was recently found in our DNS packet parsing/generation code, which, when exploited, can cause individual threads (disabling service) or whole processes (allowing a supervisor to restart them) to crash with just one or a few query packets.

  • CVE: CVE-2015-5230
  • Date: 2nd of September 2015
  • Credit: Pyry Hakulinen and Ashish Shakla at Automattic
  • Affects: PowerDNS Authoritative Server 3.4.0 through 3.4.5
  • Not affected: PowerDNS Authoritative Server 3.4.6
  • Severity: High
  • Impact: Degraded service or Denial of service
  • Exploit: This problem can be triggered by sending specially crafted query packets
  • Risk of system compromise: No
  • Solution: Upgrade to a non-affected version
  • Workaround: Run the Authoritative Server inside a supervisor when `distributor-threads` is set to `1` to prevent Denial of Service. No workaround for the degraded service exists

PowerDNS Authoritative Server 3.4.0-3.4.5 are affected. No other versions are affected. The PowerDNS Recursor is not affected.

PowerDNS Authoritative Server 3.4.6 contains a fix to this issue. A minimal patch is available.

This issue is entirely unrelated to Security Advisory 2015-01/CVE-2015-1868.

We’d like to thank Pyry Hakulinen and Ashish Shakla at Automattic for finding and subsequently reporting this bug.

PowerDNS Authoritative Server 3.4.6 released

We’re pleased to announce the release of the PowerDNS Authoritative Server version 3.4.6. This release fixes some bugs and has several improvements.

Tarballs and packages are available on:
* Soon: (RHEL/CentOS, with the usual huge thanks to Kees Monshouwer).

The changelog can be found in the documentation.

Providing first tier support – Why writing and owning your software is critical

The recently exposed denial-of-service vulnerability in a popular DNS server implementation really highlights the benefits of software providers writing and owning the software that they deliver to internet service providers. The flaw in the software allowed hackers to potentially crash DNS servers, effectively allowing them to take huge sections of the internet offline. As we have highlighted previously, DNS is an absolutely critical part of the internet and it’s tremendously important to ensure its smooth running.

As a customer, the best way to secure your DNS servers is to make sure that your software provider is in full control of the product that they deliver. No software, including PowerDNS, is free from occasional security issues. However, companies that haven’t written the core software they deliver and who simply repackage other providers’ products with additional services, are on the back foot when it comes to security issues.

The problem is that when a security flaw emerges, these companies are unable to fix it themselves. Instead they have to wait for the original providers to issue a suitable and effective patch. With security issues, the speed with which you can fix vulnerabilities is crucial. Often these companies are not on friendly terms with their ‘upstream’ (which may view them as competition!) or they have no contractual/financial agreement with them to fix these bugs and so customers are left vulnerable for a prolonged period of time.

So by definition, if you rely on a DNS vendor or appliance that repackages a third party DNS server, you are getting second-tier, second-hand support – at best.

Security breaches are one of the biggest sources of reputational damage for organisations. Customers will be unimpressed by the loss of their data or the inability to access your services but moreover, it reflects badly on the management decisions of a business that fails to take proper measures to secure their service.

Here at PowerDNS we understand the benefit of authoring, supporting and distributing our own product: we can always act quickly to ensure our software stays free from performance impacting bugs and patched against the latest security vulnerabilities.

Make sure you ask your DNS vendor if they can do the same!

PowerDNS at Open-Xchange Summit in Berlin, 8-9 October 2015

Hi everybody!

Since we are now happily part of Open-Xchange, together with our friends at Dovecot IMAPd, we will also be present at the Open-Xchange summit in Berlin, October 8-9 this year. This is a free event, and you are invited!

Besides marketing presentations like ‘The Power of DNS to Engage More Customers’, we’ll also be having a serious technical presentation on Friday about PowerDNS. Feel free to invite your manager to the first presentation and join us for the second one ;-)

Also important, the summit includes a ‘Bier-Xchange’, which also serves other things than beer, plus a party at the end. More about the event can be read on

All PowerDNS users are cordially invited to join the summit, which is free of charge: or using the ‘Register Now’ button at the bottom of page.

If you register, please drop us an email (powerdns.ideas @ so we can invite you to the PowerDNS-specific gathering during the drinks and party.

Also: feel free to invite your manager to show that PowerDNS is a real company and more than some free software from the internet.


        Bert & Team