我计划使用 DNSSEC 对我的 DNS 区域进行签名。我的区域、注册商和 DNS 服务器 (BIND9) 都支持 DNSSEC。唯一不支持 DNSSEC 的是我的辅助名称服务器提供商（即buddyns.com）。
在他们的网站上，他们对 DNSSEC 进行了如下声明：
BuddyNS 不支持 DNSSEC，因为它暴露了一些不适合大容量 DNS 服务的漏洞。
嗯，我认为目前使用 DNSSEC 存在一些问题，因为大多数解析器不会检查记录是否正确签名。我不知道的是 - 根据他们的声明 - 提供它似乎会暴露某种安全漏洞。
这些“弱点”是什么？
答案1
DNSSEC 存在一些风险，但它们与反射或放大没有直接关系。在这种情况下，EDNS0 消息大小扩展只是一种障眼法。让我解释一下。
任何不依赖于先前身份证明的数据包交换都可能被 DDoS 攻击者滥用，攻击者可以使用未经身份验证的数据包交换作为反射器，也可能将其用作放大器。例如，ICMP（“ping”背后的协议）就可能被滥用。TCP SYN 数据包也是如此，即使 SYN 被欺骗为来自某个不想要这些 SYN-ACK 数据包的受害者，它也会请求最多 40 个 SYN-ACK 数据包。当然，所有 UDP 服务都容易受到这种攻击，包括 NTP、SSDP、uPNP，以及此处其他回复指出的 DNS。
大多数入侵检测、入侵防御和负载平衡器设备都是瓶颈，无法跟上“线速”流量。许多路由器和一些交换机也无法以线速运行。这些瓶颈是“路径”中最小的东西，比链路本身还小，是基于拥塞的 DDoS 攻击的实际目标。如果您可以让某人的防火墙忙于攻击流量，那么即使链路未满，正常的流量也无法通过。减慢防火墙速度的不是每秒的总位数（可以通过使用更大的消息来增加，EDNS0 和 DNSSEC 就可以做到这一点），而是每秒的总数据包数。
关于 DNSSEC 如何因为 DNSSEC 的消息大小较大而使 DDoS 变得更糟，有很多都市传说，虽然这在直觉上是合理的并且“听起来不错”，但它完全是错误的。但如果这个传说有一丝真实性，真正的答案仍然在别处——[因为 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 技巧），也不是阻止 ANY 查询，也不是选择退出 DNSSEC。这些都帮不了你。你需要DNS 响应速率限制（DNS RRL），这是一项完全免费的技术，目前已应用于包括 BIND、Knot 和 NSD 在内的多个开源名称服务器。您无法使用防火墙修复 DNS 反射问题，因为只有内容感知中间件（例如 DNS 服务器本身（添加了 RRL））才足够了解请求，能够准确猜测哪些是攻击，哪些不是攻击。我想再次强调：DNS RRL 是免费的，每个权威服务器都应该运行它。
最后，我想揭露我的偏见。我编写了 BIND8 的大部分内容，发明了 EDNS0，并且与他人共同发明了 DNS RRL。我从 1988 年 20 多岁的时候就开始从事 DNS 工作，现在我已经 50 多岁了，脾气暴躁，对误解问题的半生不熟的解决方案越来越没有耐心。如果这条消息听起来太像“嘿，你们这些孩子，别再来我的草坪了！”，请接受我的道歉！
答案2
我知道两个具体的漏洞。一个是 Håkan 提到的反射/放大。另一个是区域枚举的可能性。
反射/放大
反射是指将带有伪造源 IP 的请求发送到 DNS 服务器的攻击。被伪造的主机是攻击的主要受害者。DNS 服务器会在不知情的情况下将回复发送给从未请求过的主机。
放大是指任何反射攻击，反射响应包含的字节数或数据包数多于原始请求。在 DNSSEC+EDNS0 之前，以这种方式放大仅允许发送最多 512 个字节。使用 DNSSEC+EDNS0 可以发送 4096 个字节，通常跨越 3-4 个数据包。
这些攻击可能有缓解措施，但我不知道有任何 DNS 服务器实施了这些措施。
当客户端 IP 尚未确认时，DNS 服务器可以发送截断响应以强制客户端切换到 TCP。截断响应可以与请求一样短（如果客户端使用 EDNS0 而响应未使用，则更短），从而消除放大。
任何完成 TCP 握手并在连接上发送 DNS 请求的客户端 IP 都可以暂时列入白名单。列入白名单后，该 IP 可以发送 UDP 查询并接收最多 512 字节（如果使用 EDNS0 则为 4096 字节）的 UDP 响应。如果 UDP 响应触发 ICMP 错误消息，则该 IP 会再次从白名单中删除。
该方法也可以使用黑名单逆转，这仅意味着默认情况下允许客户端 IP 通过 UDP 进行查询，但任何 ICMP 错误消息都会导致 IP 被列入黑名单，需要 TCP 查询才能脱离黑名单。
覆盖所有相关 IPv4 地址的位图可以存储在 444MB 内存中。IPv6 地址必须以其他方式存储。
区域枚举
首先，区域枚举是否是一种漏洞尚有争议。但如果您不希望区域中的所有名称都公开，您可能会认为这是一种漏洞。区域枚举大多可以通过使用 NSEC3 记录来缓解。
即使使用 NSEC3，问题仍然存在，攻击者只需查询随机名称即可找到每个标签的哈希值。一旦攻击者获得所有哈希值，就可以对这些哈希值进行离线暴力攻击。
针对区域枚举的正确防御需要攻击者针对每个猜测向权威服务器执行查询。然而 DNSSEC 中不存在这样的防御。
答案3
我想到的事情实际上不是 DNSSEC 特定的，而是 DNSSEC 所依赖的 EDNS0 扩展。
EDNS0 允许更大的 UDP 有效负载，而更大的 UDP 有效负载可以允许更糟糕的流量反射/放大攻击。
我不知道验证解析器的百分比是多少，但流行的名称服务器软件似乎默认带有验证功能，而且人们很容易找到一些公开进行验证的知名服务提供商，例如康卡斯特和谷歌公共解析器。
基于此，我认为验证解析器的百分比可能比签名区域的百分比要好得多。