PowerDNS Authoritative Server 4.5.0-beta1

Hello!

Today we released the first Beta version for Authoritative Server version 4.5.0.

Version 4.5.0 mostly brings small improvements and fixes, but there is one notable new feature: the zone cache.

The zone cache allows PowerDNS to keep a list of zones in memory, updated periodically. With this cache, PowerDNS can avoid hitting the database with queries for unknown domains. In some setups, and some attack scenarios, this can make a serious performance difference.

In beta1, the zone cache is enabled by default.

A full list of changes can be found in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

With version 4.5.0, support for platforms with a time_t type smaller than 64 bits is dropped. This means that we do not build packages for Raspberry Pi OS.

The tarball (signature) is available at downloads.powerdns.com. Packages for various distributions 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.4 and 4.5.2 Released

We are proud to announce the release of PowerDNS Recursor 4.4.4. and 4.5.2. Both releases contain mostly smaller bug fixes. For the 4.5.2 release the default value of nsec3-max-iterations has  been lowered to 150, in accordance with new guidelines and in coordination with other vendors. Furthermore, an issue affecting the “refresh almost expired” function has been fixed.

Please refer to the change logs for the 4.4.4 and 4.5.2 release 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 tarballs (4.4.4, 4.5.2) and signatures (4.4.4, 4.5.2) are available from our download server and packages for several distributions are available from our repository.

With the previous 4.5.1 release, the 4.2.x releases will be EOL and the 4.3.x and 4.4.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to announce that with this release we will stop supporting systems using 32-bit time. This includes 32-bit Linux platforms like arm6, arm7, and i386.

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

DNS cache snooping attack

We have been getting questions about “DNS Server Cache Snooping Remote Information Disclosure” attacks lately, mostly coming from reports generated by one very popular security scanner:

DNS Server Cache Snooping Remote Information Disclosure

Synopsis:
The remote DNS server is vulnerable to cache snooping attacks.

Description:
The remote DNS server responds to queries for third-party domains that do not have the recursion bit set.
This may allow a remote attacker to determine which domains have recently been resolved via this name server, and therefore which hosts have been recently visited.
For instance, if an attacker was interested in whether your company utilizes the online services of a particular financial institution, they would be able to use this attack to build a statistical model regarding company usage of that financial institution.
Of course, the attack can also be used to find B2B partners, web-surfing patterns, external mail servers, and more.

Note: If this is an internal DNS server not accessible to outside networks, attacks would be limited to the internal network.

This may include employees, consultants and potentially users on a guest network or WiFi connection if supported.

Risk factor:
Medium

CVSS Base Score:
5.0

CVSS2#AV:
N/AC:L/Au:N/C:P/I:N/A:N

See also:
http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf

Solution:
Contact the vendor of the DNS software for a fix.

So what is this about?

The idea behind this “attack” is to find out whether a given recursive DNS server has been asked to resolve a given domain name recently. This might in theory be used by an authorized user to know which domains would be worth targeting for mis-typing attacks.

It cannot, however, be used to get the whole content of the cache since one needs to know which domains to query, and of course can’t be used either to know who requested that domain.

How does this work?

It works by exploiting the fact that DNS resolvers do not perform actual resolution for every query they get, instead they all rely on one or several caches, allowing them to remember the responses they have recently received for a certain time, up to the “TTL” value of the response. So if we can determine that a given domain is in the cache, we know that it was queried at most “TTL” seconds ago.

The easiest way to determine if a recursive server has a given domain in cache is to ask: sending a DNS query with the recursion desired bit cleared (RD=0) will only return results from the resolver cache, as per RFC 1034. If information is available about the requested name and type, it is returned, otherwise an empty ‘No Error’ answer is sent.

Should the server refuse to answer these queries, it is also possible to know whether an answer comes from the cache by looking at the TTL returned by the recursive server for a RD=1 request, and comparing it to the original TTL returned by a name server authoritative for that domain. If the TTL returned by the recursor is equal to the one returned by the authoritative server, it was likely not in cache, or was cached less than a second ago. Otherwise it comes from the recursor cache.

We could also precisely measure the time taken by the server to respond, since in the absence of a cached answer the recursive server would have to contact an authoritative server over the network, likely increasing the response time by several milliseconds.

Why does the Recursion Desired feature exist in the first place?

That feature is an integral part of the DNS protocol, as described in RFC 1034, in particular for communication between a recursive server and an authoritative server, where recursion is indeed not desired. As some servers historically provided both authoritative and recursive services, it still makes sense today to be able to distinguish the client’s expectations and to advertise the server capabilities.

It should also be noted that it is extremely useful to be able to use RD=0 queries to remotely inspect the content of the cache for a given name when troubleshooting operational issues in production. The alternative would require connecting to the running recursor process using rec_control and dumping the whole cache.

Mitigations

The first method might be mitigated by refusing RD=0 queries, for example using dnsdist:

addAction(NotRule(RDRule()), RCodeAction(DNSRCode.REFUSED))

It might however break existing clients and setups, since the RD=0 behaviour has been relied on for decades. Moreover, there is no way to mitigate the second and third ones without violating fundamental DNS specifications and impacting performance.

Therefore our recommendation is to simply ignore this “issue”, since there is no clear threat-model where it is actually relevant. This is also the conclusion that the fine folks of ISC reached regarding their BIND DNS server.

PowerDNS Authoritative Server 4.5.0-alpha1

Hello!

Today we released the first Alpha version for Authoritative Server version 4.5.0.

Version 4.5.0 mostly brings small improvements and fixes, but there is one notable new feature: the zone cache.

The zone cache allows PowerDNS to keep a list of zones in memory, updated periodically. With this cache, PowerDNS can avoid hitting the database with queries for unknown domains. In some setups, and some attack scenarios, this can make a serious performance difference.

A full list of changes can be found in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

With version 4.5.0, support for platforms with a time_t type smaller than 64 bits is dropped. This means that we do not build packages for Raspberry Pi OS.

The tarball (signature) is available at downloads.powerdns.com. Packages for various distributions 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.5.1 Released

We are proud to announce the release of PowerDNS Recursor 4.5.1. Compared to the release candidate, this release contains two bug fixes. Note that 4.5.0 was never released publicly, since an issue was found during QA.

Compared to the previous major (4.4) release of PowerDNS Recursor, this release contains a rewrite of the way zone cuts are determined, reducing the number of outgoing queries by up to 17% when doing DNSSEC validation while reducing the CPU usage more than 20% .

Another notable feature is the implementation of EDNS0 padding (RFC 7830) for answers sent to clients.

This 4.5.1 release includes an important addition: the implementation of RFC 8198: Aggressive use of DNSSEC-Validated Cache. This enables the Recursor to answer queries for non-existing names with less effort in many cases. This feature uses both NSEC and NSEC3 records. Additionally the DNSSEC default mode is now “process”, while it was “process-no-validate” before. This means that clients asking for it will get DNSSEC validated answers by default.

We also added a cache of non-resolving nameservers. This enhances performance when the Recursor encounters domains that list nameservers that do not resolve and further mitigates the TsuNAME vulnerability.

This release also 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 protobuf 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.
  • The spoof-nearmiss-max setting‘s default has been changed to 1. This has the consequence that the Recursor will switch to do TCP queries to authoritative nameservers sooner as an effective measure against many spoofing attacks.
  • Incoming queries over TCP now also use the packet cache, providing another performance increase.
  • File written to by the rec_control command are new opened by the command itself. It is also possible to write the content to the standard output stream by using a hyphen as file name.
  • TCP FastOpen (RFC 7413) support for outgoing TCP connections to authoritative servers and forwarders.

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 several distributions are available from our repository.

With this 4.5.1 release, the 4.2.x releases will be EOL and the 4.3.x and 4.4.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to announce that with this release we will stop supporting systems using 32-bit time. This includes 32-bit Linux platforms like arm6, arm7, and i386.

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

dnsdist 1.6.0 released

Hello!

We are proud to announce the final release of dnsdist 1.6.0, with no changes since the second release candidate. Compared to 1.5.x, 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 be 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.

The memory usage of idle DNS over HTTPS and DNS over TLS connections has also been significantly reduced when the OpenSSL provider is used.

If you are upgrading from a previous version, 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.

The release tarball (signature) is 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 this release, the 1.3.x releases are EOL and the 1.4.x releases 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, Stéphane Bortzmeyer, Georgeto, Matti Hiljanen, Andreas Jakum, Nuitari, Oli Schacher, Sukhbir Singh, Thibmac and Mischan Toosarani-Hausberger!

dnsdist 1.5.2 released

Hello!

We are happy to release dnsdist 1.5.2 today, a maintenance release fixing a few bugs reported since 1.5.1:

  • A typo in prometheus metrics dnsdist_frontend_tlshandshakefailures #9728 (AppliedPrivacy)
  • A hang when removing a server with more than one socket
  • SNI availability on resumed sessions, by acknowledging the name sent by the client
  • A crash when a DoH responses map is updated at runtime
  • Dynamic Block RCode rules messing up the queries count
  • EDNS in ServFail generated when no server is available
  • A crash with DynBPF objects in client mode
  • Add missing getEDNSOptions and getDO bindings for DNSResponse

As usual there were also other smaller enhancements and fixes, 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.

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

The release tarball (signature) is available on the downloads website, and packages for CentOS 7 and 8, Debian Buster and Ubuntu Bionic and Focal are available from our repository.

TsuNAME vulnerability and PowerDNS Recursor

Recently, the TsuNAME vulnerability was published. It concerns DNS recursors endlessly querying authoritative nameservers if the nameservers listed in the domains form a loop.

The researchers contacted us before publication, and we established then that while a very old version of PowerDNS recursor was found to be looping, all version of PowerDNS Recursor since 4.0 are not affected. Note that PowerDNS Recursor versions prior to 4.2 are End Of Life. For details, consult our EOL policy page.

While not looping endlessly, PowerDNS does issue more queries than strictly necessary while encountering a nameserver loop, so we decided to implement a further mitigation of the issue. This mechanism, (the non-resolving nameserver cache) will be available and enabled by default in the upcoming PowerDNS Recursor 4.5 release.

Actions for system administrators running PowerDNS Recursor

Make sure you run a supported version of PowerDNS Recursor. Currently this means version 4.2.5, 4.3.7, 4.4.3 or newer. Note that some distributions ship unsupported versions of PowerDNS recursor. This is something out of our control, but for popular distributions you can install the latest supported version from our repository.

Second release candidate for dnsdist 1.6.0

Hi everyone,

We are happy to announce the second release candidate of what should become dnsdist 1.6.0. This release contains very few changes since the first release candidate, and thanks to the great feedback we received on previous versions we expect to be able to release 1.6.0 final very soon. The changed bits since -rc1 are:

  • Only use eBPF for “drop” actions, and clean up the eBPF rules more often
  • Fix missing locks in DNSCrypt certificates management
  • Make the backend queryLoad and dropRate values atomic

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.

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

The release tarball (signature) is 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.

First Release Candidate of PowerDNS Recursor 4.5.0

Hello!,

We are proud to announce the first release candidate of what should become PowerDNS Recursor 4.5.0. Compared to the last beta release, this release contains a few minor bug fixes and improvements.

Compared to the previous major (4.4) release of PowerDNS Recursor, this release contains a rewrite of the way zone cuts are determined, reducing the number of outgoing queries by up to 17% when doing DNSSEC validation while reducing the CPU usage more than 20% . This is a rather substantial change and we would be very grateful for tests and feedback from the community.

Another notable feature is the implementation of EDNS0 padding (RFC 7830) for answers sent to clients.

The upcoming 4.5.0 release includes an important addition: the implementation of RFC 8198: Aggressive use of DNSSEC-Validated Cache. This enables the Recursor to answer queries for non-existing names with less effort in many cases. This feature uses both NSEC and NSEC3 records. Additionally the DNSSEC default mode is now “process”, while it was “process-no-validate” before. This means that clients asking for it will get DNSSEC validated answers by default.

We also added a cache of non-resolving nameservers. This enhances performance when the Recursor encounters domains that have nameservers that do not resolve.

This release also 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 protobuf 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.
  • The spoof-nearmiss-max setting‘s default has been changed to 1. This has the consequence that the Recursor will switch to do TCP queries to authoritative nameservers sooner as an effective measure against many spoofing attacks.
  • Incoming queries over TCP now also use the packet cache, providing another performance increase.
  • File written to by the rec_control command are new opened by the command itself. It is also possible to write the content to the standard output stream by using a hyphen as file name.
  • TCP FastOpen (RFC 7413) support for outgoing TCP connections to authoritative servers and forwarders.

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 several distributions 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 and 4.4.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to announce that with this release we will stop supporting systems using 32-bit time. This includes 32-bit Linux platforms like arm and i386.

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