我阅读了很多关于它的文章,但我不明白如果出现以下情况,缓存中毒是如何发生的:
- 如果响应的事务 ID 不匹配,则查询被取消并标记为失败(即攻击者无法暴力破解事务 ID,因为他们只会接受第一个响应)
- 递归解析器一次只发送 1 个针对同一域/类型/类的请求,这意味着攻击者无法触发针对同一域的多个请求来暴力破解事务 ID
在看起来很基本的配置中,如果攻击者需要猜测事务 ID,缓存中毒怎么可能?攻击者会强迫递归解析器一次又一次地解析同一个域以进行更多尝试吗?在那种情况下,这可能需要几个小时......
我阅读了很多关于它的文章,但我不明白如果出现以下情况,缓存中毒是如何发生的:
在看起来很基本的配置中,如果攻击者需要猜测事务 ID,缓存中毒怎么可能?攻击者会强迫递归解析器一次又一次地解析同一个域以进行更多尝试吗?在那种情况下,这可能需要几个小时......
这主要是您的第一个不准确的要点:
当接收到未知的事务 id 时,该响应将被丢弃。但是您认为未完成的查询以某种方式被认为失败的假设是不正确的。
实际上,这种攻击场景变成了攻击者在来自真实名称服务器的响应到达之前获得有效响应的竞赛。
您假设的问题是事务ID(+ UDP源端口)的全部目的是匹配对未完成查询的响应,但是当这些值错误的响应(不匹配任何查询)时,你怎么知道你应该认为哪个查询失败了?
如果您要允许某种形式的部分匹配,您将如何以一种不会用可轻易利用的 DoS 攻击代替攻击者的繁重竞赛的方式来实现它?
“真实”保护的选项:
(即使只是通过 TCP 进行查询也可以改善问题中的特定场景,但基于密码学的解决方案在处理哪些攻击方面显然要广泛得多。)