2016年10月21日，星期五，从上午08:30到下午1:30 PDT，由于我们的主要DNS提供商Dyn受到DDoS攻击，大约27%的尝试连接到Mixpanel的所有API端点的客户端无法连接。少数客户端无法访问mixpanel.com网站直到10月22日星期六下午2:00decision.mixpanel.com网站直到10月24日星期一上午10:05。我们的移动客户端缓冲数据，因此能够在DNS中断结束后成功地重新提交数据，不会造成永久性的数据丢失。对于web集成，在这段时间内可能有一些数据丢失，尽管我们每周的数据量没有受到显著影响。我们对服务中断感到非常抱歉。上周早些时候，我们进行了一次验尸，并已开始制定行动项目，以使我们在未来更能应对此类事件。这篇文章的其余部分提供了我们的发现和计划的细节。响应时间表星期五上午9:40，我们的内部监测系统显示，我们的数据摄取量异常急剧下降。我们在status.mixpanel.com网站早上9点42分。我们在早上7:00看到Dyn的一条推特，说他们正在调查一起袭击事件，并立即将这两个问题联系起来。我们开始考虑故障转移DNS的选择。周五下午1:20，我们修改了mixpanel.com网站在内部配置和测试后，指向辅助DNS提供商Amazon Route 53。尽管NS记录上有48小时的TTL，但是权威的for.com的gTLD名称服务器几乎立即接受了这个更改，中间递归解析器也紧随其后。广泛使用的公共解析器服务，包括googlepublicdns和OpenDNS，提供了允许服务运营商强制缓存刷新的表单，这些缓存刷新用于Mixpanel的每个域。结果，到下午1:30，每周的活动流量没有明显的差异。与Dyn不同，路由53不允许我们在每个DNS响应中只返回一个地理区域的IP地址的子集，因此我们使用最接近客户端的数据中心的所有Mixpanel IP地址进行响应。这将DNS响应的大小从300字节以下增加到512字节以上。对于大多数客户机来说，这意味着他们的DNS请求（通常在单个UDP数据报中提供）必须通过TCP重新连接到解析程序，以接受更大的响应。一些较老的客户机没有实现IETF提出的TCP重试标准，因此当DNS记录超过512字节时就会失败。周六下午2点，我们减少了api.mixpanel.com网站到29，使响应符合旧客户端所需的512字节限制。星期一早上，我们注意到一些客户同时使用不支持TCP重试和使用的旧DNS客户端decision.mixpanel.com网站，它是api.mixpanel.com网站. DNS响应中的附加CNAME条目将添加32个字节，从而使响应超过512字节的限制。周一上午10点，我们减少了返回的IP地址数量，使之符合该限制，即使在CNAME记录的额外开销存在的情况下，也恢复了对这些客户机的服务。下一步行动我们正在采取以下措施，以提高我们在未来DNS中断时的可用性：彻底记录我们的流量工程最佳实践，包括DNS故障转移过程，并在辅助DNS提供商上维护热备用区域。添加DNS响应大小的自动测试，确保区域推送不会破坏传统的仅UDP客户端。如果您对这起事件有任何进一步的问题，请随时联系Mixpanel支持部门support@mixpanel.com。