Security of the PowerDNS Recursor

For Security Advisories, see the dedicated page.

PowerDNS Security Policy

If you have a security problem to report, please email us at both peter.van.dijk@powerdns.com and remi.gacogne@powerdns.com. In case you want to encrypt your report using PGP, please use: https://doc.powerdns.com/powerdns-keyblock.asc

Please do not mail security issues to public lists, nor file a ticket, unless we do not get back to you in a timely manner. We fully credit reporters of security issues, and respond quickly, but please allow us a reasonable timeframe to coordinate a response.

We remind PowerDNS and dnsdist users that under the terms of the GNU General Public License, PowerDNS and dnsdist come with ABSOLUTELY NO WARRANTY. This license is included in this documentation.

If you believe you have found a security vulnerability that applies to DNS implementations generally, and you want to report this responsibly to a number of implementers, you might consider also using the Open Source DNS Vulnerability mailing list, managed by DNS-OARC.

YesWeHack

Security issues can also be reported on our YesWeHack page and might fetch a bounty. Do note that only the PowerDNS software is in scope for the YesWeHack program, not our websites or other infrastructure.

Disclosure Policy

  • Let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly resolve the issue.

  • Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.

  • We will always credit researchers in our Security Advisories.

Anti-spoofing

Recursor uses a fresh UDP source port for each outgoing query, making spoofing around 64000 times harder. This raises the bar from ‘easily doable given some time’ to ‘very hard’. Under some circumstances, ‘some time’ has been measured at 2 seconds. This technique was first used by dnscache by Dan J. Bernstein and is standardized in RFC 5452

In addition, Recursor detects when it is being sent too many unexpected answers, and mistrusts a proper answer if found within a clutch of unexpected ones. When this happens, the query to the authoritative server is retried over TCP.

This behaviour can be tuned using the recursor.spoof_nearmiss_max.

Throttling

Recursor implements a very simple but effective resolver. Care has been taken not to overload remote servers in case of overly active clients.

This is implemented using the ‘throttle’. This accounts all recent traffic and prevents queries that have been sent out recently from going out again.

There are three levels of throttling.

  • If a remote server indicates that it is lame for a zone, the exact question won’t be repeated in the next 60 seconds.

  • After 4 ServFail responses in 60 seconds, the query gets throttled too.

  • 5 timeouts in 20 seconds also lead to query suppression.

Security Polling

PowerDNS products can poll the security status of their respective versions. This polling, naturally, happens over DNS. If the result is that a given version has a security problem, the software will report this at level ‘Error’ during startup, and repeatedly during operations.

By default, security polling happens on the domain ‘secpoll.powerdns.com’, but this can be changed with the security-poll-suffix. If this setting is made empty, no polling will take place. Organizations wanting to host their own security zones can do so by changing this setting to a domain name under their control.

To make this easier, the zone used to host secpoll.powerdns.com is available.

To enable distributors of PowerDNS to signal that they have backported versions, the PACKAGEVERSION compilation-time macro can be used to set a distributor suffix.

Details

PowerDNS software sadly sometimes has critical security bugs. Even though we send out notifications of these via all channels available, we find that not everybody actually finds out about our security releases.

To solve this, PowerDNS software will start polling for security notifications, and log these periodically. Secondly, the security status of the software will be reported using the built-in metrics. This allows operators to poll for the PowerDNS security status and alert on it.

In the implementation of this idea, we have taken the unique role of operating system distributors into account. Specifically, we can deal with backported security fixes.

Finally, this feature can be disabled, or operators can have the automated queries point at their own status service.

Implementation

PowerDNS software periodically tries to resolve ‘auth-x.y.z.security-status.secpoll.powerdns.com|TXT’ or ‘recursor-x.y.z.security-status.secpoll.powerdns.com’.

The data returned is in one of the following forms:

  • NXDOMAIN or resolution failure -> 0

  • “1 Ok” -> 1

  • “2 Upgrade recommended for security reasons, see …” -> 2

  • “3 Upgrade mandatory for security reasons, see …” -> 3

In cases 2 or 3, periodic logging commences. Case 2 can also be issued for non-security related upgrade recommendations for pre-releases. The metric security-status is set to 2 or 3 respectively. If at a later date, resolution fails, the security-status is not reset to 1. It could be lowered however if we discover the security status is less urgent than we thought.

If resolution fails, and the previous security-status was 1, the new security-status becomes 0 (‘no data’). If the security-status was greater than 1, it will remain that way, and not get set to 0.

In this way, security-status of 0 really means ‘no data’, and cannot mask a known problem.

Distributions

Distributions frequently backport security fixes to the PowerDNS versions they ship. This might lead to a version number that is known to us to be insecure to be secure in reality.

To solve this issue, PowerDNS can be compiled with a distribution setting which will move the security polls from: ‘auth-x.y.z.security-status.secpoll.powerdns.com’ to ‘auth-x.y.z-n.debian.security-status.secpoll.powerdns.com.

Note two things, one, there is a separate namespace for debian, and secondly, we use the package version of this release. This allows us to know that 4.0.1-1 (say) is insecure, but that 4.0.1-2 is not.

Configuration Details

The configuration setting security-poll-suffix is by default set to ‘secpoll.powerdns.com’. If empty, nothing is polled. This can be moved to ‘secpoll.yourorganization.com’.

If compiled with PACKAGEVERSION=3.1.6-abcde.debian, queries will be sent to “auth-3.1.6-abcde.debian.security-status.security-poll-suffix”.

Delegation

If a distribution wants to host its own file with version information, we can delegate dist.security-status.secpoll.powerdns.com to their nameservers directly.

Decompression limits on DNS packets

Recursor enforces several limits on pointers while parsing a DNS packet. DNS allows names to use pointers: the tail end of a name is constructed by following a pointer to a name occurring previously in the packet. As names in a packet share suffixes in a lot of cases this allows to save many bytes at the cost of extra work while parsing. For decompressing names, three limits apply to limit the amount of work while parsing a packet:

  • max-pointers-per-packet-byte: a limit for the total number of pointers followed to parse all names in a packet. This limit is 4 * the packet size by default. This seems generous, but it is possible to construct legit DNS packets that approach this limit, as constructing a single name can imply following multiple pointers.

  • max-pointers-to-pointers: a limit to the pointer directly pointing at a pointer cases while decompressing a single name. In this case the first pointer does not add any useful information and could have been replaced by the target pointer. The default value is 4.

  • max-pointers-per-name: a limit to the pointers followed while decompressing a single name. This limits the case where a pointer does not point at another compression pointer directly but adds some bytes followed by a pointer. The default value is 10.

If a limit is reached while parsing a packet, Recursor will act as it normally does for malformed answers received: advance to an alternative authoritative server if available. If no more authoritative server are available the client will receive a ServFail answer.