PowerDNS released Recursor 5.5.0-beta1 on November 11, 2026. For DNS operators, the useful next step is a focused lab comparison with their current resolver. This is a pre-release, and PowerDNS explicitly invites testing of a substantial internal change.
Start with DNSSEC regression tests
The authoritative-answer processing refactor separates DNSSEC work, including proofs that a name or record does not exist, from other response processing. It covers the path from incoming records through validation and caching to the answer returned to clients.
Our suggested priority is correctness before speed. A familiar hostname resolving successfully is a useful smoke test, but insufficient evidence for a resolver change. Include cases where the right result is a rejected answer or a validated negative response.
Three operational details worth checking
The upgrade guide documents an unknown-root-keys metric for a root key-signing key absent from configured trust anchors. The release also adds a warning. Treat that signal as a reason to verify configuration and trusted key information, not as permission to trust an unfamiliar key automatically.
For Response Policy Zones (RPZ), distinguish startup from later changes. Beta1 avoids cache-flush work during initial synchronous loading from a seed or file. The broader 5.5 behavior of clearing relevant packet-cache entries on RPZ reload still matters; the upgrade guide warns that large zones can take time.
The TLS connection-reuse change considers the subject name and configuration as well as existing endpoint information. Operators using outgoing DNS over TLS should include configuration reloads in their tests.
A practical lab checklist
- Save the current configuration and package versions. Create an isolated test resolver and a known-good comparison instance. Define how to discard the experiment before changing anything.
- Use controlled signed and unsigned zones. Compare ordinary answers, aliases, wildcard results, nonexistent names and deliberately invalid signatures. Record response codes and validation results rather than only whether a client receives an address.
- Repeat the same cases with cold and warm caches. Compare the first response with subsequent responses, then repeat after expiry. Investigate unexpected differences before drawing performance conclusions.
- Check that logs and monitoring collect the new root-key signal. Document who investigates it and which trusted source they use. Keep production trust anchors untouched during experiments.
- Exercise RPZ initial loading and a later policy change separately. Confirm that the new policy appears in answers; measure reload duration and query latency using a representative policy-zone size.
- For outgoing TLS, test reconnects and reloads under the configurations you actually use. Capture enough logs to explain failures without retaining credentials or private client-query data.
Keep the release history straight
The versioned changelog places ML-DSA-44 support in alpha2 and outgoing DoT client certificates in alpha1. They belong to the wider 5.5 release, rather than being beta1 introductions.
This checklist is our editorial recommendation, not a completed test report. We have not installed or benchmarked this beta. Document reproducible differences and review the upgrade notes before planning any production change.