We are proud to announce the release of PowerDNS Recursor 4.8.3

This release is a maintenance release. The most important fixes concern the serve-stale functionality which could cause intermittent high CPU load. The serve-stale function is disabled by default.

Please refer to the change log for the 4.8.3 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 tarball and signature are available from our download server and packages for several distributions are available from our repository. The Ubuntu Jammy package will be published soon.

The 4.5.x releases are EOL and the 4.6.x and 4.7.x releases are in critical fixes only mode. Consult the EOL policy for more details.

We would also like to repeat that starting with the 4.5 release branch we stopped supporting systems using 32-bit time. This includes most 32-bit Linux platforms.

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.

We are proud to announce the release of PowerDNS Recursor 4.8.2.

This release is a maintenance release, fixing some issues, in particular:

• Record and negative cache cleaning now maintains balance between shards in a better way
• A case where the wrong EDNS Client Subnet scope could be applied to outgoing queries has been fixed
• A few other minor issues

Please refer to the change log for the 4.8.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 tarball and signature are available from our download server and packages for several distributions are available from our repository. The Ubuntu Jammy package will be published soon.

The 4.5.x releases are EOL and the 4.6.x and 4.7.x releases are in critical fixes only mode. Consult the EOL policy for more details.

We would also like to repeat that starting with the 4.5 release branch we stopped supporting systems using 32-bit time. This includes most 32-bit Linux platforms.

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.

Hello,

Today we have released PowerDNS Recursor 4.8.1 due to a high severity issue found.

Please find the full text of the advisory below.

The changelog is available.

The tarball (signature) is available from our download server. Patches are available at patches. Packages for various distributions are available from our repository.

Note that PowerDNS Recursor 4.5.x and older releases are End of Life. Consult the EOL policy for more details.

---

PowerDNS Security Advisory 2023-01: unbounded recursion results in program termination

• CVE: CVE-2023-22617
• Date: 20th of January 2023
• Affects: PowerDNS Recursor 4.8.0
• Not affected: PowerDNS Recursor < 4.8.0, PowerDNS Recursor 4.8.1
• Severity: High
• Impact: Denial of service
• Exploit: This problem can be triggered by a remote attacker with access to the recursor by querying names from specific mis-configured domains
• Risk of system compromise: None
• Solution: Upgrade to patched version

An issue in the processing of queries for misconfigured domains has been found in PowerDNS Recursor 4.8.0, allowing a remote attacker to crash the recursor by sending a DNS query for one of these domains. The issue happens because the recursor enters a unbounded loop, exceeding its stack memory. Because of the specific way in which this issue happens, we do not believe this issue to be exploitable for code execution.

PowerDNS Recursor versions before 4.8.0 are not affected.

Note that when the PowerDNS Recursor is run inside a supervisor like supervisord or systemd, a crash will lead to an automatic restart, limiting the impact to a somewhat degraded service.

CVSS 3.0 score: 8.2 (High)
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H/E:H/RL:U/RC:C

Thanks to applied-privacy.net for reporting this issue and their assistance in diagnosing it.

This is the sixth part of a series of blog posts we are publishing, mostly around recent developments with respect to PowerDNS Recursor:

• Refreshing Of Almost Expired Records: Keeping The Cache Hot,
• Probing DoT Support of Authoritative Servers: Just Try It,
• Sharing data between threads in PowerDNS Recursor,
• Structured Logging in PowerDNS Recursor and
• ZONEMD, the missing validation.

This post is about how the Recursor can write to files even when its permissions to access the file system are restricted.

When PowerDNS Recursor is running it mostly does not need to access files. In many runtime environments its access to the file system is restricted to limit the impact of potential security issues. When reconfiguring the Recursor, we need to make sure the files it needs to read are accessible in this restricted runtime environment. But in some cases, we also want to be able to write files.

A common case for writing to a file is extracting status information from the Recursor, for example, a dump of the Recursor caches. In older releases, the Recursor would need to have write access to a directory where it could write those dumps. This is not ideal, as this restricted runtime environment might not allow for opening files with write permission and even if it allows writing, we would rather run the Recursor without that ability.

Depending on the runtime environment, the place where files are written may be surprising. For example, using chroot or systemd‘s RuntimeDirectory and PrivateTmp changes the view of the file system from the Recursor’s perspective. As questions asked on IRC and other help channels reveal, this can be confusing and hard to diagnose for a system administrator.

From a general security perspective it is good to restrict a networking daemon to not be able to create and write to files, so how can we solve the problem of where to write the cache dumps?

Passing information between processes

One way would be to dump to information via a socket to a client process. That would involve the Recursor writing to a socket, the client process then reads from the socket and writes the information to a file or pipe.

We chose another approach: file descriptor passing. The main advantage is that this allows the information to be written immediately to a file or pipe without an intermediate networking step transferring the data between the Recursor and a client process. This simplifies the code and avoids work for both the client and the Recursor.

File descriptor passing

File descriptor passing is a technique that can be used between two processes communicating over a local (also know as UNIX) domain socket. The Recursor’s command client program rec_control already uses a local socket to communicate with the Recursor.

When a file, pipe or socket is opened it is assigned a file descriptor by the kernel. The file descriptor is an integer and its scope is per-process. The kernel keeps track of open file descriptors per process and has a mechanism to translate the per process file descriptor to an actual kernel object, which represents the actual file, pipe or socket. File descriptor passing transfers a file descriptor from one process to another while keeping the kernel file object reference the same, only the per-process kernel data are changing: the sending process loses a file descriptor slot while the receiving one gains one.

The effect is that one process can open a file (or other object) for writing and then transfer the file descriptor–which is just a reference–to another process. The second process can then write to the file (or other object) without having the permissions to create or open files for writing itself.

The code to do the actual file descriptor passing is a bit arcane, but well documented. See for example https://www.man7.org/linux/man-pages/man3/cmsg.3.html or http://man.openbsd.org/man3/CMSG_DATA.3.

Consequences for system administrators

The rec_control command was modified to use file descriptor passing with the release of Recursor 4.4.0. From the system administrator’s perspective, the command still looks like this:

rec_control dump-cache cache_dump.txt

The difference is that the cache_dump.txt file will now be created using the credentials and current working directory of the rec_control process and not the credentials and current working directory of the Recursor process. The rec_control command will create the file, pass the file descriptor to the Recursor and wait until the Recursor signals it is done writing. This part of the communication between rec_control and the Recursor did not change.

It now is also possible to let the Recursor write to standard output of the rec_control command:

rec_control dump-cache - | grep some_pattern

Other rec_control subcommands writing files were converted in a similar way.

Conclusion

By using file descriptor passing, we are able to run the Recursor process with more restricted privileges and provide a flexible way to write diagnostic information.

We are proud to announce the release of PowerDNS Recursor 4.8.0.

Compared to the previous major (4.7) release of PowerDNS Recursor, this release contains the following major changes:

• Structured Logging has been implemented for almost all subsystems. This allows for improved (automated) analysis of logging information. We’ve posted a blog about this feature recently.
• Optional Serve Stale functionality has been implemented, providing resilience against connectivity problems towards authoritative servers.
• Optional Record Locking has been implemented, providing an extra layer of protection against spoofing attempts at the price of reduced cache efficiency.
• Internal tables used to track information about authoritative servers are now shared instead of per-thread, resulting in better performance and lower memory usage.
• EDNS padding of outgoing DoT queries has been implemented, providing better privacy protection.
• Metrics have been added about the protobuf and dnstap logging subsystems and the rcodes received from authoritative servers.

As always, there are also many smaller bug fixes and improvements, please refer to the changelog for additional details. When upgrading do not forget to check the upgrade guide.

We are also announcing the removal of XPF support. If you are using this feature, switch to the Proxy Protocol.

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 4.8.0 release, the 4.5.x releases will be marked “End of Life” and the 4.6.x and 4.7.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to mention that with the 4.5 release we stopped supporting systems using 32-bit time. This includes many 32-bit Linux platforms.

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.

Hello,

Today we have released maintenance updates of PowerDNS Authoritative Server 4.5.5, 4.6.4 and 4.7.3, containing fixes for a few minor issues. For more details on the other fixes, consult the changelogs available at 4.5.5, 4.6.4, 4.7.3.

The source tarballs (4.5.5, 4.6.4, 4.7.3) and signatures (4.5.5, 4.6.4, 4.7.3) are available from our download server. Packages for various distributions are available from our repository.

Note that PowerDNS Authoritative Server 4.4.x and older releases are End of Life. Consult the EOL policy for more details.

We would also like to repeat that starting with the 4.5 release branch we stopped supporting systems using 32-bit time. This includes most 32-bit Linux platforms.

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.

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

Hello,

Today we have released a maintenance release of PowerDNS Recursor 4.5.12, 4.6.5 and 4.7.4, containing fixes for a few minor issues. In particular, RPZ IXFRs now time out if the server becomes unresponsive. For more details on the other fixes, consult the changelogs available at 4.5.12, 4.6.5, 4.7.4.

The source tarballs (4.5.12, 4.6.5, 4.7.4) and signatures (4.5.12, 4.6.5, 4.7.4) are available from our download server. Packages for various distributions are available from our repository.

Note that PowerDNS Recursor 4.4.x and older releases are End of Life. Consult the EOL policy for more details.

We would also like to repeat that starting with the 4.5 release branch we stopped supporting systems using 32-bit time. This includes most 32-bit Linux platforms.

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.

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

We are proud to announce the first release candidate of PowerDNS Recursor 4.8.0. We invite all users to test this release candidate, so that we can release the final PowerDNS Recursor 4.8.0 soon.

Compared to the previous major (4.7) release of PowerDNS Recursor, this release contains the following major changes:

• Structured Logging has been implemented for almost all subsystems. This allows for improved (automated) analysis of logging information. We’ve posted a blog about this feature recently.
• Optional Serve Stale functionality has been implemented, providing resilience against connectivity problems towards authoritative servers.
• Optional Record Locking has been implemented, providing an extra layer of protection against spoofing attempts at the price of reduced cache efficiency.
• Internal tables used to track information about authoritative servers are now shared instead of per-thread, resulting in better performance and lower memory usage.
• EDNS padding of outgoing DoT queries has been implemented, providing better privacy protection.
• Metrics have been added about the protobuf and dnstap logging subsystems and the rcodes received from authoritative servers.

As always, there are also many smaller bug fixes and improvements, please refer to the changelog for additional details. When upgrading do not forget to check the upgrade guide.

We are also announcing the removal of XPF support. If you are using this feature, switch to the proxy protocol.

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 final 4.8 release, the 4.5.x releases will be marked “End of Life” and the 4.6.x and 4.7.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to mention that with the 4.5 release we stopped supporting systems using 32-bit time. This includes many 32-bit Linux platforms.

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.

This is the fifth part of a series of blog posts we are publishing, mostly around recent developments with respect to PowerDNS Recursor. The first blog post was Refreshing Of Almost Expired Records: Keeping The Cache Hot, the second Probing DoT Support of Authoritative Servers: Just Try It, the third Sharing data between threads in PowerDNS Recursor and the fourth Structured Logging in PowerDNS Recursor.

ZONEMD is a DNS record type that was introduced quite recently in RFC8976. ZONEMD records are used to validate DNS zone contents. You may ask: why is that needed, as DNSSEC already provides validation? There are several reasons for a independent validation technique that is well-integrated into the zone file format to exist:

1. Not all zones are DNSSEC signed.
2. Even in DNSSEC signed zones, not all records are signed. In particular, delegation and glue records are not signed.
3. The existing TSIG validation method is only used during transfer and only applies to zones being transferred using AXFR or IXFR and requires pre-arranged shared keys. There is no way to TSIG sign a zone on file.
4. PGP or similar signatures on files are file layout dependent and require either separate transfer or a zone file format extension that is unlikely to be generally adopted.

It was decided to define a mechanism to compute a cryptographic digest of the zone data that can easily be incorporated in a zone file because it is a DNS record. For the same reason the digest information can be transferred using either DNS specific zone transfer methods or any other method to transfer a file. The receiver of the zone can then validate the contents of the zone using the digest to detect corruption. If the zone is DNSSEC signed, the receiver can also verify the authenticity of the digest record used to validate the zone contents and, by extension, validate the authenticity of the full zone contents.

ZONEMD

An example ZONEMD record looks like:

example. 86400 IN ZONEMD 2018031900 1 1 8ee54f64ce0d57fd70e1a4811a9ca9e849e2e50cb598edf3ba9c2a58625335c1f966835f0d4338d9f78f557227d63bf6

In order, domain, TTL, class and type are part of every DNS record. 2018031900 is the serial and should correspond to the serial in the SOA record of the zone. The 1 1 are the scheme and hash algorithm which we will not describe here. The hex string is the actual digest. If the software exporting the zone does not know the presentation format for ZONEMD records, it will use the generic format. In that case, the same record will look like:

example. 86400 IN TYPE63 # 54 7848b91c01018ee54f64ce0d57fd70e1a4811a9ca9e849e2e50cb598edf3ba9c2a58625335c1f966835f0d4338d9f78f557227d63bf6

Any software receiving a zone containing a ZONEMD record can validate the digest by ordering all records in wire format in a well defined way (that is also used for DNSSEC), compute the specified cryptographic digest on that data (handling the ZONEMD record in a special way) and then compare the computed digest to the digest specified in the actual ZONEMD record. We will not go into details on how the digest is computed exactly. If you are interested, you can read about it in the RFC mentioned above.

If the zone is DNSSEC signed, the software can also validate the ZONEMD record’s associated RRSIG in the standard way to make sure that the ZONEMD record is authentic. That means the ZONEMD digest is coming from the zone owner. As the ZONEMD digest covers the whole zone data, you can be sure that whole zone is authentic if both the ZONEMD digest and its DNSSEC signature validate properly.

ZONEMD and PowerDNS

With the latest releases, ZONEMD validation is available in two places:

• pdnsutil (part of the PowerDNS Authoritative Server software) can be used to validate ZONEMD digests in zone files only.
• In PowerDNS Recursor ZONEMD validation is implemented when loading zones into the record cache using the zoneToCache function.

With the zoneToCache function, ZONEMD validation happens with all three (axfr, file and url) transfer methods and parameters can be set to ignore, validate (if present) or require ZONEMD validation and DNSSEC validation of the ZONEMD record.

A typical use of zoneToCache is to load the root zone into the cache. At the moment of writing, the root zone file published by internic.net does not include ZONEMD record(s), but in the near future it will. From that moment on, PowerDNS Recursor will perform validation ensuring the retrieved root zone is not corrupted by accident and if DNSSEC is activated it will also ensure the zone contents are authentic.

Future

In the future, we will implement ZONEMD functionality in more places. For PowerDNS Authoritative server that includes validation but also generation of ZONEMD records. For PowerDNS Recursor, future work will include validation of zone transfers and local files used both by RPZs and local authoritative zones.

Conclusion

ZONEMD records provide a way to detect corruption and ensure authenticity of zone data. PowerDNS software is ready to start validating ZONEMD records for specific use-cases, and will do so in more places in the future.

Hello DNS enthusiasts and other developers,

After three earlier successful and packed DNS devrooms at FOSDEM 2018, 2019, and 2020, we are happy to announce a half-day DNS devroom at FOSDEM 2023.

As with the previous events, we hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding or system administrators responsible for DNS infrastructure.

We have been allotted a room on Saturday the 4th of February 2023, from 15:00 to 19:00 (CET).

If you have something you’d like to share with your fellow developers, please head to pentabarf. Examples of topics are measuring, monitoring, DNS libraries, anecdotes on how you’ve (ab)used the DNS, and group discussions of upcoming technologies. For the upcoming technologies, we’re looking for submissions on Applications Doing DNS (ADD), SVCB/HTTPS records and applications thereof, and stub-resolver configuration. Here’s the 2020 schedule, for your inspiration: https://archive.fosdem.org/2020/schedule/track/dns/.

We expect to schedule 30 minutes per talk, including questions, but if you need more or less time, we can discuss this.

The deadline for submissions is December 7th 2022. If you have a FOSDEM Pentabarf account from a previous year, please use that account. Reach out to dns-devroom-manager@fosdem.org if you run into any trouble.

See you there!

Cheers,
The FOSDEM 2023 DNS Devroom organizers