上周五，受欢迎的DNS服务Dyn遭受了三波DDoS攻击，首先影响到美国东海岸的用户，后来影响到全球的用户。热门网站（其中一些也是Cloudflare的客户）无法访问。虽然Cloudflare没有受到攻击，但Dyn/Cloudflare的联合客户受到了影响。几乎在Dyn受到攻击时，我们就注意到边缘计算机上的DNS错误突然增加，并提醒我们的SRE和支持团队Dyn有麻烦了。支持部门已经准备好帮助联合客户，我们开始详细研究Dyn中断对我们系统的影响。内部的一个直接问题是，由于我们的DNS服务器无法访问Dyn，它们将消耗等待超时和重试的资源。我问DNS团队的第一个问题是："我们看到DNS响应延迟增加了吗？"紧接着是"如果情况变得更糟，我们有可能吗？"。令人高兴的是，对这两个问题的回答（在团队分析了情况之后）都是否定的。tracyshaun的CC BY-SA 2.0图像然而，这并不意味着我们没有什么事可做。操作像Cloudflare这样的大规模系统来处理不断变化的互联网本质意味着总有一些东西需要学习。早在2015年7月，Dyn就发生了一次宕机事件，这也影响到了我们的一些客户，我们改变了对所谓基础设施DNS记录的处理方式，以防止任何提供商出现类似问题，影响Cloudflare。根据我们上周五了解到的情况，我们正在对内部DNS基础设施进行一些更改，以便在主要提供商出现问题或停机（无论是否由DDoS引起）时，它的性能会更好。为了理解这些变化，我们可以看看DNS的作用以及我们在周五看到的情况。对DNS有点了解域名系统（DNS）为Internet提供地址簿服务。它负责将我们输入到web浏览器中的友好、可读的域名转换为网站的IP地址。让我们浏览一个示例web请求的生命周期，看看DNS在其中扮演了什么角色。我们可以先在浏览器中输入网址，https://www.cloudflare.com/。浏览器将这个名称转换成一个IP地址，这样它就可以联系到承载页面的服务器，它将使用DNS来完成这项工作。我们可以使用dig命令行工具自己进行这些DNS查询，以查看返回的值。$挖网站A...；；问题部分：;。在一个；；答案部分：。A 198.41.215.162中的10。A 198.41.214.162中的10DNS数据模型分为两个核心概念，名称和记录。这里的名字是网站我们查询的记录类型是A，它用于存储IPv4地址。还有其他类型的记录用于存储其他类型的数据，例如IPv6地址的AAAA记录。从上面的答案可以看出，有两个IPv4地址；浏览器选择其中一个来使用。DNS中的记录也有一个关联的TTL，它定义了数据应该缓存多长时间，这些记录的TTL为10秒。这意味着浏览器可以存储这些信息，并在接下来的10秒内跳过对域的进一步DNS查询。对于Cloudflare客户，答案将包含我们的选播IP，而不是源IP（web托管提供商的IP地址）。然后浏览器将向我们发送请求，我们将提供缓存中的内容或将请求代理到原始web服务器。在Cloudflare上配置源有两种常见方法。第一种方法是指定A和AAAA记录，它明确地为我们提供来源的IP地址。在这种情况下，我们的网络提前知道在哪里可以联系到原点，所以不需要进一步的DNS解析。例如，如果网站使用Cloudflare，并在Cloudflare控制面板中指定2001:db8:5ca1:ab1e作为源服务器的IP地址，我们可以直接连接到源服务器来检索资源。另一种方法是使用CNAME，它是指向另一个DNS名称的指针。当我们的服务器接收到一个使用CNAME配置源的请求时，我们必须执行外部DNS查找，以将CNAME的目标解析为IP地址。根据在CNAME记录上定义的TTL，缓存此信息。在这种情况下，我们提供内容（不在缓存中）的能力完全依赖于外部DNS查找来将CNAME解析为IP。例如，假设网站在Cloudflare控制面板中设置了指向server11的CNAME。myhostingprovider.biz有必要查找server11的IP地址。myhostingprovider.biz在联系源服务器之前。在许多情况下，CNAME的目标由第三方DNS提供商处理。如果第三方提供商无法回答我们的查询，我们将无法将该域解析为源IP，也无法为请求提供服务。周五的Dyn断电是什么样子正如戴恩在讨论DDoS攻击时所说，有三种截然不同的浪潮。对于Cloudflare来说，在两个时期内，我们的内部DNS查询错误率急剧上升。第一次攻击于协调世界时1110开始，主要影响美国东海岸的DNS解析。这张来自我们监控系统的世界地图显示了Cloudflare数据中心，其中DNS错误率由于Dyn中断而急剧上升。地图上的绿点是未受Dyn DDoS影响的Cloudflare数据中心。最大的影响发生在美国东海岸，尽管这次袭击在新加坡和欧洲一些地区造成了连锁反应。这很有可能是因为互联网的架构与地理位置并不直接一致。由于海底电缆或关于如何路由交通的决定，物理上完全不同的地点有时在互联网上显得"很近"。该图表显示了受停机影响的每个Cloudflare数据中心的DNS错误率。很有可能看到攻击迅速增加，然后一直持续到戴恩能够对付它。当天晚些时候，袭击者以更大的武力卷土重来，在世界范围内产生了影响。此图显示Cloudflare数据中心看到错误，因为Dyn无法访问。正如你所见，几乎整个地球都受到了影响（除了我们在中国的位置；我们将回到下面的原因）。再一次，我们可以看到攻击在协调世界时1550时加速并持续一段时间。Dyn报告说，攻击在协调世界时1700时被完全缓解。上周五晚些时候，Media和Dyn报告了第三波攻击，但Dyn立即迅速缓解了这一波攻击，因此它对Cloudflare保护的网站和应用程序没有任何影响，也没有出现在我们的系统中。为什么中国没有受到影响在对戴恩的攻击最激烈的时期，我们在中国的地点几乎完全没有受到影响。这是因为我们在中国处理域名系统的方式有点不同。为了应对中国国内时而波动的网络状况，我们的数据中心配置为将源服务器的DNS记录缓存在我们的服务器中的时间比世界上其他国家的更长。这种缓存意味着，即使Dyn已经关闭，无法从任何地方（包括中国）访问，我们仍然为在我们的中国服务器上使用Dyn的站点缓存DNS记录。因此，我们能够访问源服务器并继续提供内容。在上面的地图上显示为绿点。不幸的是，长时间保留DNS记录有一个缺点：如果我们的客户更改了其来源的DNS记录，我们将继续使用旧的DNS记录和IP地址。这可能导致停机或服务质量差。理想的系统会频繁地重新检查DNS记录，以便快速反映更改，但是如果上游DNS提供者不可用（因为攻击或其他中断），它可以使用它缓存的DNS记录。这样做被称为"在重新验证的同时提供过期服务"。我们的上游DNS解析程序将缓存频繁检查更改的记录。如果上游DNS不可用，我们将继续从缓存提供服务，直到有可能刷新DNS记录。我们正在测试和推出这一变化，并期望这将大大减少类似于Dyn DDoS事件的影响，对于所有使用CNAME的DNS记录并依赖第三方DNS提供商的客户来说。结论互联网是一个共享空间。因为公司、员工和机构一起工作，我们有一个全球联网的网络，让我们几乎可以在任何地方工作和娱乐。合作意味着我们在标准和互操作性方面共同努力，以保持网络的运行和发展。但是互联网是非常复杂的，就像很多事情一样，魔鬼在细节上，运营互联网基础设施是一个不断改进的过程。尽管dynddos对许多不熟悉互联网运作方式的人来说很可怕，但这样的攻击导致了一个更强大的网络。正如Cloudflare正在对其软件和配置进行更改一样，网络上的其他公司也在进行更改。我们一直在寻找有兴趣的人，使DNS和互联网更好地为每个人。在这里可以找到工作。