Summary

  • RIPE NCCは10月28日19:40 UTCまで、データベース更新と逆引き委任の断続的な失敗を記録した。
  • 事故ページは20:32 CET（19:32 UTC）に解決と表示する。10月30日の調査では、失敗要求は委任を変更しない内容だった。

RIPEのステータスページは当初、進行中のサービス障害を伝えた。RIPE Databaseの一部更新が処理されず、一部のドメインオブジェクトにも影響して、逆引きDNSサービスに波及していた。障害時間は10月28日11:42 UTCから19:40 UTCまで。RIPE NCCは修正を適用して監視し、中央ヨーロッパ時間20:32に解決済みとした。

10月28日の二つの時刻は同じ基準にそろえる必要がある。欧州委員会の2026年夏時間日程では10月25日に夏時間が終わっているため、20:32 CETは19:32 UTCとなる。RIPEのステータス履歴は影響期間の終了を19:40 UTCと記録する。解決時刻は記載された終了時刻より8分早い。

2日後、公開記録は結果を細かくした。失敗した要求を詳しく調べたところ、逆引き委任を変更するものは一件もなかったという。一部はそもそも変更内容を含まず、残りはZonemasterの事前委任チェックに通らなかった。更新経路は不安定だったが、調査対象の要求は委任記録を変えるための検査を通過していなかった。

ここがこの記事の焦点だ。処理が中断しても、処理が変えるはずの状態まで変わったとは限らない。RIPE NCCによれば、逆引き委任の作成・更新・削除は断続的に失敗した。一方、後日の確認によれば、失敗した要求は委任を変える内容ではなかった。公開記録は両方を示すが、それぞれの要求数は明らかにしていない。

データベース更新が19:32と19:40 UTCのどちらで再開したか、RIPE NCCは明らかにしていない。時刻をUTCで統一した訂正があれば、表示上のずれか、影響期間が終わる前の解決扱いかが判明する。

時系列の記録は有用だ。20:04 CETに、RIPE NCCは処理されない更新と逆引きDNSに影響するドメインオブジェクトを報告。20:23には修正を適用し監視中とし、20:32には解決済みとした。10月30日、要求単位の説明が追加された。最初の3件はサービス復旧を記録し、最後の説明は登録状態への影響を限定している。

時系列は更新失敗、修正と監視、要求単位の確認へと進む。有効な要求の再試行・再処理結果を公表すれば、サービス復旧後に作業が残ったか分かる。

記録：RIPE NCCの障害時系列；RIPE NCCの状態履歴と10月30日の更新；欧州委員会の2026年夏時間日程。