我刚刚发现, 192.112.36.4
( g.root-servers.net.
)既不响应请求,也不响应ping。
. 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
我查了http://www.internic.net/domain/named.root ,这是一个up2date根服务器列表,IP地址是正确的。 我总是觉得这些根服务器是冗余的,不可能发生停机。 根据http://root-servers.org ,世界上有六个服务器所在的地点,所以我认为我对这个假设是正确的。
我的问题是如果g.root-servers.net.
与其他所有人有所不同,
如果因为任何原因我不应该得到它的DNS响应?
我总是觉得这些根服务器是冗余的,不可能发生停机。 根据http://root-servers.org ,世界上有六个服务器所在的位置,所以我认为我对这个假设是正确的。
即使没有G的无证中断,这是一个不正确的假设:
最后,我们有人的因素。 G 全线下跌,但目前还没有正式披露的原因。 这种types的普遍失败通常指中央行政部门的蓄意行为或灾难性失败。
由于Serverfault的用户不代表根服务器的pipe理员,所以最好的办法就是注意一下正式的声明 。 与此同时,上面的链接足以certificateG的总中断。互联网继续运行,因为一个根的下降不会在更大的情况下产生重大的影响。
从DoD NIC更新:
Regarding yesterday's G-root outage: Like many outages, this one resulted from a series of unfortunate events. These unfortunate events were operational errors; steps have been taken to prevent any reoccurrence, and to provide better service in the future.
https://lists.dns-oarc.net/pipermail/dns-operations/2016-April/014765.html
我昨天下午在一个会议上和一个人在一起,她给我看的问题之后,我的第一印象是根服务器在防火墙上configuration不当。
我注意到的事情:
UDP不起作用,TCP工作的事实表明,有人试图阻止UDP数据包超过一定的大小或类似的东西。
在停电期间,我做了几个testing,所有的UDPtesting都失败了,不仅testing的答案大小超过了512字节。