要約

  • RIPE NCCが9月10日に公開したWhoisのコミットは、NRTMv4サービスの送信元一覧と名前検証をNrtmSourceSlaveDaoへ移した。
  • 通知ペイロードのDAOには、スレーブで空ならマスターを再検索する処理がある。しかしサービスは先にレプリカの一覧から送信元オブジェクトを作るため、そこで失敗すると再検索には到達しない。
  • これは処理順序の事実であって、実環境の遅延や障害を示すものではない。必要なのは全読取りをプライマリへ戻すことではなく、送信元を公開する前の準備完了記録である。

フォールバックが存在することと、リクエスト全体がフォールバックで覆われていることは同じではない。RIPE NCCのコミット252681a0865d5a10dbcfeaeeaf81bf33ef2c3855は、その違いをわずか三つのファイルで見せている。

コミット日時は2026年9月10日10時56分UTC。題名は「Use read-only (slave) source DAO in NRTMv4 Service」だ。既存のNrtmSourceDaoに@Primaryが付き、20行のNrtmSourceSlaveDaoが加わり、NrtmServiceが後者を受け取るようになった。新しいDAOは同じクエリ実装を継承しつつ、nrtmSlaveDataSourceを渡す。

この設計には、かなり強い理由がある。送信元の表は小さく、通常はめったに変わらない。公開サービスの反復読取りをプライマリから外せば、書込み経路との競合を減らせる。NRTMv4の配信物にも、署名付きUpdate Notification File、スナップショットとデルタのハッシュ、session_id、版番号という整合性の仕組みがある。さらに通知を探すDAOは、スレーブ側で見つからない場合にマスターを試す処理をすでに持つ。

したがって論点は「レプリカは危険だ」ではない。どの判定までが、その再試行に含まれるかである。

一覧と受付が同じ読取り側を見る

NrtmServiceは新しいDAOを二通りに使う。一つはルートのHTMLページだ。getSources()の結果を順に読み、各送信元のUpdate Notification Fileへのリンクを作る。読取り側にない行は、この一覧には現れない。

もう一つはファイル要求の受付である。通知ファイルへの要求では、サービスがfindLastNotification(getSource(source))を実行する。内側のgetSource()はDAOから全送信元を読み、URLの名前と一致するものを探す。なければ「Invalid source」というBad Requestを投げる。

Javaでは引数が先に評価される。つまりgetSource(source)が成功しない限り、findLastNotification()は呼ばれない。ここに順序の境界がある。

後段のUpdateNotificationFileSourceAwareDaoは、最初に通知ペイロードを問い合わせる。空で、現在のSourceContextがSLAVEなら、同名のマスターソースへ一時的に切り替え、再度問い合わせ、finallyで元のコンテキストに戻す。送信元オブジェクトは存在するが通知レコードが読み取り側にまだ見えない、という状態にはよく備えている。

一方、前段の送信元表に行がなければ、後段へ渡すオブジェクト自体がない。通知のフォールバックが壊れているのではない。開始地点が、送信元の受付より後ろなのである。

日常時ではなく、追加時の条件

この処理だけから、現在のRIPEや非権威データベースが影響を受けているとは言えない。定常状態では送信元行がすでにレプリカにあり、一覧も直接要求も普通に進むだろう。公開資料には、レプリカ遅延、欠落行、実際の400応答、利用者の失敗を示す観測はない。

条件が意味を持つのは、送信元を新設する時、行を再作成する時、データソースが復旧する時、設定や同期状態が変わる時だ。プライマリでは送信元が承認済みでも、配信側が読むレプリカではまだ未観測という短い時間があり得る。その場合、ルート一覧からは名前が落ち、直接通知を取りに来た要求は後段のマスター再検索より前で止まる。これはコードから導ける条件文であり、発生記録ではない。

このコミットが本番に入ったという証拠もない。mainブランチの差分は、リリース番号でもデプロイ証明でもない。オンラインの応答や複製状態を今回の証拠から推定すべきではない。まして認証回避や改ざんを許す脆弱性として扱う理由はない。

レプリカはプライマリの粗悪な代用品ではなく、時間差と引き換えに容量や分離を得る仕組みだ。どの読取りがその時間差を許容できるかを決めるのが運用設計になる。既存の小さな表を何度も読むことと、新しい公開名を有効化することは、同じ決定ではない。

NRTMv4の証拠は強いが、対象が違う

取得時点のIETF Datatrackerはdraft-ietf-grow-nrtm-v4を第11版としている。この仕様は、IRRレコードをHTTPSで一方向に同期する。配信物は一つのUpdate Notification File、一つの有効なSnapshot File、そしてゼロ個以上のDelta Fileから成る。

通知ファイルはJSON Web Signature形式で署名される。クライアントは通知URL、IRRデータベース名、公開鍵を設定し、通知に書かれた送信元名と署名を検証する。通知が参照するスナップショットとデルタにはSHA-256ハッシュがあり、不一致なら拒否する。session_idが変われば、クライアントは増分の連続性を仮定せず、最新スナップショットから読み直す。

この仕組みは、受け取った内容の真正性、完全性、版の連続性を強くする。だがHTTPサービスが送信元名を受理する前に、内部の読み取り側表が準備できたかまでは証明しない。到達できない通知の署名を、クライアントは検証できないからだ。

だからといって、プロトコルにデータベースの複製情報を載せるべきでもない。内部トポロジーは公開契約ではない。必要なのは、配信者が送信元を有効にする際の統制記録である。

送信元の「公開可」を一枚にする

実務的な改善は、送信元カタログのアドミッション・レシートだ。非公開の運用記録で構わない。送信元名、ロールアウト世代、プライマリ側の承認時刻、配信に用いる読取り経路、その経路で行を確認した時刻または準備水準、最初の有効な署名通知を同じ経路で取得した結果を結び付ける。

さらに観測したsession_idと版、署名鍵の参照、ルート一覧の確認、直接URLの確認、承認者、有効化時刻、ロールバック条件、後続記録へのリンクを残す。ホスト名、複製オフセット、内部行番号、資格情報は公開する必要がない。「世代Xが配信側で観測された後、送信元Yを有効にした」という関係が重要だ。

実行順序は、書込み側で作成または承認し、サービスが使うデータソースで観測し、その経路から署名通知を一度検証し、それから公開する、となる。制限時間内に整わなければ、有効化を保留するか、明示的で期限付きの別経路を使う。

テストも二つに分けたい。マスター表には新しい行があり、レプリカ表にはない状態で、受付の方針を確かめる。次に行は見えるが通知ペイロードだけがない状態で、既存のフォールバックを確かめる。別の失敗点を別のテスト名にするだけでも、将来の修正がどの保証を変えたか分かりやすくなる。

この統制なら、すべての読取りをプライマリへ戻す必要はない。高頻度の効率を維持しながら、可視な送信元集合が変わる低頻度の瞬間だけ、証拠を要求できる。

出典