Debian DSA-6045：递归解析器被污染，DNSSEC 也会失效

图：Debian 跟踪页上 pdns-recursor 的版本与未修复 CVE 列表（来源：security-tracker.debian.org，截图于 2026-10-19）

Debian 在 10 月给 pdns-recursor 发了 DSA-6045-1。这个包不算家喻户晓，但它在很多基础设施里是“DNS 的出口”——所有递归查询都从它走。它出问题，影响的是整条解析链。

先弄清楚 recursor 是什么

DNS 体系里有两类服务器：

权威服务器（authoritative）：持有某个域名的真实记录，回答“example.com 的 A 记录是什么”；
递归解析器（recursor）：替客户端跑腿，从根开始一路问下去，把结果缓存起来。

PowerDNS Recursor 属于第二类。你配置的 8.8.8.8、1.1.1.1 是公共递归，自建环境里常见的则是 unbound、BIND、pdns-recursor。

递归解析器的缓存是它的价值，也是它的攻击面。缓存一旦被污染，所有用它的人都会拿到错误答案，而且会持续到 TTL 过期。

这次的两个 CVE

图：CVE-2026-52690 在 Debian 跟踪页的描述：伪造应答让解析器误判权威服务器不支持 EDNS（来源：security-tracker.debian.org，截图于 2026-10-19）

图：CVE-2026-52690 在 Debian 跟踪页的描述：伪造应答让解析器误判权威服务器不支持 EDNS（来源：security-tracker.debian.org，截图于 2026-10-19）

Debian tracker 上，DSA-6045-1 对应两个编号，其中 CVE-2026-52690 的描述很具体：

Spoofing replies to Recursor might mark an IP of an authoritative server as not supporting EDNS, causing validation of DNSSEC records served by that server to fail.

翻译一下：攻击者伪造应答，让递归解析器认为某个权威服务器“不支持 EDNS”。EDNS 是 DNSSEC 的载体——如果解析器相信对方不支持 EDNS，它就不会去取 DNSSEC 记录，也就不会校验签名。结果就是：本该被 DNSSEC 保护的域名，校验被静默跳过。

另一个 CVE-2026-52688 属于同一批缓存污染问题，Debian tracker 显示 trixie 已修复。两个洞的利用前提类似：攻击者要能向 recursor 发送伪造的 DNS 应答，或者处在能嗅探/注入的位置。

为什么这比“普通缓存污染”更麻烦

图：同批修复的 CVE-2026-52688 条目（来源：security-tracker.debian.org，截图于 2026-10-19）

图：同批修复的 CVE-2026-52688 条目（来源：security-tracker.debian.org，截图于 2026-10-19）

普通缓存污染，你至少还能靠 DNSSEC 兜底：即使缓存里是假记录，校验签名对不上，解析器会拒绝。

这次的攻击直接打掉了兜底逻辑：它不是伪造一条记录，而是让解析器不再校验。这相当于把门锁拆了，而不是配一把假钥匙。

更隐蔽的是，它污染的是“权威服务器能力”的缓存，不是具体的 A 记录。这种状态可能被缓存很久，而且不会在普通的 DNS 查询日志里留下明显痕迹。

Debian 的修复状态

图：PowerDNS Recursor 官方文档首页，升级前先对照配置项变化（来源：doc.powerdns.com，截图于 2026-10-19）

图：PowerDNS Recursor 官方文档首页，升级前先对照配置项变化（来源：doc.powerdns.com，截图于 2026-10-19）

发行版	修复版本	备注
bookworm	4.8.8-1+deb12u1	稳定版安全更新
trixie	5.2.13-0+deb13u1	当前稳定版
forky / sid	5.4.6-2	开发版

升级：

sudo apt update
sudo apt install --only-upgrade pdns-recursor
sudo systemctl restart pdns-recursor

如果跑的是容器镜像，注意镜像里的版本；如果 recursor 是给内网用的，升级前确认配置兼容——5.x 和 4.x 的配置项有差异，跨大版本升级要先看 release notes。

升级后怎么验证

先看版本：

pdns_recursor --version

再确认 DNSSEC 校验在工作：

dig +dnssec +multi cloudflare.com @127.0.0.1

返回里应该有 RRSIG 记录，status 是 NOERROR。如果解析器把 AD 标志去掉了，说明校验没生效，要检查 dnssec 配置和信任锚。

还可以用 delv 或 dig +sigchase 做更严格的验证。生产环境建议加监控：对几个已知支持 DNSSEC 的域名做定时探测，校验 AD 标志，异常就告警。

一个容易忽略的点：转发器也会中招

很多环境不是让 recursor 直接递归，而是转发到上游 DNS。这种情况下，如果上游被污染，你的 recursor 只是把污染结果缓存下来，补丁救不了你。

所以除了升级，还要确认上游的可靠性：用支持 DNSSEC 的上游、开启 dnssec=validate、别把不可信网络里的 DNS 当上游。

DNS 缓存污染的历史

这类攻击不是新东西。2008 年 Kaminsky 发现的那条链，核心就是“在递归解析器缓存里塞假记录”：攻击者抢在真实应答之前，伪造一个 DNS 响应，让解析器把假 IP 缓存下来。当时整个行业紧急打补丁，加上了随机源端口和事务 ID。

之后的攻防基本围绕“如何猜中/绕过随机化”展开。EDNS 的引入扩大了报文空间，也带来了新的解析复杂度；DNSSEC 则试图用密码学校验来兜底。DSA-6045 这类漏洞，打的是“校验逻辑本身”——不是猜不中，而是让你主动放弃校验。

这提醒一件事：随机化、校验、过滤，每一层都是代码，代码就有 bug。DNS 的安全性从来不是某一个机制保证的，而是多层叠加的结果。

EDNS 与 DNSSEC 的关系

简单说：DNSSEC 的签名记录（RRSIG、DNSKEY）体积比普通记录大，传统 DNS 报文装不下，所以需要 EDNS 来扩展 UDP 报文大小。解析器要取 DNSSEC 记录，就得先确认对方支持 EDNS。

攻击者伪造应答，让解析器相信“这个权威服务器不支持 EDNS”，解析器就不会去取签名，自然也不会校验。结果就是：域名看起来正常解析，但 DNSSEC 保护被静默跳过。

这就是为什么这个漏洞比“缓存污染”更严重：它不产生错误答案，而是让安全机制失效。用户看到的是“解析成功”，实际上信任链已经断了。

自建 recursor 的加固清单

除了升级，我会做这几件事：

开启 DNSSEC 校验：dnssec=validate，并配置信任锚；
限制递归来源：只允许内网网段查询，别做开放递归（会被放大攻击利用）；
随机化源端口：确认系统没关掉 net.ipv4.ip_local_port_range 的随机性；
上游选择：转发模式要用可信上游，最好也支持 DNSSEC；
日志与监控：记录 SERVFAIL 和 AD 标志异常，污染攻击往往伴随大量校验失败；
版本跟踪：订阅 Debian 安全公告，别等 apt 提示。

开放递归是 DNS 事故的常见放大器。很多“被 DDoS”的案例，根因是 recursor 对公网开放，被人拿来做反射。加固清单里的第二条，优先级不比打补丁低。

验证脚本

我写了一个小脚本，升级后跑一遍：

#!/usr/bin/env bash
set -euo pipefail
RESOLVER="127.0.0.1"
for domain in cloudflare.com isc.org debian.org; do
  out=$(dig +dnssec +short +time=3 +tries=1 "$domain" @"$RESOLVER" 2>/dev/null || true)
  echo "$domain -> ${out:-FAIL}"
done
dig +dnssec debian.org @"$RESOLVER" | grep -q "flags:.* ad" && echo "DNSSEC OK" || echo "DNSSEC NOT VALIDATED"

脚本不复杂，但能快速回答“解析器是否正常工作、DNSSEC 是否生效”。

常见误区

误区一：“开了 DNSSEC 就安全了”。DNSSEC 防的是“记录被篡改”，前提是解析器真的去校验。这次漏洞让解析器主动跳过校验，DNSSEC 就失效了。开了不等于生效，要验证 AD 标志。

误区二：“升级 recursor 就完事”。如果 recursor 是转发模式，上游被污染一样会中招。升级 + 换可信上游 + 开校验，三件事一起做。

误区三：“DNS 是运维的事，和安全无关”。DNS 是流量的入口，污染 DNS 等于劫持所有请求。把它当安全组件，而不是基础设施。

我的判断

DNS 是互联网最不起眼、也最不能出错的层。它平时安静得像不存在，一旦被污染，表现是“网站打不开”“证书验证失败”“邮件进垃圾箱”——排查半天才发现是解析问题。

DSA-6045 这类漏洞的可怕之处，是它攻击的是“信任链的开关”，而不是某条记录。DNSSEC 的设计假设是“解析器会认真校验”，而这次的问题让解析器主动放弃校验。补丁修的是实现，但提醒的是：任何“降级”逻辑都是攻击面。

对自建 DNS 的人，动作很简单：升级、重启、验证 AD 标志。对普通用户，这件事的启示是：如果你用的网络 DNS 被污染，你看到的“安全网站”可能只是看起来安全。

最后补充一点：DNSSEC 的部署率一直不高，很多域名根本没签名。对没有签名的域名，任何递归解析器都只能“尽力而为”。这也是为什么 DNS 层需要额外的加密（DoH/DoT）和监控——它们不解决签名问题，但能减少链路上被篡改的机会。对自建解析器来说，最实际的一条是：别做开放递归，别用不可信上游，升级后一定重启。这三条做到，大部分 DNS 事故都能挡在门外。DNS 不出事的时候没人注意，出事的时候所有服务一起抖，这就是它值得多花半小时的原因。把 recursor 当核心组件维护，别把它当成装完就忘的附属品。DNS 的稳定性决定了其他一切的上限，把它纳入监控和变更管理，是性价比最高的投入之一，真的，别等它挂掉再说，这不是小题大做，是基本盘。