DNSSEC是抵御DNS缓存投毒最根本的技术手段，通过数字签名和全链路验证（权威签名、递归验证、客户端信任根密钥）确保响应真实未篡改，需同步配置ZSK/KSK、DS记录、dnssec-validation及AD标志校验。
防止DNS缓存投毒攻击，核心是让解析过程具备可验证性、可控性和可观测性。单纯靠“更新软件”或“关闭递归”治标不治本，必须从协议层、配置层和运营层协同加固。
DNSSEC 全链路启用
DNSSEC 是抵御缓存投毒最根本的技术手段，它通过数字签名确保 DNS 响应真实未被篡改。但要注意：只在权威服务器上签发不够，递归解析器必须开启验证（DNSSEC validation），客户端也要信任根密钥（如 ISC 的 trust anchor）。
- 权威侧：为域名生成 ZSK/ KSK 密钥，签署 SOA、NS、A、MX 等关键记录，并发布 DS 记录到上级（如 .com 注册局）
- 递归侧：在 BIND / Unbound / CoreDNS 中启用 dnssec-validation auto（BIND）或 dnssec: yes（Unbound），并定期更新 root anchor（如 via
dig . DNSKEY > root.key） - 验证确认：用
dig example.com +dnssec +multi查看响应中是否含 ad（Authenticated Data）标志；无 ad 或 rc=2（SERVFAIL）说明验证失败，需排查签名链或时钟偏差
递归解析器最小化与隔离
开放递归服务器是投毒攻击的温床。企业内网应禁止对外提供递归服务，同时限制内部递归器的查询来源和行为边界。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 关闭公网递归：在防火墙和 DNS 服务配置中明确限制 allow-recursion 仅限内网 IP 段（如
{ 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };） - 启用响应速率限制（RRL）：防伪造响应洪泛，BIND 可配置 rate-limit 和 max-ratelimit 参数抑制异常响应频率
- 禁用非必要记录类型：如停用 ANY 查询（易被用于信息探测），在 named.conf 中设 disable-any yes
采用加密与可信解析通道
明文 DNS（UDP/TCP 53）易被中间人监听或篡改。升级传输层安全性，可大幅提高投毒门槛。
- 部署 DoH（DNS over HTTPS）或 DoT（DNS over TLS）：终端或递归器直连可信解析服务（如 360 安全 DNS 的 101.226.4.6 支持 DoT），避免本地网络劫持
- 内网统一出口：将所有终端 DNS 请求强制转发至企业自建的 DoT/DoH 代理（如 stubby、dnscrypt-proxy），再由该代理向上游递归器发起加密查询
- 验证上游可信度：优先选择具备实时威胁情报能力的公共解析服务（如 360 安全 DNS 融合安全大脑，可拦截恶意域名及 DNS 隧道行为）
监控与快速响应机制
即使做了加固，仍需持续观测异常行为——投毒攻击常伴随响应异常、NODATA 突增、TTL 异常缩短等信号。
- 采集解析日志：记录 client IP、query name、response code、rrset、TTL、flags（含 AD/CD 位）
- 设置基线告警：如某域名 1 小时内 A 记录 TTL 从 3600 秒骤降至 60 秒；或同一 client 连续触发 >5 次 SERVFAIL
- 联动应急流程：发现疑似投毒后，立即清除对应缓存（
rndc flushname example.com），并比对权威服务器原始响应（dig @ns1.example.com example.com A）确认是否一致
