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:
* https://downloads.powerdns.com/releases/
* Soon: https://www.monshouwer.eu/download/3rd_party/pdns/ (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 http://summit.open-xchange.com/

All PowerDNS users are cordially invited to join the summit, which is free of charge: http://www.cvent.com/d/6rq9my/4W or using the ‘Register Now’ button at the bottom of http://summit.open-xchange.com/ page.

If you register, please drop us an email (powerdns.ideas @ powerdns.com) 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

What is a PowerDNS Backend? And how do I make it send an NXDOMAIN?

PowerDNS is a dynamic nameserver, with a ton of backends. If the supplied backends aren’t flexible enough, our architecture enables operators to write their own, or to use one of our forwarding backends (Pipe and Remote), which can send PowerDNS queries over a pipe, a UNIX domain socket, an HTTP connection or even a ZMQ link.

Over time, many operators have done just that, and this allows you to mix a ‘real’ nameserver, with everything you can expect from that, with a custom data source.

Very often however (weekly at this point!), we get questions from users confused about our backends:

  1. Why does my backend get ANY queries, when no ANY queries are sent to the nameserver?
  2. How do I generate an NXDOMAIN response from my backend?
  3. Why do I get SOA queries, even for domains not in my backend?
  4. Why does PowerDNS ignore the records my backend sent back to put in the packet?
  5. Why do I get more backend queries than DNS queries (sometimes)?
  6. Why do I get *way less* backend queries than DNS queries at other times?
  7. Why are backends launched for AXFRs?

All of these questions stem from a misunderstanding what a PowerDNS backend is, possibly combined with the fact that people want things that aren’t easily achieved from a backend. We may not have been doing a sufficiently good job explaining PowerDNS backends.

To explain, we must first do away with what a PowerDNS backend is not. It is for example not this:


In this model, packets from the internet get handed over to a backend, and the backend drafts an answer packet for PowerDNS to send out. We do have functionality that does that, more about which later, but backends are not it. Backends get DNS queries and return data, or perhaps none if there isn’t any.

So why did we not build it as above? It turns out DNS needs a lot of logic. So for example, if a nameserver gets a question for ‘www.powerdns.com’, it has to figure out if it is even authoritative for that question, or in other words, does it have a zone with relevant data for that query? To figure that out, the RFC algorithm tells us we must find the best zone that matches the query. Initially this could be ‘www.powerdns.com’, and if we don’t have that zone, we should look for ‘powerdns.com’, then ‘com’ and finally perhaps a root zone.

Once we have the best zone ready, we must check if a ‘www’ record exists, if there is perhaps a delegation of ‘www’ to another server, if there is perhaps a CNAME for it, if there is a wildcard ‘*.powerdns.com’ record etc. DNSSEC brings further questions, should we do DNSSEC processing, and if so, are there keys we need to sign with?

Because of all this complication, and because back in 2000 we already predicted there would be many many backends, we decided to keep the ‘DNS logic’ central, where we would implement it once and leave the backends to being providers of data, pure and simple. It might have been better if we called the backends ‘DNS Data stores’ perhaps. But alas, we missed that chance.

So now that we’ve described how it doesn’t work, let’s check out the present day reality:


Packets come in from the Internet and get processed by our PacketHandler class. This class has all the logic on best zone selection, CNAMEs, wildcards, delegations, DNSSEC metadata etc. And to figure this all out, it sends many questions to the UeberBackend. The UeberBackend is subsequently responsible for distributing the queries over the multiple possible configured backends. In addition, it hosts a cache which optionally remembers answers (or lack thereof) a backend provided previously.

The best way to understand this procedure is that the PacketHandler turns DNS packets into data backend queries. This also means that backends should do no thinking. Just answer the question, with data or none. The PacketHandler can send many kinds of questions depending on the nature of your zone. For example, it may ask about SOA records, even for zones you do not host in your backend. This is because when a question comes in for ‘www.something.com’, PowerDNS must go hunt for a backend with relevant data.

As a further example of how things work, if PowerDNS asks a backend for ‘www.powerdns.com’, it can answer with a CNAME to ‘webserver1.cloudprovider.com’. PowerDNS itself then will attempt to follow the CNAME chain and check if there is data for the ‘cloudprovider.com’ zone. The backend does not need to think about this!

Why does my backend get ANY queries when no such queries are sent to the nameserver?

In addition, as a speedup, PowerDNS may ask ANY questions, which allow it to see if there is a CNAME for the DNS query name, and if there is no CNAME, get the right answer from the same question. This answers questions 1 and 3 from the list above.

How do I generate an NXDOMAIN answer from my backend?

Answering question 2, how to generate an NXDOMAIN from my backend also becomes easy: you need to convince PowerDNS that you do host the domain in question by delivering a SOA (aka Start of Authority) record when asked for your zone, and when you then get a question for ‘nosuchdomain.powerdns.com’, just return.. nothing. From this PowerDNS will conclude that 1) you host the zone 2) there is no record called ‘nosuchdomain.powerdns.com’. And this will lead to an NXDOMAIN.

So, the clarify even further, if you run a zone called ‘maik.de’, and PowerDNS receives a DNS query for ‘nosuchdomain.maik.de’, it will ask your backend if it knows about ‘nosuchdomain.maik.de’, and you should return no data. Next it will ask about ‘maik.de’, and if it asked for ANY or the SOA record, you should return the SOA record. From this PowerDNS will conclude that it should send out an NXDOMAIN.

Why does PowerDNS ignore the records my backend sends back to put in the packet?

Answering question 4, if a backend sends back records that PowerDNS did not ask for, these do indeed not end up in your packet. PowerDNS asked the backend if it had data for a certain name, and any replies not for that name are out of spec. Not only might PowerDNS ignore them, it could also decide your backend is not functioning correctly and drop the packet.

Why do I get way less/way more backend queries than DNS queries?

Answering questions 5 and 6: you may indeed get many more backend queries than DNS packets coming in. An individual DNS query may cause 4 or more backend queries. Each of these queries is necessary to figure out details about the domain. If your Pipe backend is flooded with questions it does not want to hear about, the ‘pipe-regex’ feature is available to quickly deny any knowledge about such domains.

You may also get a lot less questions, since the UberBackend has a cache that optionally stores previous answers from your backend. If this is not what you want, caches can be disabled, which may be useful if you want to provide fully dynamic answers.

Why does PowerDNS instantiate extra copies of my backend for AXFR?

Finally, the answer to question 7, why do new backends get spawned for zone transfers? An AXFR may last minutes, and since during those minutes a backend can do nothing else, a dedicated instance is created for each zone transfer (both incoming and outgoing).


We hope that this information has been helpful in clarifying what a PowerDNS backend is and isn’t.

Finally, if it turns out a PowerDNS backend is not actually what you want, you may be interested to hear about a currently undocumented feature in the PowerDNS Authoritative Server that we use for testing. This allows you to intercept queries sent to PowerDNS Authoritative Server, much like is possible (and documented) in the PowerDNS Recursor.

From the point of interception, you can mangle questions to your heart’s delight from Lua, and send back any answer you want. This feature will become documented and supported in PowerDNS 4.0, but for now, study the ‘lua-prequery-script’ configuration parameter. And if you have any questions, you can find us on the mailing lists or IRC.

Good luck!

Authoritative Server 3.4.5, 3.3.3 and Recursor 3.7.3, 3.6.4 released

We’re pleased to announce the availibility of a number of  PowerDNS releases. These releases share a performance update that prevents short bursts of high resource usage with malformed qnames. The full changelogs can be viewed by using the links below:

PowerDNS user are recommended to update to the latest release, preferably in the latest release branch, this is 3.4 for the Authoritative Server and 3.7 for the Recursor.

Tar.gz and packages are available on:

PowerDNS needs your help: What are we missing?

Hi everybody,

As we’re working on PowerDNS 4.x, we are wondering: what are we missing?

The somewhat longer story is that as a software developer, a sort of feature-blindness creeps up on you. We try to make the software better, faster etc, but by focusing so much on the technology, one can lose sight of the actual use cases.

In this way it is possible that a software vendor neglects to implement something, even though many users desperately want it. If so, please speak up! The short version: please mail powerdns.ideas at powerdns.com your ideas!

As concrete examples, PowerDNS took its time to add an API, and once we had it, people immediately started using it, even before we had documented the API. Similarly, for many years, we did not deliver a proper graphing solution, and now that it is there it is highly popular.

But what more are we missing? Should we expand into IPAM and do DHCP and IP address management? Should we make an out of the box NAT64/DNS64 solution? Do we need to improve replication beyond “database native” and “AXFR-based” (so ‘super-duper-slave’)?

Should we start doing versioned databases so people can roll back changes?  IXFR?

Should we add a built-in DNS based load balancer where we poll if your IP addresses are up?

Or would it be wise to move on beyond the geographical versatile backends, and simply add ‘US’ and ‘Europe’, ‘Oceania’, ‘Asia’ IP address profiles?

Should the recursor gain cache sharing abilities? Or pre-fetching? Or even TTL-faking in case auths are down?

The list above is just to prime your imagination: if you have any ideas on what you are missing, please reach out to powerdns.ideas at powerdns.com, or use our contact form.


PowerDNS 2.x End of Life Statement

PowerDNS 2.x End of Life Statement

21st of May 2015

PowerDNS Authoritative Server 2.9.22 was released more than 6 years ago, in January 2009. Because of its immense and durable popularity, some patch releases have been provided, the last one of which ( was made available over three years ago in January 2012.

The 2.9.22.x series contains a number of probable and actual violations of the DNS standards. In addition, some behaviours of 2.9.22.x are standards conforming but cause interoperability problems in 2015. Finally, and earlier are impacted by PowerDNS Security Advisory 2012-01, which means PowerDNS can be used in a Denial of Service attack.

Although we have long been telling users that we can no longer support the use of 2.x, and urging upgrades to 3.x, with this statement we formally declare 2.x end of life.

This means that any 2.x issues will not be addressed. This has been the case for a long time, but with this statement we make it formal.

To upgrade to 3.x, please consult the instructions on how to upgrade the database. If you need help with upgrading, we provide migration services to our supported users. If you are currently running 2.9.22 and need help to tide you over, we can also provide that as part of a support agreement.

But we urge everyone to move on to PowerDNS Authoritative Server 3.4 or later – it is a faster, more standards conforming and more powerful nameserver!