2017年＋1s：还是引发了故障，还是程序员背锅

正文

请到「今天看啥」查看全文

客户使用CNAME这种选择时，Cloudflare偶尔要执行查询，使用DNS，查询原始服务器的实际IP地址。它是使用标准的递归DNS自动执行这项操作的。含有导致故障的那个软件错误的正是这个CNAME查询代码。

在内部，执行CNAME查询时，Cloudflare运行DNS解析器，查询来自互联网的DNS记录，以及RRDNS与这些解析器之间的对话，以便获得IP地址。RRDNS跟踪记录内部解析器的性能有多好，并对可能的解析器（我们每个接入点运行多个解析器，以确保冗余性）进行权重选择，选择性能最好的那个解析器。其中一些解析最后在数据结构中记录下了闰秒期间的一个负值。

权重选择代码在稍后被馈送到这个负数，因而引起了恐慌。负数是通过闰秒和平滑处理（smoothing）这两个因素出现在那里的。

程序员在时间方面的错误认识

影响了我们DNS服务的那个错误的根源出在时间不会倒退这一观念上。以我们为例，一些代码想当然地以为：在最糟糕的情况下，两个时间之间的时差总是为零。

RRDNS是用Go编写的，使用Go的time.Now函数来获得时间。遗憾的是，这个函数并不保证单调性（monotonicity）。Go目前并不提供单调的时间源（详情请参阅https://github.com/golang/go/issues/12914）。

在评估用于CNAME查询的上游DNS解析器的性能时，RRDNS含有下列代码：

// Update upstream sRTT on UDP queries, penalize it if it fails

请到「今天看啥」查看全文