Second Alpha Release of DNSDist 1.6.0

Hi everyone,

We are happy to announce the second alpha release of dnsdist 1.6.0. This release contains mostly fixes for issues reported in the first release candidate:

  • A race condition was found to sometimes occur at startup, making it possible for the first TCP connection to happen before the creation of TCP workers and lead to a crash.
  • Stéphane Bortzmeyer reported many TCP timeouts with the first alpha that did not happen with 1.5.x. We unfortunately did not manage to reproduce these timeouts, but we spent quite some time expanding the coverage of our TCP code, uncovering several bugs in the process. Although we unfortunately cannot be sure that the issue experienced by Stéphane has been fixed, the resulting code has seen much more testing and we have received excellent feedback from other users in the meantime, leading to this second alpha candidate.
  • The cache cleaning algorithm did not properly remove expired entries from all shards, when more than one shard was used and setCacheCleaningPercentage set below 100%. This led to a drop in the cache efficiency in the long run.
  • A null pointer dereference has been found when accessing a dynamic BPF block (DynBPF) object in client mode.
  • A debug line was not properly removed in the web server code, logging a new line for every HTTP query.

In addition to these fixes, Sander Hoentjen contributed several improvements to allow spoofing answers with multiple records, and Aki Tuomi introduced automatic conversion to string for several objects in Lua. Many thanks to them!

Please see the dnsdist website for the more complete changelog and the current documentation.

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

Release tarballs are available on the downloads website, and packages for CentOS 7 and 8, Debian Buster and Ubuntu Bionic and Focal are available from our repository.

With the future 1.6.0 final release, the 1.3.x releases will be EOL and the 1.4.x releases will go into critical security fixes only mode.

We would also like to take this opportunity to announce that we will stop supporting systems using 32-bit time. This includes 32-bit Linux platforms like arm and i386 before kernel version 5.1.

PowerDNS Authoritative Server 4.4.1

Hello!

We are proud to announce version 4.4.1 of the Authoritative Server. This releases fixes several small issues discovered since the release of 4.4.0.

Please find a full list in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 7 and 8, Debian Buster, Ubuntu Bionic and Focal are available from repo.powerdns.com.

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

First Alpha Release of DNSDist 1.6.0

Hello!

We are proud to announce the first alpha release of dnsdist 1.6.0. This release contains several new exciting features, as well as improvements and bug fixes.

In our view, the most exciting new feature is the support of out-of-order processing for TCP and DNS over TLS connections. Out-of-order processing makes it possible to have several concurrent queries on the same TCP connection, and to receive the answers to these queries as soon as they are ready. Along with connection reuse, this reduces the overhead of TCP by a huge factor. Starting with 1.6.0, dnsdist will accept up to 65536 concurrent queries on the same incoming TCP connection, and will pass all of these to the backend over a single connection as well, provided that the backend supports it. This feature is not enabled by default, and can be enabled via the maxInFlight parameter of the addLocal/addTLSLocal (client-side) and the newServer (backend-side) commands.

This new version also brings support for accepting a Proxy Protocol header on incoming connections, making it possible for a frontend to provide dnsdist with the initial source and destination ports and addresses, as well as custom values. dnsdist can then process, add and remove values before passing the information to the backend. Chaining two dnsdist instances has never been this easy!

Other new features include the ability to define custom web endpoints in Lua, to extend the existing API, as well as the ability to create blazing-fast, lock-less per-thread custom load-balancing policies using the Lua foreign function interface (FFI).

Among the many improvements, dnsdist’s packet cache no longer hashes EDNS Cookies by default, which means that two queries that are identical except for the content of their cookies will now be served the same answer. Note that it might necessary to restore the existing behaviour when dnsdist is in front of a backend actually using EDNS Cookies, which can be done via the cookieHashing parameter to newPacketCache.

Users of our own protocol buffer logging mechanism, or of dnstap, will be happy to learn that we replaced our implementation based on Google’s protocol buffer library by a tremendously faster one, based on the protozero library. This change results in much lower CPU utilization and increased scalability in a transparent way.

If you intend to test this alpha release, for which we would be very grateful, please be aware that a few actions and commands have been renamed to clear some ambiguities. Almost all actions that allow further processing of rules now start with ‘Set’, to prevent mistakes:

Some commands changing the order of the rules could have easily been confused with the ones providing insight into the current traffic, and have therefore also been renamed:

Please also note that the use of additional parameters on the webserver command has been deprecated in favor of using setWebserverConfig.

Regular users should not be impacted by this change, but packagers should be aware that since 1.6.0 dnsdist now uses the C++17 standard instead of the C++11 one it was previously using.

Please see the dnsdist website for the more complete changelog and the current documentation.

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

Release tarballs are available on the downloads website, and packages for CentOS 7 and 8, Debian Buster and Ubuntu Bionic and Focal are available from our repository.

With the future 1.6.0 final release, the 1.3.x releases will be EOL and the 1.4.x releases will go into critical security fixes only mode.

We would also like to take this opportunity to announce that we will stop supporting systems using 32-bit time. This includes 32-bit Linux platforms like arm and i386 before kernel version 5.1.

Finally, we would like to thank the PowerDNS community and all external contributors for their great work in this release, and in particular Stephane Bakhos, Georgeto, Matti Hiljanen, Nuitari, Sukhbir Singh and Mischan Toosarani-Hausberger!

First Alpha Release of PowerDNS Recursor 4.5.0

Hello!,

We are proud to announce the first alpha release of what should become PowerDNS Recursor 4.5.0. This release contains various bug fixes, improvements and new features. 

The upcoming 4.5.0 release features a re-worked negative cache that is shared between threads, allowing more efficient use of the cache and reduced memory consumption.

Support for Extended DNS Errors (RFC 8914) has been added. These can be enabled by setting the extended-resolution-errors setting to ‘yes’, this will send DNSSEC and resolution related errors to clients. Extended Errors are also hooked up to the Lua scripting engine, allowing fine-grained setting of both the error code and extra information in the response.

A “refresh almost expired records” (also called “refetch”) mechanism has been introduced to keep the record cache warm. In short, if a query comes in and the cached record’s TTL is almost expired (within N percent of its original value) the cached record is served to the client and the record queried for in the background, ensuring that new queries for that record are fresh and served from the cache.

Other new features and improvements are:

  • The complete protobuffer and dnstap logging code has been rewritten to have much smaller performance impact.
  • We have introduced non-offensive synonyms for words used in settings. See the upgrade guide.
  • The default minimum TTL override has been changed from 0 to 1.

Please refer to the changelog for additional details.

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

The tarball (signature) is available from our download server and packages for CentOS 7 and 8, Debian Buster and Ubuntu Bionic and Focal are available from our repository.

With the future 4.5.0 final release, the 4.2.x releases will be EOL and the 4.3.x releases will go into critical security fixes only mode. Consult the EOL policy for more details.

We would also like to take this opportunity to announce that we will stop supporting systems using 32-bit time. This includes 32-bit Linux platforms like arm and i386 before kernel version 5.1.

We are grateful to the PowerDNS community for the reporting of bugs, issues, feature requests, and especially to the submitters of fixes and features.

PowerDNS Authoritative Server 4.4.0

Hello!

We are proud to announce version 4.4.0 of the Authoritative Server.

This release drops GSS/TSIG support, please see PowerDNS Security Advisory 2020-06.

As of now, versions 4.1.x and older are End Of Life.

Version 4.4.0 brings a bunch of exciting changes:

  • the LMDB backend now supports long record content, making it production ready for everybody
  • the SVCB and HTTPS record types are supported, with limited additional processing
  • transaction handling in the 2136 handler and the HTTP API was again improved a lot, avoiding various spurious issues users may have noticed if they do a lot of changes
  • a new setting (consistent-backends) offers a roughly 30% speedup, subject to conditions
  • we finally emit Prometheus metrics!

Authoritative 4.3.x was the last release branch with support for CentOS/RHEL 6. Problems running Authoritative 4.4.x on CentOS/RHEL 6 will not be treated as bugs by us.

We want to specifically thank Robin Geuze, Kees Monshouwer, Mischan Toosarani-Hausberger, Chris Hofstaedtler, and Kevin Fleming for their contributions to this release. We are also grateful to all other reporters of bugs, issues, feature requests, and submitters of smaller fixes and features.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 7 and 8, Debian Buster, Ubuntu Bionic and Focal are available from repo.powerdns.com.

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.4.2 Released

Hello!

Today we are releasing PowerDNS Recursor 4.4.2.

This release fixes a bug where the wrong type could be used while verifying DNSSEC signatures, causing domains to be incorrectly marked as Bogus. Additionally, the recursor no longer resolves unneeded names when chasing CNAME records if QName Minimization is enabled. The recursor now also logs more detailed information if a name is found to be Bogus during DNSSEC validation.

As usual, there were also other smaller enhancements and bugfixes. Please refer to the 4.4.2 changelog  for details.

The 4.4.2 tarball (signature) is available at downloads.powerdns.com and packages for CentOS 7 and 8, Debian Stretch and Buster, Ubuntu Xenial, Bionic and Focal are available from repo.powerdns.com.

4.1 and older releases are EOL, refer to the documentation for details about our release cycles.

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

First Release Candidate for Authoritative 4.4.0

Hello!

This is the first Release Candidate for version 4.4.0 of the Authoritative Server.
If no trouble surfaces, we will release the actual 4.4.0 within a few weeks.

This release drops GSS/TSIG support, please see PowerDNS Security Advisory 2020-06.

Version 4.4.0 brings a bunch of exciting changes:

  • the LMDB backend now supports long record content, making it production ready for everybody
  • the SVCB and HTTPS record types are supported, with limited additional processing
  • transaction handling in the 2136 handler and the HTTP API was again improved a lot, avoiding various spurious issues users may have noticed if they do a lot of changes
  • a new setting (consistent-backends) offers a roughly 30% speedup, subject to conditions
  • we finally emit Prometheus metrics!

Authoritative 4.3.x was the last release branch with support for CentOS/RHEL 6. Problems running Authoritative 4.4.x on CentOS/RHEL 6 will not be treated as bugs by us.

We want to specifically thank Robin Geuze, Kees Monshouwer, Mischan Toosarani-Hausberger, Chris Hofstaedtler, and Kevin Fleming for their contributions to this release. We are also grateful to all other reporters of bugs, issues, feature requests, and submitters of smaller fixes and features.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 7 and 8, Debian Stretch and Buster, Ubuntu Xenial, Bionic and Focal are available from repo.powerdns.com.

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

Goodbye DNS, Goodbye PowerDNS!

After over 20 years of DNS and PowerDNS, I am moving on. Separate from this page, I am releasing a series of three huge posts on the history of PowerDNS, so I won’t dwell too much on that here.

This is not an easy story to write. I don’t like to grandstand, but when the founder of a project decides to leave after two decades, people do expect some form of an explanation.

It is also customary to describe such an exit in upbeat terms, sometimes to the point that you wonder that if things were so great, why is this person leaving?

But the reality is, I got bored and wanted to do new things. PowerDNS and the wonderful people who I met along the way have taught me so much – software development, operations, marketing, sales, business development, community building, writing internet standards & much more. It has been a wonderful ride.

But now it appears DNS and I are somewhat at the end of our relationship (even though I will remain a minor PowerDNS shareholder). Formally I leave on December 31st.

Helping build PowerDNS to what it is today – a flourishing department of Open-Xchange, able to fund itself by delivering its software to paying users, while maintaining good relations with the open source community, has been an incredible honour. 

As I leave the company, management and software development have long been in the hands of people I am proud to call my successors. They are doing a better job than I ever did – the only claim I have on the current success is that I helped recruit this next generation. I don’t think there is much more to aspire to when you create a company than leaving it behind in good shape.

(please do read on till the end of this post for the Oscar-speech round of thanks!)

Some observations

A few years ago, I became somewhat upset with DNS. This is not the main reason for quitting the profession, but now that I have your attention for one final time I do want to take one last stand on two important issues.

In 2018 I did a talk over at the IETF on the ever increasing size of the combined set of DNS specifications – I had looked through the upcoming work from the various standards groups. I plotted the amount of text involved, and also extended this to the historical beginnings of DNS. And it turned out that DNS was growing at one page every two days – without getting any better. I titled this talk “The DNS Camel”, and I wondered if just one more standard might break the back of the protocol.

Many listeners were sympathetic to this story, but also, nothing happened. The protocol just continued to grow. There was the legitimate question if I could please do more than complain. My main worry was that DNS would become even more inaccessible than it was already. I launched the ‘Hello DNS’ project to create a unified point to start learning about this protocol. I think that helped.

But I still fervently believe DNS is getting way, way too big. Not only does this make our software ever more complicated, it is also ever harder for new people to enter the field. You just don’t get all this *stuff* without half a decade of experience. This will lead to dangerous bugs but it also means we’ll miss out on younger talent that has not yet had the chance to incorporate the wisdom we’ve been imparting via the many RFCs we write each year.

And I think I am not alone in believing this – as I type this I am surrounded by no less than 4 (tiny) camels that people sent me as gifts (thanks!). 

DNS and the Cloud

Later, I saw that there was a push for “the cloud” to take over yet another part of our Internet. Encrypted DNS is great, we should all do far more of that. But I was (and am) tremendously unhappy that more and more of DNS is now set to move to (among others) Google and Cloudflare control – both of whom protest that they have nothing but the best intentions. But still I see yet more of the Internet getting centralised, and I worry where that will go

I also worry that people somehow are not worrying about this – somehow we’ve made peace with the fact that companies far away get very detailed records on everything we do online, and that we just have to live with that.

Together with Open-Xchange we spent two years spreading the word on centralised DNS over HTTPS, and I do hope we have made people think about this wisdom of moving DNS to centralised third parties.

A round of thanks and appreciations

To end on a happier note – I want to thank the PowerDNS people for the tremendous job they are doing. Already more than a year ago I started removing myself from more and more discussions, and the way you are running the business fills me with pride.

I want to thank the many people who believed in PowerDNS, who believed in me and worked with our technology, sometimes long before it was ready for prime time. You truly helped shape the product. I am very grateful for the people that decided to work with and for us, even when we did not look like much of a normal company. And of course, so much of PowerDNS actually came from the open source community, including key and core components. I can’t thank the contributors enough. 

One area of special pride is how we enabled a number of PowerDNS contributors & consultants to grow their own business or to enhance their own career. It is wonderful to see how we’ve been able to help each other get ahead in life, while doing useful things.

I also want to thank Open-Xchange (the PowerDNS parent company) for taking such good care of the company. As noted in the PowerDNS history posts, OX took in PowerDNS at a time where business was good, but the future was highly uncertain. Rafael and crew believed in the story and acquired the company. 

Open-Xchange provided a powerful sales organization, but also a rock solid project department that helped actually close deals and to deliver working solutions over at complicated customers.

It is very rare for acquisitions to be truly successful, but PowerDNS and Open-Xchange really are better together. Using the skills from both companies, PowerDNS expanded into the PowerDNS Platform that delivers the solutions that large scale internet operators need and can use.

I wish everyone the best of luck, and I sincerely hope PowerDNS continues to be a place where people love to work and that it continues to be a force that helps improve the open internet!

Signing off – 

Bert Hubert – PowerDNS co-founder (a title no one will ever take away from me!)

PowerDNS Recursor 4.4.1 and 4.3.6 Released

Hello!,

Today we are releasing PowerDNS Recursor 4.4.1 and 4.3.6.

These releases fix a bug where a reply from an authoritative server could get lost, causing timeouts or ServFail answers to clients. Additionally, an issue resolving CNAMEs of the form a.b.c CNAME x.a.b.c when QName Minimization is enabled was fixed.

As usual, there were also other smaller enhancements and bugfixes. Please refer to the 4.4.1 changelog and 4.3.6 changelog for details.

The 4.4.1 tarball (signature), 4.3.6 tarball (signature) are available at downloads.powerdns.com and packages for CentOS 7 and 8, Debian Stretch and Buster, Ubuntu Xenial, Bionic and Focal are available from repo.powerdns.com.

4.1 and older releases are EOL, refer to the documentation for details about our release cycles.

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

Authoritative 4.4.0-beta1

Hello!

we are very happy to announce version 4.4.0-beta1 of the Authoritative Server.

This release drops GSS/TSIG support, please see PowerDNS Security Advisory 2020-06.

Version 4.4.0 brings a bunch of exciting changes:

  • the LMDB backend now supports long record content, making it production ready for everybody
  • the SVCB and HTTPS record types are supported, with limited additional processing
  • transaction handling in the 2136 handler and the HTTP API was again improved a lot, avoiding various spurious issues users may have noticed if they do a lot of changes
  • a new setting (consistent-backends) offers a roughly 30% speedup, subject to conditions
  • we finally emit Prometheus metrics!

Authoritative 4.3.x was the last release branch with support for CentOS/RHEL 6. Problems running Authoritative 4.4.x on CentOS/RHEL 6 will not be treated as bugs by us.

We want to specifically thank Robin Geuze, Kees Monshouwer, Mischan Toosarani-Hausberger, Chris Hofstaedtler, and Kevin Fleming for their contributions to this release. We are also grateful to all other reporters of bugs, issues, feature requests, and submitters of smaller fixes and features.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 7 and 8, Debian Stretch and Buster, Ubuntu Xenial, Bionic and Focal are available from repo.powerdns.com.

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