要約

  • APNICによると、2026年8月28日19時10分から19時18分（UTC+10）まで、ネットワーク・ファイアウォール1台がハードウェア障害を検知して再起動した。
  • 影響対象には、MyAPNIC、登録API、Orbit、FTP、RPKIのプロビジョニング／発行プロトコル、RPKI rsyncが並ぶ。読み取り、書き込み、非同期タスク、発行、取得では完了条件が異なる。
  • 公開情報は、データ消失、破損、二重更新、セキュリティ事故を示していない。一方、処理の受理、コミット、キュー解消、複数表示の整合性も個別には示していない。
  • 一つの障害IDの下に、未受信、受理済み、確定済み、表示済み、再試行可能、照会継続、未確認を処理種別ごとに記す最小限の収束記録が必要だ。

8分という数字が答えたこと

APNICの8月28日付サービス告知は、19時10分開始、19時18分終了、UTC+10という時間を示す。ネットワーク・ファイアウォールの一つがハードウェア障害を検知し、再起動した。その結果、列挙されたサービスが中断したという。APNICはハードウェア・ベンダーと原因を調べ、同種の事象で中断を減らすため、ファイアウォール間のトラフィック切り替えを改善するとしている。RSSにも同じ時刻と説明が残る。

初動告知としては有用である。原因の範囲、対象、次の対応が簡潔に示されている。8分という短さも重要だ。ただし「影響を受けた」は、8分間ずっと全面停止したという意味ではない。接続拒否、タイムアウト、一部リクエストの失敗、受理後の応答消失、発行の遅延、取得経路の中断は別の状態である。

APNICはそのどれが各サービスで起きたかを公表していない。したがって、事故を大きく見せる推測も、全処理が無傷で終わったという推測も避けるべきだ。

非同期APIでは、切れた接続の先に仕事が残る

APNICの登録API公開時の説明によれば、このAPIは委任情報の取得だけでなく、Whois、逆引きDNS、ROA、route objectの管理にも使われる。つまり、読み取りと状態変更の双方を担う。

更新はすべて非同期のタスク・オブジェクトとして扱われる。送信後、利用者はタスクへのリンクを受け取り、完了結果が出るまで照会する。逆引きDNSと抽象化された経路管理のバッチは、可能な場合にはトランザクションとして反映される。

この設計では、HTTP接続の成否だけで更新の成否を判断できない。障害は、サーバー到達前、受理前、タスク作成後、コミット後だが最終応答前、という複数の位置で起こり得る。

最初なら再送が自然かもしれない。タスクが存在するなら、そのタスクを照会する方が安全である。すでに反映済みなら、同じ意図の再送は解決ではなく新しい操作になり得る。8月28日に二重更新や未完了タスクが生じたという証拠はない。問題は、公開された8分の時計だけでは、どの分岐だったか判断できないことだ。

MyAPNICとの対応関係もある。APNICは、APIで行った経路変更が該当アカウントのMyAPNICに現れ、MyAPNICで行った更新もAPIから見えると説明する。ポータルが再び開いたことは新しい読み取りの成功を示す。しかし、直前のタスクが完了したこと、双方の表示が同時に揃ったこと、処理待ちがゼロになったことまでは示さない。

利用者が必要なのは、「当該時間に更新は受理されなかった」「受理済みタスクは照合済みで、再送せず照会すべきだ」「一部タスクは処理中」「確認不能」のいずれかである。ネットワーク復旧時刻は、その判断を始める時刻にすぎない。

OrbitとFTPは同じ“やり直し”を持たない

Orbitは、APNICコミュニティの連絡基盤であり、メーリングリストを発展させた仕組みと説明されている。ウェブでアーカイブを読む、投稿する、メールで受け取るという経路がある。

アーカイブ閲覧の失敗は再読すればよい。投稿の受付結果が不明なら、再投稿前にアーカイブを確認したい。メール配送の遅れには、また別の終点がある。告知はOrbitを一語で挙げるだけで、どの経路かを示さない。投稿消失を示すわけではなく、重複がなかったことを保証するわけでもない。

FTPは公開データ配布である。APNICのRIR統計交換フォーマットでは、統計ファイルは世界から読め、アクセス制御を必要とせず、最新版を示す持続的なファイル名や検証材料を持つ。

取得に失敗しても、保存されているファイルが壊れたとは限らない。新しい日付版が作成済みでも、ある経路からまだ読めない可能性がある。latestの参照先と日付付きファイルは別々に確認できる。今回そのどれかが起きた証拠はないからこそ、公開状態は「読み取りのみ中断」「発行遅延」「内容不変」「最新版参照を確認」「不明」のように限定すべきだ。

RPKIという一語の内側

APNICのRPKI認証実務声明は、プロビジョニング・プロトコル、発行プロトコル、rsyncによるリポジトリ取得、RRDPによる取得を分けている。資源証明書の発行者と主体、発行者とリポジトリ、リポジトリとリライング・パーティーでは通信の向きも責任も違う。

RFC 6492は資源証明書プロビジョニングの要求・応答を定める。RFC 8181は発行者がリポジトリへオブジェクトを渡す操作を定める。RFC 8182はHTTPS上のRRDPを定める。

今回の告知は「RPKI Provisioning and Publication protocol」と「RPKI rsync」を列挙したが、RRDPには触れていない。ここから言えるのは、名指しされた面で中断があったということだけだ。RRDPが正常だった、停止した、別の障害領域にあった、と読む根拠にはならない。

リポジトリ取得の中断が、ルーターの判断をただちに空にしたとも言えない。検証ソフトウェアは取得したオブジェクトをローカルで検証し、それぞれの周期で後段へ渡す。キャッシュの年齢、オブジェクトの期限、検証器の挙動、経路への影響は公表されていない。

確認項目は役割別でなければならない。プロビジョニング要求に対応する応答は返ったか。発行操作は受理されたか、再試行が必要か。rsyncで公開される集合は意図したリポジトリ状態と一致したか。RRDPは観測対象だったか。分けて問うことは障害を誇張することではなく、RPKIという略語で処理の違いを消さないためである。

速報を遅らせず、収束記録を後から足す

8分のうちに全タスクを照合してから公表せよ、という要求は現実的でない。速報は、利用者が自分のエラーとAPNICの事象を結び付け、不要な原因調査を減らすためにある。ハードウェア・ベンダーとの調査も、その後に続く仕事だ。

APNICは2025年第4四半期の可用性報告で、1分ごとの外部監視と、アクセスログから得る利用者視点の成功率・エラー率を組み合わせ、同じ障害を二重に数えない方法を説明している。到達性と要求結果を異なる観測面として扱う考え方はすでにある。

だから、初報は短いままでよい。内部照合後に、処理種別ごとの収束記録を同じ障害IDへ追加すればよい。

公開してよい最小限の状態

各行には、インターフェース、方向、処理種別を置く。会員から登録への更新、タスク照会、コミュニティ投稿・閲覧、公開ファイルの生成・取得、RPKIプロビジョニング、発行、rsync取得、必要に応じRRDP観測である。

状態は、未受信、受理前拒否、受理済み、コミット済み、ロールバック、保留、指定表示で確認済み、再試行可、照会のみ、観測不能に限定できる。通信路復旧、キュー解消、表示間照合には別の時刻を持たせる。

件数は幅でよい。生の会員要求、オブジェクト内容、内部アドレス、認証情報、機器番号、攻撃に利用できる構成は公開不要である。後の照合で状態が変われば、旧状態と訂正日時を残す。

19時18分はファイアウォール事象の終点である。登録更新の終点は受理と結果が分かった時、発行の終点はリポジトリの判断が分かった時、取得の終点は検証可能な表示を得た時に来る。一つのIDでまとめられるが、一つの時計で意味まで統一してはならない。

出典