要約

  • APNICの10月アーカイブには、10月23日04:00 UTCから27日00:00 UTCまでのWHOIS/RDAPレポート92本がそろった。レポートと、ダウンロード内容を照合するMD5ファイルはいずれも、UTC+10表示で10月29日10:16に更新されている。
  • 10月16日の障害告知には終了時刻も継続時間もない。チェックサムは取得したバイト列を照合するが、APNICの公開スキーマは各時間の元ログが完全だったかを示さない。

92本を戻した時刻は、ほぼ一行で読める

まず数字より時刻を見る。月別一覧で92本のレポートとMD5ファイルが10月29日10:16にそろって更新されている。これはUTC+10の表示だ。10月27日の一覧では23日から27日へ飛び、連続した92時間分が見えなかった。対象は10月23日04:00 UTCから27日00:00 UTCまで。4日間、1時間ごとの区間が92本分だ。

ディレクトリの更新欄は、補完が一括で行われたことを示す。該当するレポートと付属の .md5 ファイルは、どれも10月29日10:16という同じ時刻で表示される。これはUTC+10の一覧時刻だ。最初と最後のファイルを直接取得すると、HTTPの Last-Modified はUTCで00:16:28だった。圧縮された2本を展開し、報告された時間帯を確認したうえで、ファイルのMD5をAPNICが公開する照合用ファイルと比べた。先頭は23日04:00–05:00、最後は26日23:00–27日00:00 UTCを扱っている。

最新フィードも更新を続けている。WHOISとRDAPの最新JSONは10月30日23:00から31日00:00 UTCまでをカバーし、ダウンロードした内容は公開MD5と一致した。ファイル単位では、欠けていた時間帯は戻り、時間別公開も現在に追いついている。

だが、障害の記録はその変化を反映していない。APNICの10月16日告知は、ログ処理の問題によりUTC+10の10:00以降の統計が不完全になったと説明する。生成を停止し、問題解決後に対象ファイルを再公開すると記している。終了時刻と継続時間の欄は空白のままだ。サービス更新一覧には告知が残っているが、このWHOIS/RDAP統計障害を閉じる別の記録は見当たらない。

92本のファイルは戻った。READMEはレポートの対象時間、クエリ総数、クエリ種別、ASN数、ASNごとの数値を定義する。公開資料には改訂番号、時間ごとの完全性状態、復旧マニフェストがない。確認した2本のMD5ファイルは取得したファイルと公開値が一致した。各時間にどのログが使われ、影響区間がどの処理で再構成されたかを示す記録は公開されていない。

時間系列を作る人にとって、その違いは実務上のものだ。戻った1時間をグラフや基準値に入れることはできる。時間ごとの修復ステータスが公開されれば、利用者は再掲載されたファイルと完全性を確認した区間を区別できる。92本は戻った。公開資料だけでは、10月16日以降に影響を受けたとされた期間全体の終了を確認できない。

戻った92区間に処理記録がない

APNICが区間ごとのマニフェストを出せば、話はすぐ明確になる。対象のUTC時間、復旧ステータス、レポートを作成した処理の識別ID、現在のチェックサム、障害の終了時刻を並べればよい。まだ不完全な時間は、その行にそう書く。利用者はファイルが戻ったことと、統計の完全性が確認されたことを分けられ、後日同じ系列を再計算できる。

ディレクトリの時刻はファイルの更新時刻を示す。修復台帳には区間ごとの処理ID、状態、障害の終了時刻が要る。APNICは欠けていた時間をアーカイブに戻した。次は、そのデータがどの処理を通ったか記録する番だ。

出典

APNIC 2026年10月16日サービス告知、APNICサービス更新一覧、WHOIS/RDAP統計README、2026年10月アーカイブ、10月23日04:00 UTCのレポートとMD5サイドカー、10月26日23:00 UTCのレポートとMD5サイドカー、APNIC最新統計JSONとMD5サイドカー。