g.root-servers.net发生了什么？

我总是觉得这些根服务器是冗余的，不可能发生停机。 根据http://root-servers.org ，世界上有六个服务器所在的位置，所以我认为我对这个假设是正确的。

即使没有G的无证中断，这是一个不正确的假设：

• 任播IP地址可以代表多个物理站点，但是一个地区的滥用事件在其他地方的级联失败是不可取的 。 如果一个网站扣，这个stream量不会被转移到另一个。
• 共享的networking链接，其中存在针对根服务器的滥用情况可能会在更靠近根服务器的基础设施之前阻塞。

最后，我们有人的因素。 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不当。

我注意到的事情：

• TCP响应工作正常。 （ https://atlas.ripe.net/dnsmon/group/root?dnsmon.session.color_range_pls=0-66-66-99-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112 .36.4＆dnsmon.zone = root＆dnsmon.startTime = 1460573400＆dnsmon.endTime = 1460649600＆dnsmon.ipVersion = both＆dnsmon.isTcp = true ）
• UDP响应已经死了。
• 所有成熟的Atlas探针都报告了同样的问题。 这个问题不是特定于一个地区的。
• BGP路由到networking就好了。 那里没有问题。

UDP不起作用，TCP工作的事实表明，有人试图阻止UDP数据包超过一定的大小或类似的东西。

在停电期间，我做了几个testing，所有的UDPtesting都失败了，不仅testing的答案大小超过了512字节。