要約

  • RIPE NCCは、主系負荷分散器のネットワークリンクが短く途切れて予備へ切り替わり、設定ミスによって新しいWhois更新接続が読み取り専用DBへ送られたと説明した。既存のアプリケーション接続は主DBに残った。
  • 10月28日の更新失敗時間帯はUTC 11:42–19:40。失敗した逆引き委任要求を後に精査したところ、変更がないか、zonemasterの事前検査で落ちる要求だったため、委任は変わらなかったという。

切替先が書き込み先とは限らない

RIPE NCCの11月3日の事後報告は、短い回線断から始まる。主系の負荷分散器が予備に切り替わった後、新しく作られるWhois更新用のDB接続は読み取り専用DBに向かった。以前からあるアプリケーション接続は主DBにつながったままで、影響を受けなかった。ある更新が通り、別の更新が失敗した理由は、DB全体が不安定だったからではない。接続時に選ばれる経路が分かれていた。

読み取り専用の複製は照会には役立つ。しかし資源登録情報の変更は受け付けられない。予備機のネットワーク応答が正常でも、新規の更新経路がその複製に達すれば、登録業務は成立しない。既存セッションの成功は状況をさらに見えにくくする。古い道で仕事が続くあいだ、新しい道には閉じた窓口が待っていた。

RIPE NCCは10月28日の更新失敗をUTC 11:42から19:40までと報告している。当初の障害告知は処理されない更新と逆引きDNSに関係するオブジェクトに触れたが、経路の誤りは後の報告で明らかになった。公開資料には誤設定の具体的な項目や更新失敗件数、送信方式別の内訳がない。設定差分と接続・処理結果の記録が出れば、どこまで及んだかを測れる。

逆引き委任についてRIPE NCCは追加確認も示した。失敗した要求には変更そのものがないものと、zonemasterの委任前検査に通らないものがあり、いずれも委任を変えなかったという。書き込み経路の障害と、実際に失われた有効な逆引き変更は別の結果である。この報告が立証するのは前者だ。

オブジェクトの結果を読む

RIPE Databaseの処理手順では、提出された各オブジェクトを個別に処理し、結果を応答として返す。応答の説明によれば、SyncupdatesのHTTP 200だけでは個別操作の成功が確定しない。利用者が必要とするのは、意図したオブジェクト変更の結果と登録簿での読み直しだ。緑色の負荷分散器表示は、その代わりにならない。