2018年5月31日，我们的1.1.1.1解析器服务中断了17分钟；这是我们的行为，而不是攻击的结果。Cloudflare受到Gatebot DDoS缓解管道的攻击保护。Gatebot每天执行数百次缓解，保护我们的基础设施和客户免受L3/L4和L7攻击。以下是今年Gatebot每日操作数的图表：过去，我们曾在博客中介绍过我们的系统：认识Gatebot，一个让我们睡觉的机器人今天，事情没有按计划进行。网关机器人Cloudflare的网络很大，可以处理许多不同类型的流量，并缓解不同类型的已知和未知攻击。Gatebot管道分三个独立的阶段来管理这种复杂性：攻击检测-收集全球实时流量测量并检测攻击反应自动化-选择适当的缓解措施缓解-在边缘执行缓解逻辑听起来不错的"反应式自动化"部分实际上是管道中最复杂的阶段。我们从一开始就预料到了这一点，这就是为什么我们使用定制的函数式反应式编程（FRP）框架来实现这一阶段。如果你想了解更多，请看演讲和演讲。我们的缓解逻辑通常结合来自不同内部系统的多个输入，以得出最佳、最合适的缓解措施。最重要的输入之一是关于IP地址分配的元数据：我们以不同的方式缓解对HTTP和DNS IP范围的攻击。我们的FRP框架允许我们用清晰易读的代码来表达这一点。例如，这是负责执行DNS攻击缓解的代码的一部分：def action_gk_dns（…）：[...]如果是波特！=53：无返回如果被列入白名单_ip.get（ip）：无返回如果ip不在ANYCAST_ip中：无返回[...]这是我们今天尝试改进的最后一个代码检查。显然，上面的代码过于简单化了所有的攻击缓解，但是尽早决定受攻击的IP是否服务于DNS流量是很重要的。是那张支票今天出问题了。如果IP确实服务于DNS流量，则攻击缓解的处理方式与从不提供DNS的IP不同。Cloudflare在增长，Gatebot也在增长Gatebot创建于2015年初。三年的时间听上去不算太长，但从那以后，我们已经大幅增长，并在我们的软件堆栈中增加了服务层。我们今天所依赖的许多内部集成点当时并不存在。其中之一就是我们所说的供应API。当Gatebot看到一个IP地址时，它需要能够确定它是否是Cloudflare的地址之一。provisionapi是一个简单的restfulapi，用于提供此类信息。这是一个相对较新的API，在它存在之前，Gatebot必须通过从硬编码文件中读取网络列表来确定哪些IP地址是Cloudflare地址。在上面的代码片段中，ANYCAST_IPS变量使用此文件填充。事情出了问题今天，为了收回一些技术债务，我们部署了将Gatebot引入provisionapi的新代码。我们没有说明的是，provisionapi不知道的是，1.1.1.0/24和1.0.0.0/24是特殊的IP范围。坦率地说，由于我们的IP配置相当复杂，几乎每个IP范围都是"特殊"的。但我们的递归DNS解析程序范围更为特殊：它们是相对较新的，我们正在以一种非常独特的方式使用它们。我们的Cloudflare地址硬编码列表包含一个专门针对这些范围的手动异常。您现在可能已经猜到了，我们在进行集成工作时并没有实现这个手动异常。记住，修复的全部想法是删除硬编码的陷阱！影响结果是，在推动新代码发布后，我们的系统将解析器流量解释为攻击。自动系统在协调世界时5月31日17:58到18:13之间为我们的DNS解析程序IP范围部署了17分钟的DNS缓解。这导致1.1.1.1 DNS解析程序无法全局访问。经验教训虽然Gatebot（DDoS缓解系统）有强大的功能，但我们未能彻底测试这些变化。我们利用今天的事件来改善我们的内部系统。我们的团队为1.1.1.1和Gatebot而感到无比自豪，但今天我们没有做到。我们要向所有客户道歉。我们将利用今天的事件来改进。下一次我们减少1.1.1.1流量时，我们将确保有合法的攻击正在攻击我们。