PowerDNS Recursor 4.5.12, 4.6.5 and 4.7.4 Released

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.

First Release Candidate of PowerDNS Recursor 4.8.0

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.

PowerDNS Recursor: ZONEMD, the missing validation

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.

FOSDEM 2023 DNS Developer Room Call for Participation

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

Second Beta Release of PowerDNS Recursor 4.8.0

We are proud to announce the second beta 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 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.

dnsdist 1.7.3 released

Hello!

We are very happy to release dnsdist 1.7.3 today, a maintenance release with no functional changes.

This release strictly serves to bring dnsdist packages to our EL9 and Ubuntu Jammy repositories, and upgrades the dnsdist Docker image from Debian buster to Debian bullseye, as buster is officially EOL.

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 and its signature are available on the downloads website, and packages for several distributions are available from our repository.

Authoritative Server 4.7.2

This is the release of version 4.7.2 of the Authoritative Server.

Just one day after releasing version 4.7.1, we realised an important fix was missing from it. Specifically, AXFR clients (secondaries) can get very busy checking for updates on primaries, or could miss updates entirely. 4.7.2 fixes this.

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

Please make sure to read the Upgrade Notes before upgrading.

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.

Authoritative Server 4.7.1

This is the release of version 4.7.1 of the Authoritative Server.

After 4.7.0 (quite recently) was released, we realised the SQL schema update files were missing. 4.7.1 corrects this. It also contains a few small fixes in the catalog zones implementation.

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

Please make sure to read the Upgrade Notes before upgrading.

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.

Authoritative Server 4.7.0

This is the release of version 4.7.0 of the Authoritative Server.

4.7.0 brings support for Catalog Zones, developed by Kees Monshouwer. As part of that development, the freshness checks in the Primary code were reworked, reducing them from doing potentially thousands of SQL queries (if you have thousands of domains) to only a few. Installations with lots of domains will benefit greatly from this, even without using catalog zones.

4.7.0 also brings back GSS-TSIG support, previously removed for quality reasons, now reworked with many stability improvements.

Other things of note:

  • LUA records, when queried over TCP, can now re-use a Lua state, giving a serious performance boost.
  • lmdbbackend databases now get a UUID assigned, making it easy for external software to spot if a database was completely replaced
  • lmdbbackend databases now optionally use random IDs for objects
  • a new LUA function called ifurlextup, and improvements in other LUA record functions
  • autoprimary management in pdnsutil and the HTTP API
  • in beta, a key roller daemon, currently not packaged

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

Please make sure to read the Upgrade Notes before upgrading.

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.

First Beta Release of PowerDNS Recursor 4.8.0

We are proud to announce the first beta 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 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.