要約

  • RIPE NCCは10月28日20時04分CETにWHOIS更新の断続的な失敗を調査し、20時23分にRIPE Databaseを正常表示へ戻し、20時32分に障害を解消した。
  • 公開された時系列はサービスの復旧を示すが、その間に送られた個々の変更が受理されたかどうかは示さない。

緑に戻った表示を見る人にも二種類いる。これからデータを送る人と、表示が赤かった間に送ってしまった人だ。後者にとって、サービスの復旧時刻は答えの半分でしかない。

RIPE NCCの障害ページは、10月28日の事象を「WHOIS更新の断続的な失敗」と呼ぶ。公開されている事故データでは、CETの20時04分48秒に調査、20時23分24秒に修正後の監視、20時32分00秒に解消となった。RIPE Databaseの構成要素は調査時に「部分停止」とされ、監視段階で「正常」に戻った。事故全体には重大な影響という区分も付いている。原因、影響を受けた更新手段、失敗した送信数は記載されていない。この三つの時刻は発表の記録であり、各利用者の失敗が続いた時間ではない。

RIPE Databaseの受領通知の説明を読むと、なぜ個別確認が要るかが分かる。一度の送信には、その中の各オブジェクトの結果をまとめた通知が返る。SyncupdatesではHTTP 200でも処理されたメッセージ中の一件が失敗しうる。成否は要約欄で読む。REST APIの返答形式は別だ。今回どの経路が影響を受けたかを、障害ページは特定していない。

さらにオブジェクト処理の仕様では、同じ送信に含まれるオブジェクトも個別に処理される。同期HTTP接続が切れた後に処理が完了し、その接続で通知を受け取れない場合もある。応答がなかったという理由だけで再送すれば、既に処理された変更の扱いを見誤る。送信内容と返答を保管し、権威ある現在の登録内容を照合する順番が先だ。

RIPE NCCはサービス復旧を告げた。登録簿を使う側に必要な次の情報は、どの更新経路が影響を受け、応答のない送信をどう扱うべきか。緑のランプは個々の受付印にはならない。