要約

  • RIPE Database 1.124は2026年8月27日に本番導入され、NRTMv3サーバーが無効なオブジェクトをスキップする変更を含んだ。
  • スキップは可用性を守り得るが、その後の更新が届くことだけでは、権威サーバーが検討した内容をミラーがすべて受け取ったとは証明できない。
  • 公開資料には、件数、対象クラス、ソース、検証規則の版、シリアルの扱い、修正後の再送方法が示されていない。
  • オブジェクト本文や個人情報を公開せず、境界、クラス、規則、理由群、件数、処置、再照合状態を示す欠落受領記録が必要だ。

「動いている」という確認が答えない問い

8月27日、RIPE Database 1.124が本番環境に入った。リリースノートにはOIDC 2.0、CSP、HSTS、Versions APIの応答形式など複数の変更が並ぶ。その中で、複製の証拠構造を変えるのが「NRTMv3 server should skip invalid objects」という一行である。

NRTMv3のミラーは、データベースのエクスポートと、その時点に対応する現在シリアルから始まる。その後、ほぼリアルタイムの変更を受信する。RIPEの手順は、ミラー側の最大シリアルが開始値より大きくなったことを確認するよう求める。この検査は複製処理が進んでいることを示す。しかし、なぜ各オブジェクトが存在する、または存在しないのかまでは示さない。

サーバーが有効に送信できないオブジェクトに出会ったとする。以前の版が具体的にどう失敗したのか、公開資料は説明していない。1.124導入後に実際のオブジェクトが一件でもスキップされたかも不明だ。したがって、障害や経路への影響を断定する根拠はない。

それでも、運用上の状態は増えた。権威側があるオブジェクトを見た上で送らず、後続変更だけを進めることが可能になった。見えるシリアルに欠番が生じるとは限らない。そこも資料にない。確実に言えるのは、ストリームの継続と複製内容の完全性を同じ証拠で扱えなくなったことだ。

無効性は時代と規則に依存する

長期間運用された登録データベースでは、「無効」は単純な属性ではない。RIPEの統合文書は、現在の規則では構文が無効なオブジェクトが多数残ると説明する。古い規則の下で作られたものもあれば、権威更新としては受け付けられなくても、ミラー実装には一意に解釈できるものもある。

構文と配布可否も分ける必要がある。解析不能なrouteオブジェクト、現行命名規則に反するが意味は明確なset、個人情報を含むため配布すべきでない記録、ソフトウェアの一時的不具合でシリアライズできない記録は、それぞれ異なる。隔離、安全な変換、修正後の再送、恒久除外という処置も異なる。

IETFで検討中のNRTMv4草案は比較材料になる。解釈不能なオブジェクトと、非準拠でも曖昧でないオブジェクトを区別し、処理制限はスナップショットとデルタに一貫して適用するよう求める。ただし、これは別プロトコルの期限付き草案であり、1.124のNRTMv3実装を証明しない。

比較から分かるのは規則版の重要性だ。オブジェクト本文が同じでも、解析器やスキーマが更新されれば判定は変わる。どの検証規則で除外したかが残らなければ、後に現れたオブジェクトが修正されたのか、ソフトウェアが再解釈したのか、初めて送られたのかを区別できない。

可用性を守る反論は正当である

一件の不正な入力が後続の有効な更新をすべて止めるなら、局所的な欠陥が共有サービスの遅延に変わる。ミラーを検索、研究、経路ポリシー準備、ローカルな継続性に使う運用者にとって、全停止の被害は大きい。無効な一件を飛ばして流れを保つ方が安全な場合は十分にある。

問題のある本文を必ず送ることも解決ではない。個人情報や認証情報の残骸を含む可能性があり、クライアントを再び壊す構造かもしれない。透明性は、配布すべきでない内容の再公開を意味しない。

選択肢は「悪いオブジェクトを送る」か「何も説明しない」かではない。本文、主キー、連絡先を伏せたまま、権威サーバーで意図的な不送信が起きたことを記録できる。

RIPE NCCは検証と修正の権限を保持する。ミラー運用者は警告、隔離、再同期を自ら決める。両者の共有層には、境界で起きた状態を同じものとして確認するための最小情報だけを置けばよい。

同じ「不在」を生む四つの制御面

権威データベースは受理、保存、修正、削除を制御し、完全な本文と検証結果を知る。すべてを公開する必要はないが、信頼できる欠落記録の事実源はここにある。

NRTMv3サーバーは送信を制御する。権威状態が存在しても、このプロトコルで安全に送れるかを判断する。1.124は「スキップ」を送信層の結果にした。バイトが来ないという沈黙だけでは、その結果を説明できない。

ミラークライアントは受信を制御する。ローカル規則でクラスを除外し、形式を拒否し、接続を失うこともある。サーバー側の省略とクライアント側の拒否は、最終データベースでは同じ空白に見えるが、責任者も救済策も違う。

さらに下流のフィルター生成者や分析者は、空の検索結果しか見ないことがある。その不在は、未作成、削除、権威側省略、転送失敗、クライアント拒否、ローカル除外のいずれでもあり得る。すべてを「権威記録がない」と読むのは、証拠不足を確信に変える行為だ。

RIPE NCCが各ネットワークの経路受入れを決める必要はない。自らが制御する状態遷移を、外部の失敗と区別可能にするだけでよい。

公開記録がまだ示していないこと

九項目の欠落受領記録

一定の公開区間ごとの集計、または安全な場合のイベント記録には、次の項目があればよい。

  1. ソースとNRTM版。
  2. 実際のワイヤー動作に対応するシリアルまたは区間。
  3. 主キーを含めないオブジェクトクラス。
  4. 検証規則の識別子と版。
  5. 解析不能、配布不可、旧規則衝突、内部処理失敗などの理由群。
  6. その区間とクラスでの件数。
  7. 隔離、変換、恒久除外、修正待ち、修正済みという処置。
  8. 再送、スナップショット反映、照合の状態。
  9. 時刻、受領記録ID、訂正履歴。

クラスと狭い区間の組合せが機微な事案を推測させるなら、集計を遅らせ、区間を広げられる。認可された運用者には安定IDを使って非公開の詳細を提供できる。公開層は決定の存在を示し、その根拠となった保護対象を見せない。

「修正待ち」は閉じる必要がある。修正後に後続ストリームへ入ったのか、新スナップショットだけに入ったのか、除外が続くのか、権威データベースから削除されたのかを記録することで、推測を終えられる。

実行中のコードには実行中の証拠が要る

リリースノートは動作変更を証明するが、その動作が各ストリームで何をしたかまでは証明しない。1.124は省略が可能だと伝えた。次に必要なのは、具体的な省略を規則と解決状態につなぐことだ。

見かけの完全性のために、異常一件で全流を止める動作へ戻す必要はない。可用性を維持しながら、低下した完全性を観測可能にし、機微データを守り、限定された照合経路を示す方がよい。

進むシリアルは動きを証明する。版付きの薄い受領記録は、その動きの中で何が届き、何が意図的に留められ、何が回復可能かを証明できる。

情報源