要約

  • RIPE 93で公開されたRootVizの発表によると、2026年1月22日から26日にかけ、約2000台のRIPE AtlasプローブでL-Root宛てIPv4測定がタイムアウトした。
  • 22日の二つの10分間を比べると、1773台が事象発生中だけ応答を得られなかった。以前利用していた任意配信拠点には他のネットワークから到達でき、発表者は通信経路側の問題と結論づけた。

「Lが赤い」。ここまでは画面が教えてくれる。次に必要なのは、赤くなった場所を探す地図だ。RootVizのRIPE 93発表資料は、1月の調査でその地図を手作業で描いた経緯を示している。

1月22日から26日まで、L-RootへのIPv4測定では約2000台のプローブにタイムアウトが生じた。IPv6と他のルートサーバー識別子は同じようには変動しなかった。22日04:00～04:10 UTCと13:00～13:10 UTCの比較では、後者だけで1773台が応答を得られなかった。これは観測地点の数であり、名前解決に困った利用者数ではない。

RootVizは既存のRIPE Atlas測定を、もっと広い角度から見えるようにする。ネットワークスタックが稼働するプローブを選び、サーバー識別子の食い違う応答を除いたうえで、30分ごとのタイムアウト台数を表示する。5月6日付の比較では、DNSMONのアンカー999台・109か国に対し、全プローブは1万4528台・180か国だった。RIPE Atlasの測定一覧では番号10308をL-Root宛てIPv4 UDP測定として公開している。観測点を増やすと異常はよく見える。原因まで自動で見えるわけではない。

研究者は影響を受けたプローブが直前に到達していた任意配信拠点をたどった。事象発生中も別のネットワークからその拠点に届いていた。経路追跡やBGPの確認を重ね、発表は問題を途中のネットワークに位置づける。一月の件について、原因となった単独の通信事業者を確定したとは述べていない。ICANNはL-Rootの運用主体だ。だからこそ、表示名と修理担当を一緒にしない記録が要る。

事故票にはIPv4とIPv6の別、影響を受けたプローブ、比較対象のルート識別子、拠点の到達状況、経路の証拠を並べたい。発表によれば、異常検知の後、これらを照合するのに数時間の手作業が必要だった。最初の通知で決めつければ、パケットが通る別会社の道まで、名前の見えやすい運用者が背負うことになる。

原資料：RIPE 93発表、RIPE Atlasの内蔵測定、ICANNのルートサーバー説明。