Joh*_*uer 28 security domain-name-system dnssec vulnerabilities
我打算用 DNSSEC 签署我的 DNS 区域。我的区域、注册商和我的 DNS 服务器 (BIND9) 都支持 DNSSEC。唯一不支持 DNSSEC 的是我的二级域名服务器提供商（即buddyns.com）。
在他们的网站上，他们对 DNSSEC 进行了说明：
BuddyNS 不支持 DNSSEC，因为它暴露了一些不适合大容量 DNS 服务的漏洞。
好吧，我认为 DNSSEC 的使用目前在某种程度上是有问题的，因为大多数解析器不检查记录是否正确签名。我不知道的是 - 根据他们的声明 - 似乎提供它会暴露某种安全漏洞。
这些“漏洞”是什么？
Pau*_*xie 103
DNSSEC 有一些风险，但它们与反射或放大没有直接关系。在这种情况下，EDNS0 消息大小扩展是一个红鲱鱼。让我解释。
任何不依赖于先前身份证明的数据包交换都会受到 DDoS 攻击者的滥用，他们可以将未经身份验证的数据包交换用作反射器，也可能用作放大器。例如，ICMP（“ping”背后的协议）可能会以这种方式被滥用。TCP SYN 数据包也是如此，即使 SYN 被欺骗来自某些不想要这些 SYN-ACK 数据包的受害者，它也会请求多达 40 个 SYN-ACK 数据包。当然，所有 UDP 服务都容易受到这种攻击，包括 NTP、SSDP、uPNP，以及这里的其他响应所指出的，也包括 DNS。
大多数入侵检测、入侵防御和负载平衡器设备都是瓶颈，无法跟上“线速”流量。还有很多路由器不能以线速运行，还有一些交换机。这些瓶颈是“路径中”最小的东西，比链路本身更小，是基于拥塞的 DDoS 攻击的实际目标。如果您可以让某人的防火墙忙于攻击流量，那么即使链接未满，良好的流量也不会通过。降低防火墙速度的不是每秒总位数（可以通过使用更大的消息来增加，EDNS0 和 DNSSEC 可以增加），而是每秒数据包总数。
有很多关于 DNSSEC 如何使 DDoS 变得更糟的都市传说，因为 DNSSEC 的消息大小较大，虽然这具有直观意义并且“听起来不错”，但它完全是错误的。但是，如果这个传说有一丝真实，那么真正的答案仍然在别处——[因为 DNSSEC 总是使用 EDNS0，但 EDNS0 可以在没有 DNSSEC 的情况下使用]，并且许多正常的非 DNSSEC 响应与 DNSSEC 一样大反应是。考虑用于表示 SPF 策略或 DKIM 密钥的 TXT 记录。或者只是任何大量的地址或 MX 记录。简而言之，没有攻击需要 DNSSEC，因此任何将 DNSSEC 视为 DDoS 风险的关注点都是浪费精力。
DNSSEC 确实有风险！它很难使用，更难正确使用。通常它需要一个新的工作流程来更改区域数据、注册管理器、安装新的服务器实例。所有这些都必须经过测试和记录，并且每当与 DNS 相关的问题出现问题时，都必须将 DNSSEC 技术作为可能的原因进行调查。如果您做对了一切，最终结果将是，作为区域签名者，您自己的在线内容和系统对您的客户来说将更加脆弱。作为远端服务器运营商，结果将是，其他人的内容和系统对您来说将更加脆弱。这些风险通常被视为大于收益，因为唯一的好处是保护 DNS 数据免于进行中的修改或替换。那次攻击是如此罕见，以至于不值得付出这些努力。我们都希望有一天 DNSSEC 变得无处不在，因为它将启用新的应用程序。但事实是，今天，DNSSEC 全是成本，没有收益，而且风险很高。
因此，如果您不想使用 DNSSEC，那是您的特权，但不要让任何人混淆您，DNSSEC 的问题在于它作为 DDoS 放大器的作用。DNSSEC 没有必要充当 DDoS 放大器；还有其他更便宜的更好的方法来使用 DNS 作为 DDoS 放大器。如果您不想使用 DNSSEC，那就是因为您还没有喝过 Kool Aid，并且您想成为最后的推动者（以后）而不是先动者（现在）。
DNS 内容服务器，有时也称为“权威服务器”，必须防止被滥用为 DNS 反射放大器，因为 DNS 使用 UDP，并且因为 UDP 可被欺骗源数据包滥用。保护您的 DNS 内容服务器免受此类滥用的方法不是阻止 UDP，也不是强制 TCP（使用 TC=1 技巧），也不是阻止任何查询，也不是选择退出 DNSSEC。这些东西都不会帮助你。您需要DNS 响应速率限制(DNS RRL)，一种完全免费的技术，现在存在于多个开源名称服务器中，包括 BIND、Knot 和 NSD。您无法通过防火墙修复 DNS 反射问题，因为只有内容感知中间件（例如 DNS 服务器本身（添加了 RRL））对请求有足够的了解，以便能够准确猜测什么是攻击，什么不是。我想再次强调：DNS RRL 是免费的，每个授权服务器都应该运行它。
最后，我想揭露我的偏见。我写了大部分 BIND8，我发明了 EDNS0，我共同发明了 DNS RRL。自 1988 年以来，我一直在研究 DNS，当时我 20 多岁，现在我脾气暴躁，50 多岁，对解决误解问题的半生不熟的解决方案越来越没有耐心。如果这条信息听起来太像“嘿，你们这些孩子，滚出我的草坪！”，请接受我的道歉。
我知道两个特定的漏洞。有 Håkan 提到的反射/放大。并且存在区域枚举的可能性。
反射/放大
反射是指将带有欺骗性源 IP 的请求发送到 DNS 服务器的攻击。被欺骗的主机是攻击的主要受害者。DNS 服务器会在不知不觉中将回复发送给从未请求过它的主机。
放大是指任何反射攻击，其中反射响应由比原始请求更多的字节或更多的数据包组成。在 DNSSEC+EDNS0 之前以这种方式放大最多只允许发送 512 个字节。使用 DNSSEC+EDNS0 可以发送 4096 个字节，通常跨越 3-4 个数据包。
这些攻击有可能的缓解措施，但我不知道有任何 DNS 服务器实施它们。
当客户端 IP 没有被确认时，DNS 服务器可以发送一个截断的响应来强制客户端切换到 TCP。截断的响应可以与请求一样短（或者如果客户端使用 EDNS0 而响应没有，则更短）消除了放大。
任何完成 TCP 握手并在连接上发送 DNS 请求的客户端 IP 都可以临时列入白名单。一旦列入白名单，该 IP 就可以发送 UDP 查询并接收最多 512 字节的 UDP 响应（如果使用 EDNS0，则为 4096 字节）。如果 UDP 响应触发 ICMP 错误消息，则该 IP 将再次从白名单中删除。
该方法也可以使用黑名单来反转，这意味着默认情况下允许客户端 IP 通过 UDP 进行查询，但任何 ICMP 错误消息都会导致 IP 被列入黑名单，需要 TCP 查询才能从黑名单中删除。
覆盖所有相关 IPv4 地址的位图可以存储在 444MB 的内存中。IPv6 地址必须以其他方式存储。
区域枚举
区域枚举是否首先是一个漏洞是有争议的话题。但是，如果您不希望您的区域中的所有名称都为公众所知，您可能会将其视为一个漏洞。区域枚举主要可以通过使用 NSEC3 记录来缓解。
即使在使用 NSEC3 时仍然存在的问题是攻击者可以通过简单地查询随机名称来找到每个标签的哈希值。一旦攻击者拥有所有散列，就可以对这些散列执行离线暴力攻击。
对区域枚举的适当防御将要求攻击者针对每个猜测对权威服务器执行查询。然而，DNSSEC 中不存在这样的防御。