g.root-servers.netで何が起こっていますか？

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をチェックしました。これは、ルートサーバーの最新のリストであり、IPアドレスは正しいです。私は常に、これらのルートサーバーはダウンタイムが発生しないほど冗長であるという印象を受けていました。http://root-servers.orgによると、サーバーが配置されている場所は世界中に6か所あるため、私はその仮定に間違いないと思います。

私の質問はg.root-servers.net.、他のすべてのものと何らかの形で異なるのか、特別なのか、
そして何らかの理由でそれからDNS応答を受け取らないことになっているのかどうかです。

domain-name-system

— ダニエル
ソース

Gルートは米軍によって運営されています。

— マイケルハンプトン

それで、米軍だけがそれにアクセスできます、または、あなたは私に何を伝えたいですか？

— ダニエル

何が違うのか、それについて特別なのか尋ねました。

— マイケルハンプトン

neither responds to requests, nor responds to pings-Pingは、ターゲットから応答を取得する必要があることがわかっている場合にのみ有用なツールです。pingに応答しないということは、応答を取得する必要があると考えることを意味します。判明したように、他のすべてのルートサーバーはpingに応答するため、g.root-servers.netも同様にすべきであるという非常に安全な前提ですが、それでもそれは前提です。pingを使用するのは、ターゲットが応答する必要があることが確実にわかっている場合のみです。

— joeqwerty

FWIW、g.rootサーバーは、停止中にTCP over DNSリクエストに応答していました-使用できなかったのはUDPのみでした。

— オリオン座ゼータ星

回答:

私は常に、これらのルートサーバーはダウンタイムが発生しないほど冗長であるという印象を受けていました。http://root-servers.orgによると、サーバーが配置されている場所は世界中に6か所あるため、私はその仮定に間違いないと思います。

文書化されていないGの停止がなかったとしても、それは間違った仮定です。

エニーキャストIPアドレスは複数の物理サイトを表す場合がありますが、ある地域での悪用イベントが他の地域の障害にカスケードすることは望ましくありません。サイトが破損した場合、そのトラフィックは別のサイトに移動しません。
ルートサーバーに向けられた悪用が存在する共有ネットワークリンクは、ルートサーバーにより近いインフラストラクチャが行う前に非常にうまく停止する可能性があります。

最後に、人間の要素があります。Gは全面的に下落しましたが、現時点では公式に明らかにされた理由はありません。このタイプの広範囲にわたる障害は、通常、中央管理における意図的なアクションまたは壊滅的な障害を指します。

Serverfaultのユーザーはルートサーバーの管理者ではないため、最善の策は公式の声明に注意することです。一方、上記のリンクは、Gの完全な停止があったことを示すのに十分です。1つのルートがダウンしても、全体像に大きな影響がないため、インターネットは動作し続けました。

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

— アンドリューB
ソース

昨日の午後、Ripeの誰かと会議に出席しました。彼女が問題を示してからの最初の印象は、ルートサーバーがファイアウォールの設定ミスに苦しんでいたことです。

私が気づいたこと：

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の応答は停止しました。
すべてのRipe Atlasプローブが同じ問題を報告しました。問題は1つの地域に固有のものではありませんでした。
ネットワークへのBGPルーティングは問題ありませんでした。問題ありません。

UDPが機能せず、TCPが機能したという事実は、誰かが特定のサイズ以上のUDPパケットをブロックしようとしたことを示唆しています。

停止中に、512バイトを超える回答サイズのテストだけでなく、いくつかのテストを行い、すべてのUDPテストが失敗しました。

— ヤン・ヒューゴ・プリンス
ソース