要約

  • 2026年9月3日付のdraft-ietf-regext-epp-https-04はREGEXT作業部会のInternet-Draftである。RFCでもIESG承認でもなく、実運用への採用を示す資料でもない。
  • EPP処理層が応答を生成した要求は、命令の成否にかかわらずHTTP 200 (OK)で返る。HTTP状態とEPP結果は別々の事実である。
  • 処理された可能性があるのに有効なEPP応答が届かなければ、結果は不確定となる。中継装置の自動再試行は禁止され、命令全体と拡張の冪等性を理解するEoHクライアントだけが同じ取引IDと順序を保って判断できる。

監視担当者が最初に見るのは、しばしばロードバランサーの200である。しかし、レジストリが返したEPPコードは失敗を示すかもしれない。二つの記録は食い違ったのではない。観測した境界が違う。

draft-ietf-regext-epp-https-04は、状態を持つXMLプロトコルEPPをHTTPS上へ写像する。RFC 5730が求める命令順序、セッション、応答の対応関係は維持される。EPPをRESTに作り替える提案ではない。既存の会話をPOSTに載せ、WAFや負荷分散、L7監視を利用できるようにするトンネル型の写像だ。

接続は、帯域外で知らされたURLへの空POSTから始まる。正常応答にはEPP greeting、application/epp+xml、no-store、nosniff、セッションcookieが含まれる。その接続上でEPP <login>が成功して初めて認証済みセッションになる。

200は命令の承認印ではない

ログイン後、一つのPOSTが一つのEPP命令を運び、一つのHTTP応答が一つのEPP応答を運ぶ。要求がEPP処理層まで届き、EPP応答が作られたなら、外側は常にHTTP 200である。内側が成功でも拒否でも同じだ。

4xxや5xxは、HTTP側の別の問題を示す。形式不正、媒体型の不一致、サイズ制限、レート制限、過負荷、ゲートウェイ障害などで、権威あるEPP応答を受け取れなかった場合である。これらの状態コードだけでは、レジストリオブジェクトに何が起きたかを確定できない。

無効なセッションcookieでも境界は見える。その要求がEPP処理へ入れば、HTTP 200の中にEPP 2002「command use error」が返る。HTTP 200の件数を命令成功件数として扱うと、明示的な拒否が正常処理として集計される。

したがって、証跡は少なくともHTTP状態、EPP結果コード、クライアント取引IDを結び付ける必要がある。最初は経路、次はレジストリ判断、最後は再試行を元の意図へ結ぶ鍵である。

タイムアウトは取消通知ではない

本当に危険なのは、応答だけが消える場合だ。クライアントが更新命令を送信し、レジストリが処理した後、復路の接続障害で応答を失う。成功コードも失敗コードもない。ドラフトはこの状態を「indeterminate」とする。

ここで一般的なHTTP再試行を使うと、回復ではなく二度目の命令になり得る。POSTはHTTP上で冪等と定義されていない。EPP命令は冪等にできるよう設計されているが、実際の安全性は命令全体と拡張に依存する。プロキシにはその意味が分からない。

改訂04は判断をEoHクライアントへ戻した。障害が一時的で、HTTP状態の意味が再試行と整合し、完全なEPP命令が冪等だと分かる場合だけ再送できる。命令と取引IDは同一でなければならず、有効な応答を得るかセッションを放棄するまで次の命令を送れない。管理下の中継装置ではEPP POSTの自動再試行を無効にする。

これは順序の保護でもある。新しいIDは同じ意図を別命令に見せる。次の命令を先に通せば、未知の状態を前提に処理が続く。汎用ゲートウェイへ再試行権を渡せば、意味を知るクライアントから、タイムアウトしか知らない装置へ決定権が移る。

多重化できるのは回線であり、因果関係ではない

HTTP/2とHTTP/3は多重化を備えるが、EoHは一つのEPPセッションに複数の未完了要求を認めない。中継装置が並行要求を作る可能性は残るため、サーバーは拒否か直列化かを定義しなければならない。

セッションcookieは、複数のHTTP接続をまたいでも一つの論理EPP接続を表す。複数インスタンスでは、特定バックエンドへのアフィニティか共有セッションストアを選べる。前者は単純だが、状態を複製しなければインスタンス障害とともにセッションを失う。後者は切替を容易にする一方、ストア自体が機密性・完全性・可用性の境界になる。

同じ接続の要求は順番に処理し、状態変更は原子的に行い、HTTP・EPP・保存状態の寿命を合わせる必要がある。HTTPSのヘルスチェックが通っても、レジストリ会話の状態が残っているとは限らない。

ドラフトはVerisign SDKの開発実装と、Registro.itが2009年から使う少し異なる構成を記す。ただし、実装欄は寄稿者の申告でありIETFが検証したものではない。稼働コードの存在は示しても、普及率や品質の証明にはならない。

Heng Luの現実層を分ける考え方に従えば、HTTP配送、EPP判断、保存状態、DNS公開、リゾルバ観測は別々の証拠である。Running-Code Primacyが再試行権の所在も明らかにする。命令を理解し、後続を止め、取引IDを保存し、権威状態を照会できる実装が判断すべきだ。

HTTPSは運搬路を新しくする。命令の意味までHTTPへ譲渡するものではない。

情報源