最近备受关注的DDoS攻击在DNS社区引发了激烈的争论。对于如何加强DNS以避免将来的宕机，每个人都有很强的意见。使用一个或多个DNS提供者更好吗？什么DNS TTL值是最好的？DNSSEC让你多少暴露了？Leticia Chamorro提供的CC BY 2.0图像这些都是值得认真讨论的有效问题，但是调整您自己的DNS服务器设置并不是全部。作为一个社区，我们需要加强DNS协议本身。我们需要做好准备，以抵御未来肯定会带来的最严峻的DDoS攻击。在这篇博文中，我将指出核心DNS协议中的一个模糊特性。现在将此"隐藏"功能用于DDoS抵御是不实际的，但只要稍作调整，它就可能变得非常有用。该功能目前未使用不是由于协议问题-它是由于DNS顶级域（TLD）运营商的冷漠。如果它正常工作，它将减少遭受攻击的DNS服务器的DDoS恢复时间。有问题的功能是：DNS TLD粘合记录。更具体地说，dnsld使用自定义TTL值粘合记录。DNS-glue是DNS协议中最不被人理解的怪癖之一。请允许我解释一下为什么我认为减少胶水TTL是个好主意。但首先：胶水到底是什么？Frankieleon的CC BY 2.0图像DNS粘合DNS胶水是DNS固有的"鸡还是蛋问题"的解决方案。用一个具体的例子来解释是最容易的。想象一下你想解决cloudflare.net域。为此，请向本地递归DNS服务器请求解析。好吧，但这不能回答问题，分解器是做什么的？为了简单起见，让我们做几个假设：我们的递归器没有缓存任何数据cloudflare.net.但是，它知道.NETTLD是由许多命名服务器处理的，其中包括.gtld-服务器.net它的IP地址是192.5.6.30。我们忽略了第一步，并在递归器查询.net名称服务器时开始我们的调查。解决cloudflare.net递归器需要确定哪些名称服务器承载cloudflare.net数据-或者用DNS来说：哪个名称服务器是该区域的权威服务器？为此，递归器请求.net名称服务器。假设我们知道其中一个是192.5.6.30。递归器将启动一个查询，我们可以用这个dig命令进行模拟：$挖cloudflare.net@192.5.6.30条[为简洁起见，输出被截断]；；权限部分：cloudflare.net. NS ns1中的172800。cloudflare.net.；；附加部分：[暂时跳过]我们礼貌地问一个.net名称服务器：我在哪里可以找到cloudflare.net？答案是：我不知道，但我知道该问谁！去和ns1谈谈。cloudflare.net，它知道所有关于cloudflare.net区域！这就是所谓的"代表团"。net告诉我们离开去问ns1。cloudflare.net相反。等等，ns1在哪里。cloudflare.net？它的IP地址是什么？如果我们问.net名称服务器，它会告诉我们同样的事情-去和ns1谈谈。cloudflare.net!正如你所看到的，这是一个鸡和蛋的问题。解决cloudflare.net我们需要解决ns1。cloudflare.net. 解析ns1。cloudflare.net我们需要解决ns1。cloudflare.net，以此类推。由Sam Cat制作的CC BY 2.0图像胶水这就是DNS胶水的用武之地。我在之前的终端输出中撒了一点谎，ns1的分辨率。cloudflare.net在.net名称服务器给出的响应中可用。这次请允许我展示答案的相关"附加"部分：$挖cloudflare.net@192.5.6.30条[为简洁起见，输出被截断]；；权限部分：cloudflare.net. NS ns1中的172800。cloudflare.net.；；附加部分：ns1。cloudflare.net. 172800澳元173.245.59.31为了打破解析循环，我们需要答案中的第二位数据-附加部分。在这里，.net服务器显示：顺便说一句，以防您想知道ns1在哪里。cloudflare.net，是173.245.59.31。这是DNS胶水。从概念上讲，这是一个相当奇怪的发明。我们正在请求.net区域的权威名称服务器，以获得cloudflare.net. 作为响应，我们不仅得到了委派信息，还得到了服务器的地址。想一想，这就像是cloudflare.net区域由.net TLD区域处理！这能走多远？附加部分会不会有武断的决议？这个行吗？$挖cloudflare.net@192.5.6.30条[为简洁起见，输出被截断]；；权限部分：cloudflare. NS ns1中的172800。cloudflare.net.；；附加部分：ns1。cloudflare.net. 172800澳元173.245.59.31 1.2.3.4中的172800有趣的故事是：它曾经"工作"并混淆递归器。这正是1997年卡什普雷夫袭击所造成的后果。这是一个很好的老派DNS缓存注入或缓存中毒攻击。解释DNS胶水答案的递归逻辑是相当扭曲的。对细节的理解很差，而且每个实现都会有所不同。从概念上讲，有效的粘合记录和缓存注入之间的障碍非常小。DNS专家们正在积极讨论这一点，见draft-fujiwara-dnsop-resolver-update-00和draft-weaver-dnsext-comprehensive-resolver-00。怎么了？我们已经展示了DNS胶水是什么，它是如何工作的，以及为什么在DNS协议中需要它。坦率地说，DNS胶水是一个非常巧妙的解决方案来解决一个真正的斗争。现在让我解释一下这个问题。让我们再看看胶水的答案：；；附加部分：ns1。cloudflare.net. 172800澳元173.245.59.31问题是TTL值。在这里，你可以看到这个记录的TTL是172800秒=48小时。在正常情况下，域所有者，在本例中，我的同事管理cloudflare.net域，有一种方法可以在粘合记录中配置此值。但48小时并不是我们打算使用的值！如果你问cloudflare.net此记录的权威名称服务器您将获得一个更短的不同TTL：$dig ns1。cloudflare.net@173.245.59.31ns1。cloudflare.net173.245.59.31中的0.900您可以看到，权威名称服务器声称此记录的有效期仅为900秒=15分钟，而不是48小时！这种差异从何而来？胶水记录通常是在登记员公开的某种面板中管理的。这很好；最后，我们将cloudflare.net命名空间放入.net区域。但问题是：虽然有一种方法可以设置glue IP地址，但是无法配置TTL。glue TTL由TLD操作员硬编码为48小时。我坚信这太长了，而且会损害攻击性的DDoS缓解技术。散射如果DNS-glue-TTL更小，在攻击期间可能会轮换名称服务器的ip。事实上，在Cloudflare，我们一直在HTTP层使用这种技术。在重大攻击期间，我们能够通过更改客户橙色云域（我们代理的那些域）的DNS分辨率，在IP地址之间迅速移动客户流量。这使我们能够转移受攻击IP地址的合法流量，并在这些地址上部署积极的DDoS缓解措施。在极端情况下，我们可以BGP空路由目标ip，而对客户影响很小。在内部我们称这种技术为"散射"。HTTP层上的"散射"对L3攻击非常有效。也可以做到分散而不影响客户，因为我们提供的DNS记录具有较低的DNS TTL值。但"散射"也可以在DNS权威层上进行！在对我们的一个DNS服务器进行严重的L3攻击期间，我们希望将合法流量从受攻击的IP地址移开。DNS权威层上的"散射"可能是一种强大的缓解技术。当来自僵尸网络的数据包直接攻击权威服务器（而不是被合法的DNS递归器反映出来）时，这将非常有效地抵御攻击。不幸的是，这是不可能的"DNS认证散射"，因为我们没有权力调整TLD glue TTL值。由于TTL停留在48小时，动态更改名称服务器的IP地址不是一个选项。我认为这个问题应该解决。反论点虽然我坚信短DNS ttl是件好事，但其他人不同意。一个经常提到的问题是短ttl会增加DNS服务器上的负载。这当然是正确的，但是正如.nl操作符在这个OARC演示中指出的，影响是最小的。为了应对攻击，DNS服务器必须大量超量配置。实际上，.nl运营商从2016年初就开始提供1小时胶水TTL服务，没有任何问题。在这篇博客文章中，BozhidarBozhanov认为短TTL通常是不可取的。重要的是glue TTL应该是可配置的。测试东西很难证明"DNS-auth-scattering"技术的有效性，因为glue TTL是在48小时内硬编码的，但是我们还是尝试了检查它。在一个测试中，我们添加了一个胶粘记录，并测量了它所占流量份额需要多长时间。我们在cloudflare.com网站域。下面是两个Cloudflare名称服务器的流量级别图表，这两个服务器已经有glue:ns3和ns6，我们刚刚添加了glue for:ns6 bis。一天，我们在协调世界时2200添加胶水。很明显，随着全球递归器上的缓存过期，这个IP地址上的流量逐渐增加。流量似乎已经达到了与其他glue名称服务器相当的水平，大约在第二天1600到1800之间，大约8小时之后。在一大块DNS解析程序接收新的粘合IP之前，至少有8小时的延迟。当然，完全切换的最长时间是48小时。结束语我们必须使用一切可能的技术，以使互联网的DNS基础设施更具抵御DDoS攻击的能力。我们可能需要改进核心DNS协议（积极的NSEC缓存），调整默认值（提倡使用低ttl）和共享高级缓解技术（散射）。在本文中，我解释了DNS glue是什么，以及为什么我相信DNS TLD glue TTL val