致力于打造中国站长娱乐学习的免费资源站!官方合作QQ:283852481

您当前的位置:首页 > 科技 > 传媒播报

帝恩思解读:都是闰秒惹得祸,都是程序员背的锅。

时间:2017-01-11  来源:站长之家用户   

一秒钟,就能搞个大新闻。

在新年第一天协调世界时(UTC)子夜,在Cloudflare的自定义RRDNS软件内部,一个数字本该在最糟糕的情况下总是为零,结果却变成负数。影响就是,为Cloudflare的一些托管网站提供的一些DNS解析以失败告终。

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

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

640.webp (2).jpg

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的安全方面的考虑,应当更全面且谨慎。

第一梯队.jpg

此前,帝恩思作为国内首屈一指的域名服务商进行过分析,目前中国处于攻击目标地的“第一梯队”,万不可掉以轻心。

因为DNS作为当前全球最大最复杂的分布式层次数据库系统,由于其天生的开放性、庞大性、复杂性等特点,在设计之初就对于安全性考虑不足。利用DNS基础架构来制造DDoS攻击其实相当容易——控制大批僵尸网络利用真实DNS协议栈发起大量域名查询请求。

谁知道意外和明天哪个先来。未雨绸缪,做好安全措施,找好DNS备份服务商才是真理。


精彩广告