今天，在21:00 UTC之后不久，在我们的内部操作聊天中，我们的一位高级支持人员发出了一条可怕的消息："正在获取DNS解析错误support.cloudflare.com"，同时自动监测显示出问题。此后不久，我们看到了来自不同客户（但不是所有人）的警报和反馈报告"1001错误"，这表明CloudFlare后端存在DNS解析错误。不用说，我们的运营和工程团队立即对此做出了压倒性的回应，因为我们没有任何改变，也没有其他异常迹象。在调试过程中，我们能够识别出受影响站点的共同特征，这些站点基于CloudFlare的CNAME用户，而不是完全托管在CloudFlare上的完整域，具有讽刺意味的是，它包括我们自己的支持站点，support.cloudflare.com. 当用户（通过CNAME）指向某个域而不是向我们提供IP地址时，我们的网络会解析该名称——如果DNS提供商有问题，显然无法连接。（我们的状态页https://www.cloudflarestatus.com/已断开网络，未受影响）。然后，我们在调查为什么只有某些域有问题是上游DNS的问题？测试他们的域名是否可以在互联网上解析（他们曾经是）添加了一个令人困惑的数据点。最终，中断被确定为另一个主要的DNS运营商Dyn，他们自己的DNS配置有问题。(https://www.dynstatus.com/incidents/4sbm48rdsdbq)因特网由许多网络组成，由世界各地的公司、组织、政府和个人运营，所有这些网络都使用一套共同的协议和商定的政策和行为进行合作。这些系统以多种方式进行互操作，有时完全不明显。共同的目标是为最终用户提供服务，让他们交流、享受新服务、共同探索。当一家供应商出现技术问题时，它可能会在整个互联网上层出不穷，而用户并不清楚哪一块被破坏了。幸运的是，即使公司是竞争对手，互联网的精神也是为了用户的利益而合作。一旦我们发现了这个问题，我们立即联系了戴恩，并转达了我们所知道的，并与他们合作解决了这个问题，造福于所有人。我们暂时采取了一些变通办法来解决这一问题，并希望潜在的困难能够很快得到解决。最新消息：Dyn的好员工发布了一个简短的解释，解释了在他们的命名服务器上发生了什么。