要約

  • APNICは、一方の負荷分散ノードを保守していた際、接続を排出する手順が誤ってもう一方のノードに実行され、障害が発生したと説明した。告知は会員ポータル、レジストリAPI、DASH、複数のRPKI機能など8サービスを影響対象に挙げる。
  • 10月1日の開始時刻14:44から終了時刻15:01までは、UTC+10で表示上17分ある。一方、告知の継続時間欄は15分だ。APNICは保守・フェイルオーバー手順を見直すとしているが、利用者数や新たな安全策の検証結果は示していない。

分析

10月2日付の告知で運用上の核心となるのは、保守する予定だったノードと、接続排出の操作が実際に向けられたノードが異なっていた点だ。APNICは、一方の負荷分散ノードの保守中に、接続を排出する手順をもう一方に誤って実行し、障害につながったと述べている。

影響対象として列挙されたのは、MyAPNIC会員ポータル、registry-api.apnic.net、DASH、通知プラットフォーム、REx、RPKI rsync、RPKIプロビジョニング・公開プロトコル、rsc-verifier.apnic.netの8つ。会員向け、レジストリ、RPKI関連の機能にまたがる。ただし、この一覧はAPNICが影響ありと報告した範囲を示すもので、8サービスすべてが同じ時間に完全停止したことや、内部経路を共有していることまでは示さない。

時間の記録には数値のずれがある。開始は14:44、終了は15:01、いずれもUTC+10と記載され、表示された分の差は17分になる。しかし同じ告知の継続時間欄は15分だ。秒単位の記録や差を説明する注記はない。小さな食い違いでも、公開された事故記録を比較する際にどちらの数字を基準にすべきかは明らかでない。

APNICは、保守とフェイルオーバーの手順をより明確にし、追加の安全策を設けるために見直すとしている。これは見直しの表明であり、新手順が承認、試験、実装された証拠ではない。担当者、期限、操作前に対象ノードを確認する方法、サービスごとの復旧時刻も公表されていない。

事実の境界も保つ必要がある。対象にはRPKIサービスが含まれるが、APNICはROAの古さや誤り、経路への影響、データ消失、セキュリティ事案、番号資源の登録ミスを報告していない。影響を受けた会員や利用者の数も示していない。今回の10月1日の事象は、異なる原因が説明された9月のMyAPNICの2件とは別の出来事であり、共通原因も公表されていない。

内部アドレス、認証情報、トポロジーを明かさずに、保守の対象ノード、排出前の対象確認、事象を閉じたサービス検査、継続時間の算出方法を短く記録することはできる。そうした証拠が出るまで、言えることは限定される。APNICは、誤った対象への保守操作が8つの列挙サービスに及ぶ障害を招き、現在手順を見直していると説明した。

出典