要約

  • RIPE Whois 1.124は履歴版をプレーンテキストで返す機能を加えた。返るのはフィルター処理後の履歴オブジェクトであり、当時送られた更新要求そのものの保管庫ではない。
  • 調べた実装では、テキストの本文は構造化応答に履歴版番号を設定する処理より先に返る。保存には照会先と版番号、表示形式の情報も必要だ。ただし、この分析は本文の経路に限られ、すべての応答ヘッダーを調べたものではない。

履歴の内容をテキストファイルに保存する。後日開いても、オブジェクトのキーや説明は読める。しかし照会のURIを残していなければ、そのファイルがどの版を、どの条件で取得したものかをどう確かめるのか。これは想定上の保存場面であって、今回見つかった誤った証拠提出の事例ではない。RIPEの新しい履歴応答は、こうした記録管理の問題を具体的な実装として見せる。

Whois 1.124の公開説明には、履歴版のREST APIがプレーンテキストに対応したことが記されている。GitHubのリリース公開日は2026年8月12日。公式のリリース記録は、候補版を8月13日、本番への配備を8月27日としている。この記事は9月にその変更を検討するもので、9月の新リリースを報じてはいない。現在の全インストールの版も確認していない。根拠は固定されたリリースのコードと公式文書であり、本番サービスへの照会結果ではない。

テキスト形式を選ぶ理由はある。RPSLはネットワーク運用者が直接読むためにも使われ、余分な包みがなければコマンドラインでの処理や差分の比較が簡単になる。使いやすい表示が、同時に一式の証拠記録である必要はない。問題は、利用者がその違いを意識しないまま保存する場合だ。

版の指定には照会そのものが関わる。WhoisVersionServiceは、選択した履歴版に対してSELECT_TYPESとSHOW_VERSIONを使う問い合わせを組み立て、後者に要求された履歴版番号を渡す。処理側はそれに対応する過去のRPSLオブジェクトを選ぶ。オブジェクト内の日付やremarksにも意味はあり得るが、応答の枠組みに置かれる版の識別子とは別物だ。

選ばれた履歴オブジェクトは、そのまま昔の入力を再送するものでもない。VersionQueryExecutorは、要求された版を返却用のオブジェクトに包む前に、メール、認証、changed、個人情報に関するフィルターを適用する。「履歴版」とは、この規則の下で返せる過去のオブジェクトだ。更新に使われたHTTP要求やメール、内部の全情報を無削除で復元するという契約ではない。

フィルターにはプライバシーや機密性を守る理由がある。それを履歴の破損と呼ぶのは行き過ぎだ。各フィールドが必ず変わるとも、ある返却内容が当時の提出テキストと偶然一致しないとも、この記事は主張しない。サービスの機能から、原始的な更新取引の保存を保証したことにはならないという区別である。

表示形式の分岐は、その後に現れる。Acceptにtext/plainを含む要求では、サービスがgetRpslObject().toString()を返す。構造化用のマッパーを動かし、WhoisObject.setVersionで歴史上の版番号を設定するより前の戻りである。この本文経路は、構造化応答が明示的に版番号を設定するその処理を通らない。

ここから「どのヘッダーにも版の情報がない」とは言えない。この記事はすべてのインターセプターやプロキシを点検していない。要求URIには対象と指定版が残り得る。URIと本文を一緒に保存すれば、テキスト形式だから必ず関連づけが失われるわけではない。実装上の本文の境界と、応答全体の主張を混同しないことが大切だ。

構造化の経路では、解釈済みのunformatted引数を属性マッパーへ渡し、履歴オブジェクトの版を設定する。外側にはサービスのソフトウェア版、エラー、利用条件などもある。歴史上のオブジェクト版と、サービスを実行するソフトウェア版は、別の問いに答える。「何番目の修訂を見たか」と「どの実装で応答を作ったか」を一つの版欄にまとめてはいけない。

unformattedも「元の要求を取り戻す」という意味ではない。この経路では構造化属性のマッピングに作用する。テキスト応答はそのマッパーより前に返り、履歴オブジェクトに先ほどのフィルターを掛ける処理も取り消されない。更新メールの原文や提出者の権限を証明するスイッチではない。

保存方法の改善は、大げさなものではなくてよい。要求URI、データベースのsource、オブジェクト型とキー、指定した履歴版、Acceptとunformattedの値、取得日時、関係するヘッダー、保存形式とそのハッシュを本文に添えて残す。これは利用者への記録上の提案で、RIPEが新たに義務づけた条件ではない。ファイル名と担当者の記憶だけに頼らないのが要点だ。

ハッシュは保存したバイト列が変わったかを確かめる。残さなかった要求条件や、当時の承認を復元しはしない。将来、表示やフィルターの規則が変われば、同じ履歴版から見えるバイト列が違う可能性はある。それは検討すべき場面であり、今回観測した改ざんや資源の変更ではない。

プレーンテキストの追加は、運用上の便利さをもたらす。そこから更新時の権限、原文、資源の権利まで完全に証明されたとするのは、サービスが引き受けていない仕事を載せることになる。本文を軽くするなら、その照会情報をどこに残すかは利用者が決めておく必要がある。

出典

  1. RIPE Whois 1.124のリリース説明
  2. RIPE Databaseの公式文書とリリース記録
  3. 固定コミットのWhoisVersionService
  4. 履歴版の実行処理とフィルター
  5. サーバー側の属性マッパー
  6. 構造化オブジェクトのマッパー
  7. 履歴RPSLを保持する返却オブジェクト