![.io auth.NS 拒绝对 dnsviz.net 发出 UDP 响应 – 我为什么不应该这样做?](https://linux22.com/image/785931/.io%20auth.NS%20%E6%8B%92%E7%BB%9D%E5%AF%B9%20dnsviz.net%20%E5%8F%91%E5%87%BA%20UDP%20%E5%93%8D%E5%BA%94%20%E2%80%93%20%E6%88%91%E4%B8%BA%E4%BB%80%E4%B9%88%E4%B8%8D%E5%BA%94%E8%AF%A5%E8%BF%99%E6%A0%B7%E5%81%9A%EF%BC%9F.png)
认真地说,假设我阻止(当然是返回,而不是丢弃)UDP :53 进入我的权威名称服务器。解析器将回退到 TCP,并且我不需要对欺骗的源 IP 进行任何速率限制。因为 DDoS 攻击的欺骗受害者只会得到相当于 UDP 或 TCP 确认的连接被拒绝,而不是更大的 DNS 答案。
简单的解决方案,一切都很好。或者不是那么简单吗?
答案1
据我所知,当通过默认 UDP 传输联系权威名称服务器失败时,DNS 协议不要求必须通过 TCP 重试请求。实际上,阻止 UDP 将有效地使您的权威名称服务器无法访问。
正常的方法是DNS服务器需要发送一个TC
设置了位(截断)的UDP响应,通知客户端消息长度已超出允许的大小并通过TCP重试。
答案2
将客户端切换到 TCP 进行常规查询的正常机制是发送截断响应(TC
设置了标志的响应)。
这是实施速率限制的常用策略,目的是在仍提供服务的同时限制基于 UDP 的放大攻击。
我不会依赖于解析器服务器通常甚至会自发地尝试 TCP,即使这当然是被允许的,而且从稳健性的角度来看如果它们这样做会很好。