我打算用DNSSEC签署我的DNS区域。 我的区域，注册商和我的DNS服务器（BIND9）都支持DNSSEC。 唯一不支持DNSSEC的是我的辅助名称服务器提供商（即buddyns.com ）。
在他们的网站上 ，他们就DNSSEC 做出如下表述：
BuddyNS不支持DNSSEC，因为它暴露了一些不适合高容量DNS服务的漏洞。
那么，我认为DNSSEC的使用目前在某种程度上是有问题的，因为大多数parsing器不检查logging是否正确签名。 我不知道的是 – 根据他们的说法 – 似乎提供它会暴露某种安全漏洞。
那些“漏洞”是什么？
DNSSEC有一些风险，但它们与reflection或放大没有直接关系。 在这种情况下，EDNS0消息大小扩展是一个红色的鲱鱼。 让我解释。
任何不依赖于以前的身份certificate的数据包交换都会受到DDoS攻击者的滥用，这些攻击者可以使用未经身份validation的数据包交换作为reflection器，也可能用作放大器。 例如，ICMP（“ping”后面的协议）可能会被滥用。 就像TCP SYN数据包一样，即使SYN被欺骗来自不想使用这些SYN-ACK数据包的受害者，它也能请求多达40个SYN-ACK数据包。 当然，所有的UDP服务都容易受到这种攻击，包括NTP，SSDP，uPNP，以及其他的响应，这里也包括DNS。
大多数入侵检测，入侵防御和负载均衡设备都是瓶颈，无法跟上“线速”stream量。 还有许多路由器不能以线速运行，有些交换机。 这些瓶颈是“在path上”最小的东西，比链路本身小，是实施拥塞的DDoS攻击的实际目标。 如果你可以让某人的防火墙忙于攻击stream量，那么即使链路不满，stream量也不会很好。 减慢防火墙的速度并不是每秒总的比特数（可以通过使用更大的消息来增加，而EDNS0和DNSSEC则可以增加），而是每秒的总数据包数。
关于DNSSEC如何由于DNSSEC的更大的消息大小而使DDoS更糟，并且这使得直观的感觉和“听起来不错”，这里有很多都市传奇。 但是，如果这个图例有一丝真相，真正的答案仍然会在别处 – [因为DNSSEC总是使用EDNS0，但是EDNS0可以在没有DNSSEC的情况下使用]，许多正常的非DNSSEC响应与DNSSEC一样大回应将是。 考虑用于表示SPF策略或DKIM密钥的TXTlogging。 或者只是任何大型的地址或MXlogging。 总之，没有攻击需要DNSSEC，因此任何关注DNSSEC作为DDoS风险都是错误的能量。
DNSSEC确实有风险！ 这很难使用，难以正确使用。 通常，它需要一个用于区域数据更改的新工作stream程，注册商pipe理，安装新的服务器实例。 所有这些都必须经过testing和logging，并且每当与DNS有关的事情中断时，就必须对DNSSEC技术进行调查。 而最终的结果是，如果你做的一切正确的话，作为区域签名者，你自己的在线内容和系统对你的客户来说会更脆弱。 作为一个远端的服务器运营商，其结果将是，其他人的内容和系统对你来说将更加脆弱。 这些风险通常被认为超过了收益，因为唯一的好处是保护DNS数据免受空中修改或replace。 这种攻击是非常罕见的，不值得所有这些努力。 我们都希望DNSSEC有朝一日会变得无处不在，因为它将启用新的应用程序。 但事实是，今天，DNSSEC是所有成本，没有好处，并具有高风险。
所以，如果你不想使用DNSSEC，这是你的特权，但是不要让任何人迷惑你，说DNSSEC的问题就是它作为一个DDoS放大器的angular色。 DNSSEC作为DDoS放大器没有必要的作用; 还有其他更便宜的使用DNS作为DDoS放大器的更好方法。 如果你不想使用DNSSEC，那就让它是因为你还没有喝过库尔援助，你想成为最后一个（后来）而不是先行者（现在）。
必须防止DNS内容服务器（有时称为“权威服务器”）作为DNSreflection放大器被滥用，因为DNS使用UDP，并且因为UDP可被欺骗源数据包滥用。 保护您的DNS内容服务器免受这种滥用的方法不是阻止UDP，也不是强制TCP（使用TC = 1技巧），也不阻止ANY查询，也不select退出DNSSEC。 这些东西都不会帮助你。 您需要DNS响应速率限制 （DNS RRL），这是一项完全免费的技术，现在已经出现在包括BIND，Knot和NSD在内的多个开源名称服务器中。 您无法修复防火墙的DNSreflection问题，因为只有内容感知的中间件（如DNS服务器本身（已添加RRL））足够了解请求，才能准确地猜出攻击是什么，什么不是。 我想再次强调：DNS RRL是免费的，每个权威服务器都应该运行它。
最后，我想揭露我的偏见。 我写了大部分BIND8，我发明了EDNS0，和我共同发明了DNS RRL。 自1988年以来，我一直在从事DNS方面的工作20多年，现在我已经50多岁了，对半解决scheme的误解越来越不耐烦了。 请接受我的道歉，如果这个消息听起来太像“嘿，你的孩子，得到我的草坪！
我知道两个具体的漏洞。 有Håkan提到的reflection/放大。 并有区域枚举的可能性。
reflection/放大
reflection意味着将具有欺骗源IP的请求发送到DNS服务器的攻击。 被欺骗的主机是攻击的主要受害者。 DNS服务器会不知不觉地将答复发送给一个从未要求的主机。
放大是指任何reflection攻击，其中reflection的响应由比原始请求更多的字节或更多的分组组成。 在这种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地址将不得不以其他方式存储。
区域枚举
区域枚举是否首先是一个漏洞是辩论的主题。 但是，如果您不希望区域中的所有名称都是公开的知识，那么您可能会认为它是一个漏洞。 区域枚举通常可以通过使用NSEC3logging来减轻。
甚至在使用NSEC3时仍然存在的问题是攻击者只需查询随机名就可以find每个标签的哈希值。 一旦攻击者拥有了所有的哈希，就可以对这些哈希进行离线蛮力攻击。
防范区域枚举需要攻击者对权威服务器执行每个猜测的查询。 但是DNSSEC没有这样的防御。
想到的事实际上并不是DNSSEC特有的，而是关于DNSSEC依赖的EDNS0扩展。
EDNS0允许更大的UDP有效载荷，更大的UDP有效载荷可以允许更差的stream量reflection/放大攻击。
我不知道validationparsing器的百分比是多less，但是默认情况下，受欢迎的名称服务器软件似乎可以通过validation发送，而且可以轻松find一些值得关注的服务提供商，例如Comcast和Google公共parsing器。
基于此，我认为validationparsing器的百分比可能比签名区域的百分比好得多。