What does PowerDNS actually do?
This is a good question, one we can ask about any company. How do they stay alive, what services do they deliver, who do they sell them to?
For Open Source companies, the question is doubly interesting: if your software is so great, and you give it away for free (as in freedom), how do you survive?
In this post I want to explain how PowerDNS (and our parent Open-Xchange) have squared this circle. In many large countries, PowerDNS & Open-Xchange are now the DNS supplier to the largest telecommunications companies.
Everything starts with products of course, and PowerDNS has four main ones. The Authoritative Server hosts domain names, and it dominates the mid-size market of hosters running up to 10 million domains. While there are other very good open source authoritative nameservers, PowerDNS has an edge because of its wide support for databases, its DNS-aware checking API and lately the new LUA records which deliver DNS based traffic-engineering, failover and load-balancing.
The PowerDNS Recursor meanwhile has picked an interesting niche among resolvers & caches, where again the open source landscape delivers outstandingly good software. The Recursor supports the big important features of course, like DNSSEC and shortly QName minimization, but our focus has been on providing servers that deliver great performance & rock-solid stability for high-capacity operators, while retaining the flexibility to do malware filtering, parental control and security analysis. Of specific note is our support for interoperating with CDNs like Akamai that require EDNS Client Subnet, while retaining top performance.
Our third product, dnsdist, for now appears to be unique – a scriptable high performance, DoS-aware load balancer & distributor of DNS queries. It protects installations from denial of service attacks, of which even small ones can burn up a lot of CPU. Dnsdist also delivers such modern encrypted variants of DNS as DNS over HTTPs and DNS over TLS. It has a built-in cache that delivers stellar performance even on top of slow backend. Dnsdist is highly flexible and can redirect queries based on almost every aspect of a question. It frequently replaces dedicated load-balancer hardware. Although only a few years old, we were very pleased to learn dnsdist was part of the recent NATO Locked Shields cybersecurity exercise in Estonia.
These first three products are built in close cooperation with our lovely community. A community is far more than people supplying patches. It also consists of users vocally telling us what they need or pointing out that what we do is exactly what they don’t need. It consists of the heroes that test pre-releases and let us know if the quality or the features are where they should be. We are also super happy with users that point out where documentation is missing or wrong. Conversely, we truly enjoy helping our users improve their lives with open source, where we cooperate daily with other open source projects.
Finally there is the part that is not open source, the PowerDNS Platform that delivers the first three products in an integrated, automated, monitored and graphed solution, with a central graphical & scriptable control plane. In addition, with OX Protect, this platform provides for malware filtering & parental control.
What we actually sell
Who would buy a nameserver when there are so many good ones available to download for free? Asking the question almost answers it: operators that do not wish to deploy and assemble the raw goods they can find on the internet. While it is entirely possible to have teams and infrastructure in place to do just that, many modern telecommunications operators have decided to only deploy fully supported units of functionality.
While it is entirely possible to assemble similar functionality to our Platform with open source components, this is a lot of work and operators would have to learn how to scale, monitor and control such a system. There is value in getting this as a preassambled whole – even as we retain our open interfaces for integration into existing monitoring and graphing systems. But beyond that – assembling platforms by hand is a risky business.
This is a variant of the old story that no serious company would run software without a support contract in place. While this was not quite true, what we are seeing today is a step even beyond that. A support contract is a suitable solution if the operator decides to take full ownership of architecting, deploying, testing and running a project. The support is important for the rare cases where things do not go as planned – it is in fact a warranty.
Although we have a number of excellent customers where we provide such support as a service, in almost all cases our engagement these days goes far beyond answering email messages.
A large scale enterprise, like a telecommunication service provider, is a complex organization. For every project there are many stakeholders – there are product departments that want specific functionalities and performance for the subscribers. There are legal and compliance departments that make sure vendors have the right certifications and can be held liable for intellectual property violations. Service Level Agreements need to be spelled out in great detail, including penalty clauses. Whenever consumer communications are touched, GDPR compliance is of utmost importance.
Then there are network and infrastructure teams that each have their own requirements for hardware, virtualization specifications and capacity. On top of this, there are always existing software installations with sometimes custom features that need to be retained and migrated.
Of supreme importance is high-level sign-off. Senior management needs to be reassured that this is a vendor worth betting on. Or as a big PowerDNS customer once phrased it “you need to hire more golf players to grow”. We took this message on board. This is also why you will be seeing PowerDNS opine on 5G deployments, on Network Function Virtualization and End-to-End performance monitoring and reporting.
To round this off, a project of any serious size will be run through a procurement department, often at group level, sometimes even in a different company. Navigating an RFP is a skill in itself – especially when third party integrators or vendors are fronting the project.
In short, to deliver a working solution requires coordination among all these departments and the creation of an architecture, a training plan, a support structure, a hardware/software layout, a migration procedure, and all of this needs to be ‘sold’ through the procurement department.
So if a modern telecommunications company wants to deploy a new nameserver constellation, it will require not just the software but all of the above.
After a project has been specced up properly and the papers are signed, next up is the actual deployment and migration. When we launched PowerDNS in the late 1990s, it was clearly up to the operator to perform deployment and migrations. This made sense on one level: testing & deploying software (or hardware) is the best way to make sure operators fully understand what they bought and that they can support it themselves.
Conversely however, a vendor deploys and migrates its products all the time. Vendors therefore have developed tooling and procedures to make this happen swiftly. We can’t expect a service provider that does a hardware refresh once every 4 years to have performed many migrations itself with the existing staff – it simply does not happen that often.
These days, most customers ask us to be very or even completely hands-on during testing, rollout and migration. We do however vastly prefer to perform such operations in close cooperation with the intended operators – because it remains true that “doing” is the ultimate form of training.
Traditionally, vendors grudgingly provide support in case of proven malfunctions. It is now so hard to open tickets with major network vendors that at least one company we know of sells “opening network vendor tickets” as-a-service – allowing operators to focus on solving problems. This is not how we want our customers to work with us however!
To our large scale operators, we provide collaborative operations services. This means there is no need to ‘escalate’ something so it is an issue. Whenever there is a need for a configuration change, or there is a worry because of a graph that is going in the wrong way, we are there to provide guidance, scripts or hands on help.
What we have managed to do is retain our open source collaborative nature, but deliver it also to the largest of operators, wrapped in solid service level agreements.
Summing it up
“The secret to PowerDNS’s success” is that we are able to take excellent open source software, and deliver it to large scale telecommunications service providers, while continuing to be an open and accessible vendor. And it turns out that everything we provide on top of the raw open source software is worth good money to our customers.
As of 2019, PowerDNS is growing rapidly. And as the rollout of DNS over TLS/HTTPS, 5G transition, (Network Function) Virtualization at service providers continues, it appears we will be an ever larger part of the telecommunication landscape.
If you our your company are interested in working with us for your next DNS project, please do not hesitate to contact us! For more about PowerDNS, please head to https://powerdns.com or to https://open-xchange.com/.
The Beta 1 release comes with a lot of bug fixes, improvements and also some new features:
- Add a new
max-cache-bogus-ttloption to cap the TTL of a record that has been validated as
Bogusin the query cache, so it is not kept around for days if the initial TTL is high,
- Add options
dont-throttle-netmasksto throttle authoritative servers that do not answer queries or send responses the recursor does not like,
- Add an option (
pdns-distributes-queries) to make the distributor thread use a bounded load-balancing algorithm while distributing queries to worker threads, making sure that no thread is assigned more queries than
distribution-load-factortimes the average number of queries currently processed by all the workers.
Please see the changelog for details.
The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie, Stretch and Buster, Ubuntu Trusty, Xenial, Bionic and Cosmic are available from repo.powerdns.com.
This is a maintenance release with improvements for high-performance sites (and a wild bug fix appeared).
- #7634: Use a bounded load-balancing algo to distribute queries.
- #7651: Implement a configurable ECS cache limit so responses with an ECS scope more specific than a certain threshold and a TTL smaller than a specific threshold are not inserted into the records cache at all.
- #7647: Provide CPU usage statistics per thread (worker & distributor).
- #7495: Correctly interpret an empty AXFR response to an IXFR query.
This release contains a bunch of backports, improvements and bug fixes that we wanted in the 4.1.x release channel after the 4.1.7 security release was out of the door.
Please see the changelog for full details:
- #7604: Correctly interpret an empty AXFR response to an IXFR query,
- #7610: Fix replying from ANY address for non-standard port,
- #7609: Fix rectify for ENT records in narrow zones,
- #7607: Do not compress the root,
- #7608: Fix dot stripping in
- #7605: Fix invalid SOA record in MySQL which prevented the authoritative server from starting,
- #7603: Prevent leak of file descriptor if running out of ports for incoming AXFR,
- #7602: Fix API search failed with “Commands out of sync; you can’t run this command now”,
- #7509: Plug
- #7567: EL6: fix
CXXFLAGSto build with compiler optimizations.
This release fixes an issue with security implications that has been recently reported in the HTTP remote backend of the PowerDNS Authoritative Server. Setups that are not using this backend are not impacted by this issue. More information can be found in the corresponding security advisory:
- PowerDNS Security Advisory 2019-03 (CVE-2019-3871): Insufficient validation in the HTTP remote backend
There are some additional smaller improvements and bug fixes in this release. Please see the changelog:
- #7576: Insufficient validation in the HTTP remote backend
- #7546: Fix API search failed with “Commands out of sync; you can’t run this command now”
- #7219: Fix static lookup when using weighted records on multiple record types.
- #7516: Report “checkKey“ errors upwards.
The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty, Xenial and Cosmic are available from repo.powerdns.com.
These two releases fix an issue with security implications that has been recently reported in the HTTP remote backend of the PowerDNS Authoritative Server. Setups that are not using this backend are not impacted by this issue. More information can be found in the corresponding security advisory:
- PowerDNS Security Advisory 2019-03 (CVE-2019-3871): Insufficient validation in the HTTP remote backend
It affects PowerDNS Authoritative Server up to and including 4.1.6. Please note that at the time of writing, PowerDNS Authoritative Server 3.4 and below are no longer supported, as described in https://doc.powerdns.com/authoritative/appendices/EOL.html.
Minimal patches are available at https://downloads.powerdns.com/patches/2019-03/.
The 4.0.7 changelog:
- #7582: Insufficient validation in the HTTP remote backend
The 4.1.7 changelog:
- #7577: Insufficient validation in the HTTP remote backend
The 4.0.7 tarball (signature) and 4.1.7 tarball (signature) are available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from repo.powerdns.com.
It has been too long a time since the release of PowerDNS Authoritative Server 4.2.0-alpha1. The Beta 1 release comes with a lot of bug fixes, improvements and also some new features:
- LMDB backend,
- Fixes for OpenBSD and Sparc64 courtesy of Otto Moerbeek,
- A lowering of the UDP truncation limit from 1680 to 1232 bytes (this is the largest number of payload bytes that can fit in the smallest IPv6 packet).
This release was made possible by contributions from: Aki Tuomi, Josh Soref, Klaus Darilion, Kees Monshouwer, Matt Nordhoff, Ruben Kerkhof, spirillen, Chris Hofstaedtler, Baptiste Courtois, @alebeta90, Chris Boot, Hannu Ylitalo, @jonathaneen, Robin Mulder, Thomas DU BOYS, @mimianddaniel and Donatas.
The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Trusty, Xenial, Bionic and Cosmic are available from repo.powerdns.com.