在新年的UTC午夜，在Cloudflare的自定义RRDNS软件内部，一个数字变成了负数，而最坏的情况是，它应该一直是零。稍后这个负值导致RRDNS恐慌。这种恐慌是使用Go语言的recover特性捕捉到的。最终的结果是，对某些Cloudflare管理的web属性的某些DNS解析失败。该问题只影响了使用Cloudflare的CNAME DNS记录的客户，并且只影响了Cloudflare 102个数据中心中的少量计算机。峰值时，对Cloudflare的DNS查询大约有0.2%受到影响，而对Cloudflare的所有HTTP请求中只有不到1%遇到错误。这个问题很快就被发现了。受影响最严重的机器在90分钟内修复完毕，修复程序于协调世界时0645分在全球范围内推出。很抱歉，我们的客户受到影响，但我们认为写下根本原因让其他人理解是值得的。关于Cloudflare DNSCloudflare客户使用我们的DNS服务为其域的DNS查询提供权威答案。他们需要告诉我们他们的原始web服务器的IP地址，这样我们就可以联系服务器来处理非缓存请求。它们有两种方法：要么输入与名称相关联的IP地址（例如example.com网站是192.0.2.123并作为A记录输入）或输入CNAME（例如。example.com网站是起源吗-服务器.示例-托管.biz).此图显示了一个测试站点，其中包含theburritobot.com网站和一个CNAME直指赫罗库。当客户使用CNAME选项时，Cloudflare偶尔需要使用DNS来查找源服务器的实际IP地址。它使用标准递归DNS自动执行此操作。正是这个CNAME查找代码包含了导致中断的bug。在内部，Cloudflare运行DNS解析程序来从互联网上查找DNS记录，RRDNS在进行CNAME查找时会与这些解析程序对话以获取IP地址。RRDNS跟踪内部解析器的执行情况，并对可能的解析器进行加权选择（我们为冗余而在每个数据中心操作多个解析器），并选择性能最好的解析器。其中一些分辨率最终在闰秒期间在数据结构中记录了一个负值。后来，加权选择码被输入负数，导致它恐慌。负数是通过闰秒和平滑相结合得到的。程序员相信时间的谎言影响DNS服务的bug的根本原因是相信时间不能倒流。在我们的例子中，一些代码假设两个时间的差在最坏的情况下总是为零。RRDNS是用Go编写的，使用Go的时间。现在（）函数获取时间。不幸的是，这个函数不能保证单调性。Go目前没有提供单调的时间源（参见12914期讨论）。在测量用于CNAME查找的上游DNS解析程序的性能时，RRDNS包含以下代码：//在UDP查询上更新上游sRTT，如果失败则惩罚它如果！start.is零() {rtt:=时间。现在（）.Sub（开始）如果成功&&R代码！= dns.rcodeServer故障{s、 更新（rtt）}其他{//惩罚应该是实际超时的倍数//因为我们不知道好消息应该什么时候到达，//但它不应该让服务器立即退出s、 updateRTT（TimeoutPenalty*s.timeout）}}在上面的代码中，如果时间。现在（）早于start（通过调用时间。现在（）之前）。如果时间推移，这种代码会很好地工作。不幸的是，我们已经将我们的解析器调整为非常快，这意味着它们在几毫秒内响应是正常的。如果，当一个解决方案发生时，时间倒流一秒，那么感知到的解决时间将是负值。RRDNS不仅仅为每个解析器保留一个测量值，它还需要许多测量值并使它们平滑。因此，单次测量不会导致RRDNS认为解析器在负时间工作，但是在几次测量之后，平滑值最终会变为负值。当RRDNS选择一个上游来解析CNAME时，它使用加权选择算法。该代码获取上游时间值并将其提供给Go兰特Int63n（）功能。兰特Int63n如果它的论据是否定的，就会立即惊慌失措。这就是RRDN恐慌的来源。（旁白：程序员对时间还有很多错误的看法）一个字符的修正使用非单调时钟源时的一个预防措施是始终检查两个时间戳之间的差是否为负。如果发生这种情况，在时钟停止倒带之前，不可能准确地确定时间差。在这个补丁中，我们允许rrdn忽略当前的上游性能，如果时间向后跳过，则让它再次正常化。这可以防止负数泄漏到服务器选择代码，这将导致在尝试联系上游服务器之前引发错误。我们应用的修复程序防止在服务器选择中记录负值。重新启动所有RRDNS服务器，然后修复了该问题的任何重复出现。时间轴以下是闰秒错误事件的完整时间轴。2017-01-01 00:00 UTC影响开始2017-01-01 00:10 UTC上报工程师2017-01-01 00:34 UTC问题已确认2017-01-01 00:55 UTC缓解部署到一个金丝雀节点并确认2017-01-01 01:03 UTC缓解部署到金丝雀数据中心并确认2017-01-01 01:23 UTC Fix部署在受影响最大的数据中心2017-01-01 01:45 UTC Fix正在部署到主要数据中心2017-01-01 01:48 UTC Fix正在各地部署2017-01-01 02:50 UTC Fix已在大多数受影响的数据中心推出2017-01-01 06:45 UTC影响结束此图表显示了每个Cloudflare数据中心的错误率（一些数据中心比其他数据中心受到的影响更大）以及在部署修复程序时错误的快速减少。我们部署了修复程序，首先对错误最多的位置进行优先级排序。结论很抱歉，我们的客户受到了这个bug的影响，我们正在检查我们的所有代码，以确保没有其他对闰秒敏感的时间间隔使用。