昨天，DigitalOcean的DNS基础设施在两小时零四分钟内无法使用。在此期间，我们只能对发送到ns1、ns2和ns3的一小部分DNS请求作出响应。数字海洋网. 我们知道您对数字海洋的依赖程度，我们非常重视我们服务的可用性和可靠性。我们想道歉，并分享更多关于我们的DNS系统的细节，这一具体的攻击，以及我们正在做什么，使我们的系统从这里更具弹性好吧。有些背景解析程序组成了我们权威的DNS基础设施，由一家著名的DDoS抵御公司提供支持。他们提供的服务使用anycast将来自世界各地的客户的流量转移到数字海洋最近的数据中心。然后我们在所有的设施中都有权威的解析程序来处理和响应DNS查询。这种方法最显著的优点之一是它允许在我们的全球范围内进行简单的负载分配，并且可以轻松地添加更多的解析器来处理增加的容量需要。那个发生在2016年3月24日UTC下午2:34（美国东部时间上午10:34），我们开始从我们的监控系统收到警报，所有的解析程序都无法响应DNS查询。当我们调查这个问题时，我们注意到解析器接收到的查询比正常情况下多出几个数量级。尽管在典型的峰值操作期间，哪个云服务器，可用容量明显大于所需容量，但仍然不足以回答异常大量的入站查询。我们开始更仔细地查看发送到解析程序的查询，试图将正常流量与坏参与者的流量区分开来。流量模式和源IP地址与我们期望的相匹配——只是比正常情况下大得多。您可以看到未缓存（黄线）和缓存流量（绿线）下面。在在这一点上，我们的DDoS缓解提供商参与进来了。我们所有的DNS流量都流经他们的网络，网络中有许多保护措施，既能识别又能减轻攻击。然而，我们两个都没能在流量之外发现任何异常重点。我们的DNS守护程序被配置为在某个阈值清空未应答查询的队列，以确保守护程序能够应答将来的入站查询。这无意中导致了缓存失效。我们推出了一个新的配置来解决这个问题，但是缓存无法重新填充。虽然在正常情况下，淘客网站，系统可以承受所有解析器丢失其查询缓存，但是查询数量的急剧增加使得解析程序无法重建其缓存。这一切都发生在解析器已经处于异常高的负载下，导致它们进一步压力。在在这一点上，我们进一步与我们的DDoS缓解提供商联系，以帮助确定流量的来源和类型，并识别出PTR记录的查询百分比高于正常百分比。我们开始屏蔽它们，以允许我们对其他查询作出响应。他们还能够通过阻塞一些自治系统号（ASN）来减少到达我们的解析器的查询数量，这些系统号是最重要的流量来源。最后，我们增加了缓存的DNS记录的TTL，这是在允许新查询命中源解析程序之前边缘缓存响应的时间长度。当我们通过流量查找模式时，很明显攻击者知道大量使用我们的DNS基础设施管理的域。我们所有的公共子网都可以通过ARIN获得，这意味着可以找到托管在我们服务上的域，推断它们正在使用我们的DNS，建站快速，然后发送大量看起来合法的查询。虽然ASN阻塞确实阻止了一些合法的DNS查找被应答，但它几乎立即允许系统开始应答大多数查询服务从UTC下午4:40（美国东部时间下午12:40）开始以正常延迟响应查询。缓存开始重新填充，查询量恢复到正常水平。在UTC下午5:30（美国东部时间下午1:30），进入我们的解析器的绝大多数流量是干净的。在下面的第一张图中，可以看到查询缓存命中率随着服务的开始而急剧增加恢复。那个下图以绿色显示SERVFAILs，蓝色显示边缘和我们的解析器之间的第50个百分位延迟，以及中的第90个百分位延迟黄色。在7： UTC下午22点（美国东部时间下午3点22分），大部分的过滤是删除。未来我们正在审查和改进一些基础设施。最值得注意的是，我们将在我们的基础设施中构建更好的方式来移动DNS流量。导致这起事件持续两个小时的原因之一是，返利购物，我们无法控制到达我们网络的流量。尽管我们将继续与DDoS抵御提供商合作，但我们也将通过创建内部移动、速率限制和流量整形等手段来改进我们自己的DNS网络，以便即使在受到攻击时也能继续响应大多数请求。我们已经准备好了强大的工具来减轻对Droplet网络的攻击，并将扩展该工具以支持DNS as好吧，我们将完全从DDoS缓解提供商中分离额外容量的供应。与我们的DDoS缓解提供商的外部通信意味着我们在事件发生期间会有相当频繁的往返，这使得我们更难自行测试缓解技术。它们透明地向解析器发送请求，这意味着我们提供更多解析程序容量的能力取决于提供者的响应速度。这导致向池中添加额外的节点所需的时间比理想的要长得多，这导致我们随后减慢了恢复正常操作的速度。我们计划改变我们向DDoS缓解提供商运行的代理服务器呈现网络的方式，看云，以动态更改池的容量更容易。进去结论首先，我们知道我们的服务对您的项目和业务的成功至关重要。我们DigitalOcean的所有人都想为这次中断造成的影响道歉。我们将继续分析我们的内部通信系统的可靠性和恢复力。