假墙投毒DNS投毒

DNS投毒是一种破坏DNS查找过程的攻击，它会将用户重定向到恶意目标，而无需更改目标服务器上的任何内容。本文将从协议层面解析DNS投毒的工作原理，解释它为何至今仍是一种重要的威胁，以及如何检测和防御DNS投毒。
DNS解析如何造成攻击面#要理解 DNS 投毒，你需要了解递归解析的工作原理。当客户端查询一个域名时，请求通常会经过递归解析器（例如你的 ISP、Cloudflare1.1.1.1或像Technitium这样的自托管实例）。该解析器会遍历委托链，包括根服务器、顶级域名服务器、权威域名服务器，然后根据记录中的TTL值缓存响应。
漏洞就存在于缓存中。DNS 设计于 1983 年（RFC 882/883，后修订为 RFC 1035），当时没有身份验证机制，响应与查询的匹配依赖于 16 位事务 ID ( TXID ) 和传出查询的源端口。如果攻击者能够预测或暴力破解这些值，并在合法响应到达之前发送伪造的响应，解析器就会接受并缓存这条被污染的记录。
然后，缓存的虚假信息会一直提供给使用该解析器的每个客户端，直到 TTL 过期。
卡明斯基袭击事件#2008 年之前，DNS 投毒攻击被认为难以大规模实施，因为攻击者必须等待缓存记录过期才能尝试注入。丹·卡明斯基的研究推翻了这一假设。
Kaminsky证明，攻击者可以针对随机的、不存在的子域名（例如`example.com` abc123.example.com）发起查询，这些子域名永远不会被缓存，从而向解析器发送大量伪造的响应。每个伪造的响应都包含一个授权部分，该部分将example.com自身委托给攻击者控制的名称服务器。由于子域名是唯一的，因此每次尝试都会与实际的权威响应形成新的竞争条件。
这使得DNS投毒攻击从低概率的单次攻击转变为可重复的攻击。包含65,536个值的TXID密钥空间可在数秒内耗尽。随后的协调补丁（源端口随机化RFC 5452）通过随机化UDP源端口扩大了有效熵，但这仅仅是一种缓解措施，DNS中缺乏加密认证的问题依然存在。
超越经典缓存投毒的攻击变种#DNS投毒攻击并非仅限于与递归解析器竞速响应。还有其他一些类似的技术也能达到类似的效果。
针对本地网络的恶意DHCP /网关攻击可以直接向客户端推送恶意 DNS 服务器。在共享网络或网络隔离不完善的网络中，ARP 欺骗允许攻击者在第二层拦截 DNS 查询并返回任意响应，这本质上是在解析层进行中间人攻击。
BGP劫持已被用于在路由层重定向DNS流量。2018年，攻击者利用互联网交换中心（IXP）的BGP泄漏，短暂劫持了亚马逊的Route 53 IP地址空间，将加密货币钱包服务的DNS查询重定向到钓鱼网站。这并非传统意义上的缓存投毒，但同样达到了目的，用户会收到看似合法但实则由攻击者控制的响应。
解析器被入侵或恶意攻击是另一种可能性。公共 Wi-Fi 强制门户、ISP 级拦截以及国家级 DNS 过滤都会在传输过程中修改响应。在这些环境下，用户的解析器根本不可信。
检测与可见性#检测 DNS 投毒可能有一些迹象：
- TTL 意外偏移：通常具有 3600 秒 TTL 值的记录突然出现 60 秒或 86400 秒的值，这可能表明存在注入。
- 授权部分异常：响应中包含指向陌生名称服务器的委托记录。
- DNSSEC验证失败：如果您正在进行验证，SERVFAIL但对应该能够正常解析的域的响应可能表明上游遭到篡改。
- 查询日志分析：单个域的随机子域的大量NXDOMAIN响应可能表明正在进行 Kaminsky 式攻击。
诸如dnstap（被动式 DNS遥测）和Zeek（又名 Bro）及其 DNS 分析器模块之类的工具可以大规模地捕获和分析 DNS 流量。对于自托管解析器，Technitium DNS 服务器提供内置查询日志记录功能，并原生支持 DNSSEC 验证。
纵深防御#没有哪一种单一的控制措施能够彻底根除DNS投毒攻击。有效的防御措施通常是多层叠加的。
DNSSEC为 DNS 记录添加加密签名，使解析器能够验证响应是否真正来自权威区域。
DNS-over-HTTPS (DoH)和DNS-over-TLS (DoT)对传输层进行加密，防止传输过程中被拦截和篡改。它们并不能取代 DNSSEC，而是共同解决身份验证和保密性问题。
运行自己的验证解析器（Unbound、Knot Resolver、Technitium）可以让您控制缓存行为、DNSSEC 策略和查询日志记录，因为您不再信任第三方的缓存完整性。
三十年来的补丁、扩展和加密层虽然缩小了攻击面，但核心协议默认情况下仍然未经身份验证。了解这种信任机制的缺陷所在，是构建不依赖于该协议的基础设施的第一步。