要約

  • ARIN は 2026 年 8 月 24 日、一部の Whois 照会で空の結果が返る問題を記録した。調査中の更新は 12:43 EDT、解決済みの更新は 13:04 EDT に公開された。
  • 21 分という差は二つの公開時刻の間隔であり、障害の正確な継続時間ではない。登録の削除、具体的な対象プロトコル、利用者の損害も、この記録からは確認できない。
  • 復旧後は疑わしい照会を利用者側で確認する必要がある。取得に失敗した状態を登録の不存在と混同せず、保存した古い回答には取得時点と未確認の状態を残すべきだ。

復旧通知で終わる仕事、終わらない仕事

外部サービスの復旧通知は、止まっていた確認作業を再開するための合図になる。しかし、通知を受け取っただけで、手元にある過去の照会結果まで正しくなるわけではない。

ARIN の公式ステータスページには、8 月 24 日に一部の Whois 照会が空の結果を返したという記録がある。調査中とした更新は米国東部夏時間の 12:43、解決を知らせる更新は 13:04。9 月 3 日に本稿のため確認したページは、全システムが稼働中であると表示していた。

現在進行形の障害を報じているのではない。また、公開された説明には、影響を受けた照会の例、応答コード、原因、利用者数が示されていない。二つの更新の間隔を、そのまま障害の開始から終了までの時間とすることもできない。同日に記載された保守作業と、根拠なく因果関係を結ぶべきでもない。

確認できるのは、限定された照会結果の異常を ARIN が認め、その後に解決を公表したという点だ。その先で考えるべきなのは、異常な結果を受け取った可能性のある利用者が、何を保存し、何を判断したかである。特定の利用者が誤った処理をしたという証拠はない。以下は、この種の障害に備えるための運用上の検討だ。

二択に収まらない照会結果

例えば、登録情報のローカル一覧を定期更新する仕組みを考える。前日には項目があった。当日の照会では利用できるレコードを得られなかった。そこで古い項目を削除扱いにすると、読み取りの成否が、登録そのものの存否に置き換わってしまう。

必要なのは、存在する、存在しないという二つの状態に加え、「今回の照会では確かめられなかった」という状態である。接続上の問題、解釈できない内容、正しく理解された否定的な回答を、すべて空の一覧として次の処理に渡してはいけない。

その違いが失われると、連絡先の選定、資源一覧の作成、顧客の確認などで、根拠の弱い判断が使われる可能性がある。これは八月に実際に起きた被害の説明ではない。照会結果が別の業務へ流れるとき、どこで不確かさを保つ必要があるかを示す例だ。

古い結果を残すだけでも十分ではない。登録が本当に変更されていることはあり得る。保存するなら、いつ取得した回答なのか、現在の状態は未確認なのかを明示する必要がある。最後に正常だった情報は、現在も正しいと確認された情報とは異なる。適切に解釈できる新しい否定回答が得られた場合には、それを受け入れられなければならない。

読み取り経路も証拠の一部

ARIN は Whois-RWSを、データベースにある番号資源、組織、連絡先の情報を公開するサービスとして説明している。ブラウザー、スクリプト、API から利用できる。登録情報の出所が ARIN であっても、取得できなかったという観察だけで登録削除を確認したことにはならない。

従来の WHOIS を定義する RFC 3912は、TCP ポート 43 によるテキストの交換を規定している。サーバーが接続を閉じることは応答の終わりを示すが、登録の消滅を表す共通の機械可読な業務判定まで規定するものではない。

Whois-RWS API の文書には、GET による取得と複数の表現形式が記載されている。主となる既定の形式は XML で、ほかの形式はベストエフォートで提供される。従来の Whois 向けプロキシやブラウザー表示に使う変換処理の説明もある。したがって、要求した形式や解析の結果は診断に必要だ。ただし、これらの記述から今回の原因となった層を特定することはできない。

RDAP では幾つかの応答を明確に区別する。RFC 7480では、肯定的な回答を 200、照会に適切に一致するデータがない場合を 404、解釈できない照会を 400、頻度制限を 429 として扱う。429 を受け取ったクライアントは照会頻度を下げ、Retry-After があれば従うことが推奨される。すべてを空の配列にしてしまえば、サービスが返した有用な区別を利用者側で捨てることになる。

これはクライアント設計の説明であって、八月の応答を再現した結果ではない。事故記録の Whois という表現から、具体的な通信プロトコルは特定できない。RDAP が影響を受けず、独立した代替手段だったとも確認されていない。別の画面から取得できたというだけで、独立した二重確認と呼ぶのは早い。

疑わしい観察を、限られた作業として見直す

利用者が再確認の対象にするべきなのは、自らのログに残る疑わしい照会である。対象の識別子、インターフェース、形式、取得時刻、回答そのもの、または適切に保護した診断用の参照を保持する。公開された二つの時刻は手掛かりになるが、影響範囲を完全に区切るものではない。診断のために連絡先情報を無関係な場所へ複製する必要もない。

復旧後、その対象を限定した確認待ち一覧から、負荷を抑えて再照会する。登録が得られた場合、解釈可能な否定回答の場合、依然として確認できない場合は、別々の結果として扱う。確認待ちを閉じる理由は、結果の照合が済んだこと、または次の対応を明示したことであるべきだ。定期処理の終了だけでは足りない。

ARIN の案内も、Whois の動作上の問題と、記載情報が不正確であるという報告を区別している。問い合わせる側も、どちらを観察したのかを明確にした方がよい。複数の経路へ同時に再試行を重ねれば、確実性より負荷だけを増やすこともある。

空の結果を永久に拒むことが目的ではない。取得条件に見合った意味だけを与え、未確認だったものを改めて確認する。サービスの復旧はその機会を作り、利用者側の照合が手元の未完了の仕事を終わらせる。