当你的用户访问银行网站，却看到钓鱼页面；当你的业务域名解析到错误的IP，导致服务中断——这些都可能源于DNS缓存污染。攻击者利用DNS协议漏洞，向递归解析器注入伪造的解析记录，使缓存中的域名指向恶意服务器。本文不讨论理论，直接教你如何排查和加固。
先判断：你的DNS缓存是否已被污染？
在动手加固前，先确认问题。你可以使用以下方法检测：
- 对比解析结果：使用不同公共DNS（如8.8.8.8、1.1.1.1）解析同一域名，若结果不一致，怀疑被污染。
- 检查TTL异常：正常记录的TTL通常稳定，若某条记录TTL异常短或异常长，可能被篡改。
- 使用安全工具：如
dig命令查看权威服务器返回，与递归解析结果对比。
但请注意：解析结果不一致也可能是CDN负载均衡的正常现象，需排除。若确认污染，立即清除本地缓存，并联系ISP或管理员。
核心防护：部署DNSSEC验证
DNSSEC（域名系统安全扩展）通过数字签名保证解析记录的真实性，是防污染的根本手段。但部署需要分步操作：
1. 在权威侧启用DNSSEC
如果你管理域名，需在DNS服务商处启用DNSSEC。通常包括生成密钥对、发布DS记录到父域。注意：启用后需监控签名有效期，定期轮换密钥。
2. 在递归解析器侧开启验证
运行递归解析器（如BIND、Unbound）时，配置dnssec-validation yes;。验证失败时，解析器应返回SERVFAIL而非伪造记录。但要注意：并非所有域名都正确配置DNSSEC，验证失败可能导致无法解析，需权衡。
3. 客户端使用支持DNSSEC的解析器
公共DNS如1.1.1.1、8.8.8.8均支持DNSSEC验证。但默认情况下，操作系统可能不强制验证，需在应用层或网络层配置。
替代与补充：使用安全解析器与加密传输
DNSSEC并非万能，它不加密查询内容，且依赖链可能中断。作为补充，你可以：
- 使用DoH/DoT：通过HTTPS或TLS加密DNS查询，防止中间人篡改。但注意：加密传输不验证记录真实性，需配合DNSSEC。
- 选择信誉良好的公共DNS：如Cloudflare、Google，它们有严格的安全措施，但依赖第三方，需评估信任。
- 部署本地递归解析器：自建Unbound并开启DNSSEC，减少对外部依赖，但需维护。
监控与日志：发现异常的关键
即使加固，也需要监控。根据OWASP日志安全速查表，日志应记录关键事件，但DNS日志往往被忽视。你可以：
- 记录解析请求与响应：包括源IP、查询域名、返回记录、TTL。异常模式（如大量相同查询、TTL突变）可能是污染迹象。
- 启用结构化日志：使用JSON格式，便于分析。Python的logging模块支持结构化输出，但需注意日志级别和性能。
- 集中收集日志：使用OpenTelemetry等工具，将日志与指标、追踪关联，但需注意兼容性。
然而，日志记录存在隐私和性能代价。根据OpenTelemetry文档，日志采集需平衡全面性和开销。建议先记录关键事件，逐步完善。
常见误区与失败条件
- 误区1：启用DNSSEC就万无一失：若递归解析器配置错误，或父域DS记录过期，可能导致解析中断，而非安全。
- 误区2：公共DNS绝对安全：公共DNS可能被针对，或本身存在漏洞，需定期关注安全公告。
- 误区3：日志越多越好：过度日志影响性能，且可能泄露用户隐私，需遵循最小化原则。
失败条件：如果域名未正确配置DNSSEC，或递归解析器未开启验证，防护形同虚设。此外，攻击者可能利用DNS协议的其他漏洞（如NXDOMAIN注入），需保持系统更新。
总结与行动清单
防止DNS缓存污染，你需要：
- 定期检测解析结果，发现异常立即处理。
- 在权威侧和递归侧部署DNSSEC，并验证生效。
- 使用DoH/DoT加密传输，但不要迷信单一措施。
- 配置日志监控，但注意隐私和性能。
记住：安全是动态过程，没有一劳永逸的方案。持续监控，及时更新，才能降低风险。
参考资料
延伸阅读