一秒钟，就能搞个大新闻。
在新年首先天协调世界时（UTC）子夜，在Cloudflare的自定义RRDNS软件内部，一个数字本该在最糟糕的情况下总是为零，结果却变成负数。影响就是，为Cloudflare的一些托管网站提供的一些DNS解析以失败告终。
原因：程序员在时间方面的错误认识
影响Cloudflare的DNS服务的错误的根源出在时间不会倒退这一观念上。一些代码想当然地以为：在最糟糕的情况下，两个时间之间的时差总是为零。
RRDNS是用Go编写的，使用Go的time.Now()函数来获得时间。遗憾的是，这个函数并不保证单调性（monotonicity）。
RRDNS根本不为每个解析器保留单一的度量指标，它拿来许多度量指标后，对它们进行平滑处理。所以，单一的度量指标不会引起RRDNS认为解析器在负时间内工作，但是经过几个度量指标后，经过平滑处理的值最终会变成负值。
当RRDNS选择上游解析CNAME时，它使用一种权重选择算法。代码拿来上游时间值后，将它们馈送到Go的rand.Int63n()函数。如果变量是负值，rand.Int63n就会立即恐慌。这就是造成RRDNS恐慌的根源。
另外，程序员在时间方面还有其他的许多错误认识。
故障过程：记录闰秒期间一个负值
客户使用CNAME这种选择时，Cloudflare偶尔要执行查询，使用DNS，查询原始服务器的实际IP地址。它是使用标准的递归DNS自动执行这项操作的。含有导致故障的那个软件错误的正是这个CNAME查询代码。
在内部，执行CNAME查询时，Cloudflare运行DNS解析器，查询来自互联网的DNS记录，以及RRDNS与这些解析器之间的对话，以便获得IP地址。RRDNS跟踪记录内部解析器的性能有多好，并对可能的解析器（我们每个接入点运行多个解析器，以确保冗余性）进行权重选择，选择性能较好的那个解析器。其中一些解析最后在数据结构中记录下了闰秒期间的一个负值。
权重选择代码在稍后被馈送到这个负数，因而引起了恐慌。负数是通过闰秒和平滑处理（smoothing）这两个因素出现在那里的。
总结：找好DNS备份服务商的重要性
跨了个年， 1S，Cloudflare的DNS解析就废了不少。不过，短短数月，DNS方面的突发事件，都是有目共睹的。猝不及防的结果接踵而至，各种事故原因也是层出不穷。
除了此次的闰秒事故，特别在DNS的安全方面的考虑，应当更全面且谨慎。
此前，帝恩思作为国内排名靠前的域名服务商进行过分析，目前中国处于攻击目标地的“首先梯队”，万不可掉以轻心。
因为DNS作为当前全球比较大最复杂的分布式层次数据库系统，由于其天生的开放性、庞大性、复杂性等特点，在设计之初就对于安全性考虑不足。利用DNS基础架构来制造DDoS攻击其实相当容易——控制大批僵尸网络利用真实DNS协议栈发起大量域名查询请求。
谁知道意外和明天哪个先来。未雨绸缪，做好安全措施，找好DNS备份服务商才是真理。
（推广）