帝恩思解读 | 2017跨年：都是闰秒惹得祸，都是程序员背的锅。
时间 : 2017-01-10 编辑 : DNS智能解析专家
在新年第一天协调世界时（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.COM|美国半个互联网近崩溃，DNS安全引发企业如何思考
DNS.COM|凤凰新闻遭遇今日头条流量劫持，通过劫持DNS实现？
DNS.COM|BIND最新漏洞导致DOS攻击，POC大规模流出
除了此次的闰秒事故，特别在DNS的安全方面的考虑，应当更全面且谨慎。
此前，帝恩思也进行过分析，目前中国处于攻击目标地的“第一梯队”，万不可掉以轻心。
因为DNS作为当前全球最大最复杂的分布式层次数据库系统，由于其天生的开放性、庞大性、复杂性等特点，在设计之初就对于安全性考虑不足。利用DNS基础架构来制造DDoS攻击其实相当容易——控制大批僵尸网络利用真实DNS协议栈发起大量域名查询请求。
谁知道意外和明天哪个先来。未雨绸缪，做好安全措施，找好DNS备份服务商才是真理。
