Debian DSA-6045: a poisoned resolver can also break DNSSEC
Debian issued DSA-6045-1 for pdns-recursor, fixing CVE-2026-52690 and related issues. An attacker can forge answers so the resolver marks an authoritative server as EDNS-incapable, which makes DNSSEC validation fail.
Figure: Debian package tracker for pdns-recursor (source: security-tracker.debian.org, captured 2026-10-19)
A recursive resolver is the part of DNS that walks from the root to the answer. If you can control what it believes about a server, you can control what it believes about a name.
The two CVEs
CVE-2026-52690: forged replies can make the resolver mark an authoritative server as not supporting EDNS. Once that mark is set, the resolver stops expecting DNSSEC records from it, and validation can be skipped. CVE-2026-52688 is a related wildcard validation issue fixed in the same batch.
Why it is worse than ordinary cache poisoning
Cache poisoning makes one name wrong. This makes the resolver distrust DNSSEC for a server, so every name under it is affected.
Debian status
| Release | Fixed version |
|---|---|
| bookworm | 4.8.8-1+deb12u1 |
| trixie | 5.2.13-0+deb13u1 |
| sid | 5.4.6-2 |
Verify after upgrading
dig +dnssec example.com @127.0.0.1
dig +edns=0 example.com @127.0.0.1Check that the AD flag appears where it should and that EDNS fallback is not permanent.
Forwarders are affected too
A forwarder that caches the “no EDNS” conclusion passes it downstream. Restart or flush caches after upgrading.
History
DNS cache poisoning is one of the oldest attacks on the internet. Each generation fixes one path and finds another.
EDNS and DNSSEC
EDNS carries larger responses and the DO bit; DNSSEC needs those records. If a resolver decides a server cannot do EDNS, it cannot validate.
Hardening checklist
- Upgrade and restart.
- Do not forward to untrusted resolvers.
- Monitor for repeated EDNS fallback.
- Keep DNSSEC validation on and alert on failures.
Verification script
Query a signed name, check the AD bit, then query with a small buffer to force EDNS fallback and confirm the resolver recovers.
Common mistakes
- Upgrading without restarting the daemon.
- Assuming DNSSEC means the resolver is trustworthy.
- Ignoring forwarder caches.
My take
DNSSEC protects against forged data, not against a resolver that has been convinced to stop checking. Patch, restart, and watch for fallback.
Comments
…