递归解析器安全审计

01 · 解析器在链路中的定位

DNS 查询链路为 Stub 解析器（终端）→ 递归解析器 → 权威服务器。递归解析器代终端向多级权威迭代查询并缓存结果，是用户实际"信任的解析端点"。因此它同时承担两类安全职责：①对内——为终端提供正确、经过验证的应答（对应子课题01的H-3递归层劫持、子课题02的DNSSEC验证）；②对外——不当配置会使其成为放大攻击的"反射源"，危害互联网整体可用性（对应子课题06的韧性）。

02 · 开放解析器与放大攻击防护

开放解析器（Open Resolver）指接受任意来源递归查询的解析器。配置不当的开放解析器是 DNS 反射/放大攻击（DNS Reflection/Amplification，DrDoS） 的主要载体：攻击者伪造受害 IP 发起大量查询，解析器将大体积应答反射给受害方，放大比可达数十倍。DNS 是 US-CERT/CISA 持续预警的常见 UDP 放大向量：TA13-088A 专项告警与 TA14-017A 的带宽放大因子（BAF）清单均将其列入，实测 BAF 约 28—54 倍。

• 收敛递归权限：仅对授权网络（内网/客户网段）开放递归，对外部仅提供权威应答——这是降低开放解析器数量的根本措施。
• 响应速率限制（RRL, Response Rate Limiting）：对近似相同的应答实施限速，抑制放大与滥用；RRL 机制由 ISC 以规范草案公开（draft-jabley-dnsext-rate-limiting，未成为正式 RFC，属事实标准），BIND 等主流软件已内置。
• 禁用/限制 ANY 查询与大载荷：关闭递归、限制EDNS UDP 载荷、配合 BCP38（入口过滤）减少源地址伪造空间。

03 · 缓存与验证安全

递归解析器的缓存正确性直接决定终端拿到的答案是否被篡改，是子课题01"缓存投毒"（H-5）与子课题02"DNSSEC 验证"的交汇点。

• 源端口随机化 + 0x20 编码：提升事务 ID/端口的熵，抵御 Kaminsky 式盲猜投毒（见子课题01第3页）；属"缓解"而非"根因防护"。
• 强制 DNSSEC 验证：开启 validate（Unbound）或 dnssec-validation yes（BIND），对失验域名返回 SERVFAIL，从根上阻断对签名域的投毒（子课题02）。
• 缓存中毒面收敛：限制每查询接受的附加/授权记录数，启用最小 TTL 上限与缓存清扫，防止投毒记录长驻。

04 · 查询隐私与转发信任链

• 上行转发器信任：企业/内网解析器常把查询转发给上游（如运营商或公共解析）。需明确"转发即把查询内容交给对方"，审计上游是否支持 DoT/DoH 与 DNSSEC 验证，避免在上游发生劫持（H-3）或隐私泄露。
• 查询日志与合规：开启 query logging 可支撑检测（子课题05），但 DNS 查询含 PII 倾向，须按《个人信息保护法》《数据安全法》最小化留存、脱敏与访问控制。
• 加密上行：解析器↔上游优先走 DoT/DoH（子课题03），降低链路监听与抢答篡改面。

05 · 运维与漏洞审计

解析器软件自身漏洞会直接转化为劫持/投毒面，审计须覆盖版本、配置与补丁。

• 版本与补丁：跟踪 BIND/ISC、Unbound(NLnet Labs)、Knot Resolver、dnsmasq 的安全公告；例如 dnsmasq 曾集中披露多项漏洞（CERT/CC VU#973527，CVE-2017-14491 等），须及时升级。
• 配置基线：对照 NIST SP 800-81《Secure DNS Deployment Guide》与厂商安全模板（如 Team Cymru/ISC 安全配置），关闭版本暴露、限制递归、开启 DNSSEC 验证与 RRL。
• 监控与回退：解析器健康（解析成功率、延迟、SERVFAIL 率）纳入可观测性；多上游+健康探测实现自动回退（呼应子课题06客户端韧性）。

参考来源