昨晚不是我们最好的时候。格林尼治标准时间7:30左右，我们完成了一个新的DNS基础设施的推进。这个新更新的核心是使DNS更新更快。在您的DNS设置更改传播到我们的所有基础设施之前，大约需要一分钟的时间，随着新的DNS更新，它几乎是即时的。为了了解出了什么问题，了解这一点很重要。对DNS进行更新需要更改系统中的底层代码，并使服务器脱机。我们将更新时间安排在网络上最安静的时间，即格林尼治标准时间07:00（旧金山晚上11:00左右）。上周，代码在我们的测试环境和一个数据中心运行得很顺利，所以我们感觉很好。而且，事实上，DNS更新的推进进展顺利，而且是提前的。丑陋的当14个数据中心中的10个更新完成时，我们得到了一个小问题的消息，这个问题影响了从主DNS数据库推送的一些数据。在诊断次要问题的过程中，主DNS数据库被删除。新的DNS系统完成了它的工作，并在10个数据中心中进行了快速的更新。结果是，如果递归DNS查找一个域并命中这10个数据中心中的一个，那么在格林尼治标准时间07:30左右，它们将收到一个无效的结果。这意味着这些网站离线了，这完全是我们的错。坏的DNS数据库是定期备份的，但我们花了大约5分钟来识别问题、检索备份并将其推送到生产环境中。我们新的DNS基础设施立即将更新推送到大多数数据中心，但由于更新量太大，需要几分钟才能重建。在大多数地方，新的DNS请求得到了正确的响应，但结果却不到10分钟。不幸的是，DNS是一系列相互连接的缓存，其中许多不在我们的控制范围之内。如果您在该问题期间访问了某个页面，则ISP的递归DNS可能会缓存该结果。由于大多数DNS提供商不容易刷新缓存（与OpenDNS这样的递归提供程序相比），它延长了已经看到问题的用户的停机时间。一般来说，在30分钟内，递归DNS已刷新，到格林尼治标准时间8:00站点恢复在线。两个数据中心未正确执行所有已更正的DNS文件更新。我们仍在调查原因，但我们的猜测是，由于更新影响了大量记录，系统在最初尝试更新时受阻。在格林尼治标准时间8点10分之前，一些网站的请求都返回了不好的结果。因此，欧洲和亚洲的一些访问者可能会在一些站点上看到更长时间的停机时间。我们的系统具有多层冗余，包括在数据中心级别，因此我们在发现问题后立即将这两个数据中心从轮换中移除，并再次让受影响的访问者看到正确的DNS结果。最后两个问题使情况恶化。首先，与我们的正常运营一样，我们当时正在处理两次针对我们的一些客户的中型DDoS攻击。这没什么不正常的，但轮流运行的数据中心减少了两个，这使我们在停止这些数据中心时效率降低，并导致了少量500个错误。然而，这些影响是最小的（在大约12分钟的时间内不到0.001%的流量）。其次，在我们的系统中有一些针对tld的DNS条目，比如新西兰公司本来不应该的。虽然它不是一个经过验证的DNS区域记录，但DNS更新的推送方式导致这些tld下的一些记录也出现了长时间的中断。当我们得到这方面的报告时，我们发现了问题并删除了有问题的条目。好的这件事本身没有什么好处。当系统状态现在为绿色时，我们将在系统状态页上记录事件。一、 与团队其他成员一起，为问题和任何经历过问题的人道歉。我们已经构建了一个能够抵御大多数攻击的系统，但是我们的一个错误仍然可能导致重大问题。这是我们在整个网络范围内出现的第二个重要的停机时间。第一次是一年多以前，也是因为我们自己犯了一个错误。任何一段时间的停工都是我们无法接受的，我们再次真诚地道歉。今后，我们已经增加了几层安全措施，以防止此类事件或类似事件的发生。CloudFlare的技术系统是为了随着时间的推移而设计的，我们的团队本身也是这样。虽然这起事件很糟糕，但我很自豪地看到几乎整个工程、运营和支持团队在凌晨时分在线帮助客户解决问题，并建立安全措施，以防止将来发生类似的问题。今天早上我打算写一篇关于我们新的DNS基础设施的博客文章，所以我将以一点更详细的内容结束这篇文章。如上所述，其中一个主要的好处是DNS更新比以前更快。在过去，DNS文件每隔一分钟左右就被复制一次。现在，我们的整个网络将立即发生变化。虽然昨晚这不是一件好事，但总的来说，我们相信这对我们的出版商是一大好处，使我们成为世界上更新最快的全球权威域名系统。对DNS系统的更新还包括针对我们已经开始看到的新一代DNS定向DDoS攻击的强化。今后，这将有助于我们提供更好的保护，抵御越来越大的攻击。我们的目标是领先于攻击者，并确保CloudFlare上的每个人都有最先进的保护措施来抵御攻击。我再次为你们中因我们的错误而经历停工的人道歉。我们将从中吸取教训，继续在CloudFlare中构建冗余和弹性，以赢得您的信任。