Category: Uncategorized

Important Changes in PowerDNS Authoritative Server 4.2.0

Hello PowerDNS user,

as the year draws to an end, we are preparing for the release of a new version of the Authoritative Server (and the Recursor – stay tuned for more news in that area). This release (4.2.0) will see some changes that may affect your usage of PowerDNS. Please read, or at least skim, this article to make sure you will not be surprised when you upgrade.

If, after reading this, you have questions, please reach out to us via our mailing list or IRC channel. If you feel you’ve found a bug or other problem, we’d love a ticket on our GitHub repository.


Since forever, PowerDNS has supported a badly-documented feature called ‘autoserial’ which allowed a database backend to generate a serial on demand, when the serial inside the SOA record was set to zero. This feature was never documented properly and most deployments we have seen of it turned out to be broken in key areas. Supporting this feature also means we have bugs around the handling of the valid serial number zero in zones that do not want autoserial.

Over the last few releases, PowerDNS has gained robust HTTP REST support, and a mature implementation of RFC 2136 DNS Update. For the command line user, pdnsutil increase-serial is a simple way to increase serials on zones after updates.

Because autoserial was hard to use, rarely did what people wanted, and because its presence prevents us from fixing other bugs, we have decided to retire the feature now that several alternatives are available.

Builder/packaging changes

Between 4.1 and 4.2, we have replaced our old package building infrastructure with a new one, based on pdns-builder. While the idea is that most users will not notice this transition, there may be unintended changes.

Our Debian/Ubuntu packages no longer use ucf.

Our ./configure script inconsistently used --enable and --with. This has been fixed; downstream packagers may need to adjust their packaging.


Around the development of the LUA record type (more on that in a separate post), some of the Lua handling in the Authoritative Server has been refactored. If you have any existing Lua scripts in your Auth server, please make sure they still work correctly after upgrading to 4.2.


Following RFC6986 which deprecates the usage of GOST R 34.11-2012 generally, and anticipating the publication of Algorithm Implementation Requirements and Usage Guidance for DNSSEC which intends to move DNSSEC ECC-GOST support in signers to the ‘MUST NOT’ category, support for both ECC-GOST signing and GOST DS digests has been removed. In the unlikely situation that you have domains signed with ECC-GOST, you will need to roll their algorithms before upgrading to PowerDNS Authoritative Server 4.2.


PowerDNS Recursor 4.1.8 Released

We’ve released PowerDNS Recursor 4.1.8.

This release fixes Security Advisory 2018-09 that we recently discovered, affecting PowerDNS Recursor from 4.1.0 up to and including 4.1.7.  PowerDNS Recursor 4.0.x and below are not affected.

The issue is that a remote attacker can trigger an out-of-bounds memory read via a crafted query, while computing the hash of the query for a packet cache lookup, possibly leading to a crash.

When the PowerDNS Recursor is run inside a supervisor like supervisord or systemd, a crash will lead to an automatic restart, limiting the impact to a somewhat degraded service.

A minimal patch is available at

The changelog:

  • #7221: Crafted query can cause a denial of service (CVE-2018-16855)

The tarball (signature) is available at and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

PowerDNS Recursor 4.1.7 Released

Today we have released the PowerDNS Recursor 4.1.7. It is an update to relax EDNS compliance requirements from upstream authoritative servers.

Recursor version 4.1.5 (and, by extension, 4.1.6), contains a fix for Security Advisory 2018-07. One part of that fix is a stricter fallback to non-EDNS queries when EDNS queries fail. It turns out that there are several authoritative servers on the Internet that have such bad EDNS handling, that the domains hosted on them stop resolving with 4.1.5. The 4.1.7 release has relaxed the EDNS compliance requirement and includes an alternative fix for 2018-07.

Since reports of this started coming in yesterday, some domains have been fixed by their owners, but a long tail of broken zones remains for now.

We have decided to release this increase in strictness in the PowerDNS Recursor 4.2.0, so that domain owners can work on their server’s compliance. We urge operators of authoritative servers to check their domains and servers with the EDNS compliance tool and act upon its results. Increased EDNS compliance strictness will be added to many DNS resolvers coming next February.

The changelog is as follows:

  • #7172: Revert ‘Keep the EDNS status of a server on FormErr with EDNS’
  • #7174: Refuse queries for all meta-types

As always, the tarball(sig) can be found on the downloads website and packages for CentOS 6 and 7, Ubuntu Trusty, Xenial and Bionic and Debian Jessie and Stretch can be found on

PowerDNS Recursor 4.1.6 Released

We have just released the PowerDNS Recursor 4.1.6. This release fixes an issue with DNSSEC validation introduced in Recursor 4.1.5 by reverting a code-change related to the acceptation of ADDITIONAL records. We will investigate this issue in detail the coming days, but found it necessary to issue an update with a fix early.

The full changelog is very short:

  • Revert “rec: Authority records in AA=1 CNAME answer are authoritative”. References: #7158, pull request 7159

The tarball(signature) is available at and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

PowerDNS Authoritative Server 4.0.6 & 4.1.5 and Recursor 4.0.9 & 4.1.5 Released

We’ve released PowerDNS Authoritative Server 4.0.6 & 4.1.5 and Recursor 4.0.9 & 4.1.5.

These are security releases with additional minor improvements and bug fixes.

Minimal patches for the releases are available at

The changelogs look as follows:

Authoritative Server 4.1.5

This release fixes the following security advisories:

  • PowerDNS Security Advisory 2018-03 (CVE-2018-10851)
  • PowerDNS Security Advisory 2018-05 (CVE-2018-14626)


  • Apply alias scopemask after chasing (#6976)
  • Release memory in case of error in the openssl ecdsa constructor (#6917)
  • Switch to devtoolset 7 for el6 (#7118, #7040)

Bug Fixes

  • Crafted zone record can cause a denial of service (CVE-2018-10851, #7149)
  • Packet cache pollution via crafted query (CVE-2018-14626, #7149)
  • Fix compilation with libressl 2.7.0+ (#6948, #6943)
  • Actually truncate truncated responses (#6913)

Authoritative Server 4.0.6

This release fixes PowerDNS Security Advisory 2018-03 (CVE-2018-10851).

Bug fixes

  • Crafted zone record can cause a denial of service (CVE-2018-10851, #7150)
  • Skip v6-dependent test when pdns_test_no_ipv6 is set in environment (#6013)
  • Fix el6 builds (#7135)


  • Prevent cname + other data with dnsupdate (#6315)
  • Switch to devtoolset 7 for el6 (#7119)

Recursor 4.1.5

This release fixes the following security advisories:

  • PowerDNS Security Advisory 2018-04 (CVE-2018-10851)
  • PowerDNS Security Advisory 2018-06 (CVE-2018-14626)
  • PowerDNS Security Advisory 2018-07 (CVE-2018-14644)


  • Add pdnslog to lua configuration scripts (Chris Hofstaedtler) (#6919, #6848)
  • Fix compilation with libressl 2.7.0+ (#6948, #6943)
  • Export outgoing ECS value and server ID in protobuf (if any) (#7004, #6991, #6989)
  • Switch to devtoolset 7 for el6 (#7122, #7040)
  • Allow the signature inception to be off by a number of seconds (Kees Monshouwer) (#7125, #7081)

Bug Fixes

  • Crafted answer can cause a denial of service (CVE-2018-10851, #7151)
  • Packet cache pollution via crafted query (CVE-2018-14626, #7151)
  • Crafted query for meta-types can cause a denial of service (CVE-2018-14644, #7151)
  • Delay the creation of rpz threads until we have dropped privileges (#6984 #6792)
  • Cleanup the netmask trees used for the ecs index on removals (#6961 #6960)
  • Make sure that the ecs scope from the auth is < to the source (#6963, #6605)
  • Authority records in aa=1 cname answer are authoritative (#6980, #6979)
  • Avoid a memory leak in catch-all exception handler (#7073)
  • Don’t require authoritative answers for forward-recurse zones (#6741, #6340)
  • Release memory in case of error in the openssl ecdsa constructor (#6917)
  • Convert a few uses to toLogString to print DNSName’s that may be empty in a safer manner (#6925, #6924)
  • Avoid a crash on DEC Alpha systems (#6945)
  • Clear all caches on (N)TA changes (#6951, #6949)

Recursor 4.0.9

This release fixes the following security advisories:

  • PowerDNS Security Advisory 2018-04 (CVE-2018-10851)
  • PowerDNS Security Advisory 2018-06 (CVE-2018-14626)
  • PowerDNS Security Advisory 2018-07 (CVE-2018-14644)

Bug fixes

  • Crafted answer can cause a denial of service (CVE-2018-10851, #7152)
  • Packet cache pollution via crafted query (CVE-2018-14626, #7152)
  • Crafted query for meta-types can cause a denial of service (CVE-2018-14644, #7152)

The tarballs and signatures are available at and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from  Raspberry PI packages will follow tomorrow.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

FOSDEM 2019 DNS devroom CfP

Hello DNS enthusiasts and other developers,

After a successful and packed half-day DNS devroom at FOSDEM 2018, we are happy to announce a full-day DNS devroom at FOSDEM 2019.

As with last year, we hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding or system administrators responsible for DNS infrastructure.

We have been allotted a room on Sunday 3 February 2019. We expect to schedule 30 minutes per talk, including questions, but if you need more or less time, we can discuss this.

If you have something you’d like to share with your fellow developers, please head to pentabarf at Examples of topics are measuring, monitoring, DNS libraries, and anecdotes on how you’ve (ab)used the DNS. Here’s the 2018 schedule, for your inspiration: .

The deadline for submission is December 1st. If you have a FOSDEM pentabarf account from a previous year, please use that account. Reach out to if you run into any trouble.

See you there!

Peter van Dijk, Shane Kerr, Pieter Lexis, and Kees Monshouwer

Spoofing DNS with fragments

With some care, it turns out to be possible to spoof fake DNS responses using fragmented datagrams. While preparing a presentation for XS4ALL back in 2009, I found out how this could be done, but I never got round to formally publishing the technique. The presentation was however made available.

Update: this “discovery” has now been dated back to at least 2008 when Florian Weimer knew about it & tells us it was communicated clearly and widely back then.

In 2013, Amir Herzberg & Haya Shulman (while at Bar Ilan University) published a paper called Fragmentation Considered Poisonous. In this paper they explain how fragmented DNS responses can be used for cache poisoning. Later that year CZNIC presented about this paper and its techniques at RIPE 67.

A stunning 72 papers cite the original article, but as of 2018 not too many people know about this cache poisoning method.

More recently, The Register reported that another team, also involving Dr Shulman (now at Fraunhofer Institute for Secure Information Technology), has been able to use fragmented DNS responses to acquire certificates for domain names whose nameservers they do not control. They were able to demonstrate this in real life, which is a remarkable achievement. Incidentally, this team includes Amit Klein who in 2008 discovered & reported a weakness in PowerDNS.

Full details will be presented at the ACM Conference on Computer and Communications Security in Toronto, October 18. This presentation will also propose countermeasures.

Meanwhile, in this post, I hope to explain a (likely) part of their technique.

Whole datagram DNS spoofing

To match bona fide DNS responses to their corresponding queries, resolvers and operating system check:

  • Name of the query
  • Type of the query
  • Source/destination address
  • Destination port (16 bits)
  • DNS transaction ID (16 bits)

The first three items can be predictable, the last two aren’t supposed to be. To spoof in a false response therefore means we need to guess 32 bits of random. To do so, the attacker needs to send the resolver lots and lots of fake answers with guesses for destination port and the transaction ID. Over (prolonged) time, their chosen response arrives ahead of the authentic response, is accepted, and they are able to spoof a domain name. Profit.

Screenshot from 2018-09-10 22-12-57

In practice this turns out to be very hard to do. The 32 bit requirement plus the short timeframe in which to send false responses means that as far as I know, this has been demonstrated in a lab setting just once. Anecdotal reports of blindly spoofing a fully randomized source port resolver have not been substantiated.


DNS queries and responses can be carried in UDP datagrams. A UDP datagram can be many kilobytes in size – far larger than most UDP packets. This means that a sufficiently large UDP response datagram can get split up into multiple packets. These are then called fragments.

Such fragments travel the network separately, to be joined together again on receipt.

Fragmented DNS responses happen occasionally with DNSSEC, for example in this case:

$ dig -t mx +dnssec -4 +bufsize=16000
43.028963 IP > 20903+ [1au] MX? (48)
43.035379 IP > 20903*- 3/5/21 
  MX 20, MX 10, RRSIG (1472)
43.035391 IP > ip-proto-17

The final line represents a fragment, which only notes it is UDP (protocol 17).

Matching fragments together is quite comparable to matching DNS queries to responses. Every IP packet, even a fragment, carries a 16 bit number called an IPID. This IPID is not copied from the query to the response, it is picked by the DNS responder.

Screenshot from 2018-09-10 22-13-30

On receipt, fragments are grouped by IPID, after which the checksum of the reassembled datagram is checked. If correct, the DNS response gets forwarded to the resolver process.

If we want to spoof a DNS response, we could pick a DNS query that leads to a fragmented datagram, and then try to spoof only the second fragment. On first sight, this does not appear to be much easier as we now need to guess the IPID (16 bits) and we also need to make sure the checksum of the whole datagram matches (another 16 bits). This then also requires a 32 bit guess to succeed.

However, if we send a server a DNS query, it will most of the time send the same DNS response to everyone who asks (also for fragmented answers). In other words, if the attacker wants to spoof a certain response, it will know exactly what that response looks like – with the exception of the destination port and the DNS transaction ID (32 bits).

But note that both of these unpredictable parts are in the first fragment. The second fragment is completely static, except for the IPID. Now for the clever bit.

The ‘internet checksum’ is literally .. a sum. So the checksum of the entire datagram consists of the checksum of the first fragment plus the checksum of the second fragment (modulo 16 bits).

Screenshot from 2018-09-10 22-13-49

This means that to make sure the whole reassembled datagram passes the checksum test, all we have to do is make sure that our fake second fragment has the same known partial checksum as the original. We can pick the checksum of our fake second segment easily through the TTL of the our chosen response record.

This leaves us with only 16 bits to guess, which given the birthday paradox is not that hard.


Randomness of the IPID

So how random is the IPID, does it even represent a 16-bit challenge? According to the 2013 paper, some operating systems pick the IPID from a global counter. This means an attacker can learn the currently used IPID and predict the one used for the next response with pretty good accuracy.

Other operating systems use an IPID that increments per destination which means we can’t remotely guess the IPID. It turns out however that through clever use of multiple fragments, this still allows an attacker to “capture” one of these. See the original paper for details.

Is that it?

Definitely not. In order to get a certificate issued falsely using this technique requires several additional elements. First we must be able to force many questions. Secondly, we must make sure that the original authoritative server fragments the answer just right. There are ways to do both, but they are not easy.

I await the presentation at the ACM conference in October eagerly – but I’m pretty sure it will build on the technique outlined above.


In the meantime, DNSSEC does actually protect against this vulnerability, but it does require that your domain is signed and that your CA validates. This may not yet be the case.