要約

  • RFC 8334はローンチ登録とローンチ申請を区別する。申請モデルでは、同じドメインに複数の申請を受け付けられ、有効なcreateに結果1001、applicationID、pendingCreateを返しても割当は終わっていない。
  • 成功が証明するのはコマンド受理と申請オブジェクトの生成である。商標上の優先、最終割当、レジストリ公開、DNS委任、サービス到達性は別の主体と時計に属する。
  • 監査にはトランザクションID、フェーズとポリシー、順序付き状態・poll履歴、最終domain:panDataが必要である。割当後もドメインオブジェクト、公開面、権威DNS、サービスを個別に読む。

運用画面の「成功」は、処理を前へ進めるためにある。しかし、その一語が何を主語にしているかを消すと、まだ存在しないドメインを存在するものとして扱い始める。

RFC 8334の例では、サーバーはCommand completed successfully; action pendingと答える。結果コードは1001で、フェーズとapplicationIDも返る。完了したのはコマンドであり、保留中なのは申請を割当または却下へ動かす行為である。

このRFCは2018年3月にIETF標準化過程文書として公開され、J. Gould、W. Tan、G. Brownの共同著作である。IANAのEPP拡張レジストリもRFC 8334を参照する。Gavin Brownを人物として取り上げる理由は、この共同作業が受理と権利化の間を明確に記述したからだ。Brown一人の発明でも、彼個人によるレジストリ判断でもない。

2026年8月31日に保存したIETFプロフィールは、BrownがDNS・ドメイン名業界で25年の経験を持ち、Team Internet PLC（旧CentralNic）に22年、うち14年をCTOとして勤務し、現在はICANNで働くと記す。RFC 8334を含む4件のRFC、RESTful Provisioning Protocol議長、ARTARTレビュアーなどの公開役割も載る。これは日付付きの専門経歴であり、個々のローンチに対する権限ではない。

同じcreateでも生成物が違う

RFC 8334は二つのモデルを定義する。ローンチ登録は、先着順モデルのローンチフェーズで単一の登録を作る。ローンチ申請は登録の意思を表し、サーバーは同じドメインに複数の申請を保持して、後で一件を登録へ割り当てられる。

複数申請は、このモデルが許す選択肢であって全ローンチの事実ではない。サーバーがローンチ申請を支援しなければ、その形式は失敗する。フェーズごとの方針が採用可否と選択方法を決める。

有効な申請createを受けたサーバーは、申請オブジェクトを作り、識別子を割り当て、RFC 5731のpendingCreateを設定し、applicationIDを返さなければならない。同じ名前をめぐる申請が複数あっても、このIDで一件を追跡できる。

これは実体のある成功である。サーバーは申請を記録し、後続処理が参照できる状態を作った。ただし、生成物は申請であって最終ドメインオブジェクトではない。IDは申請を識別し、pendingCreateは未完了を明示する。

データ項目を単にcreate_successと呼べば、何をcreateしたのかが消える。顧客通知は登録完了と誤読され、課金が始まり、DNSチームに委任不在の障害票が届く。必要なのは成功を弱めることではなく、申請受理、検証、割当、ドメイン生成、委任、サービスという目的語を残すことである。

1001が発行する限定的な受領証

EPP中核のRFC 5730で、1001はコマンドが正常に完了し、要求した行為が保留中であることを意味する。レスポンスはクライアントのトランザクションIDを引き継げ、サーバーのトランザクションIDを持つ。双方のログはそこで結べる。

ローンチ申請の受領証には、時刻、スポンサークライアント、ドメイン、接続先、両ID、フェーズ、サブフェーズ、create形式、適用ポリシー、結果、applicationID、RFC 5731状態、ローンチ状態を残すべきだ。

その証拠から言えるのは、当該サーバーが当該文脈で申請操作を受理・記録したことまでである。商標上の権利、検証完了、競合申請からの選択、定常ドメインオブジェクト、RDAP公開、親ゾーン委任、サービス稼働は含まれない。

各動詞の主体も異なる。レジストラクライアントは提出する。必要なら検証者が資料を評価する。レジストリがポリシーを適用する。公開系がデータを投影する。ゾーン運用者が委任を掲載し、権威サーバーが答え、サービス運用者がアプリケーションを用意する。一つ目の成功は、後続主体の委任を取得しない。

フェーズ名だけでは判断できない

RFC 8334にはsunrise、landrush、claims、open、customがある。クライアントは対象フェーズを指定し、サーバーはそれを検証し、サブフェーズも検証できる。フェーズは重なり得て、name属性で細分化もできる。

だがラベルはポリシー本文ではない。同じsunriseでも、受付期間、検証事業者、料金、資格、競合処理、割当時刻はレジストリごとに違い得る。RFCは互換な表現を与え、具体的判断の一部を帯域外方針に残す。

したがって、証拠にはポリシー版と有効期間が要る。フェーズ名だけでは、どのマーク資料が必須か、複数申請が許されるか、どの状態を省略できるか、何が勝者を決めるか分からない。

RFC 7848は関連するマークと署名付きマークのオブジェクトを定義する。RFC 8334は形式に応じてマーク、署名付きオブジェクト、コード、通知を運べる。これらは来歴を証明する材料であり、割当そのものではない。有効なマークが一条件を満たしても、最終判断はレジストリ方針にある。

逆に、すべての形式に同じ資料を要求してはならない。不足を指摘する前に、当時のフェーズ、サブフェーズ、形式、ポリシーが何を必須としたかを示す必要がある。最小仕様とローカル判断を分けるからこそ、責任の所在が見える。

保留は一枚の状態ではなく時系列である

ローンチ状態にはpendingValidation、validated、invalid、pendingAllocation、allocated、rejected、customがある。非最終状態でローンチ状態を使う間、RFC 5731のpendingCreateが維持される。ポリシーにより中間状態は省略できる。

最終状態だけを保存すると、検証が行われたのか、正常に省略されたのか、いつ誰が通知を受けたのかが失われる。そこでRFC 5730のpollキューが非同期変化を運ぶ。メッセージにはIDがあり、クライアントは取得して確認する。

RFC 8334は中間変化にpollを推奨し、allocatedまたはrejectedという最終状態にはRFC 5731のdomain:panDataを必須とする。監査記録はメッセージID、投入時刻、取得、確認、状態、申請ID、関連トランザクションを順序付きで残す。

allocatedはその申請が選ばれた証拠であり、RFC 5731ドメインオブジェクトへ進む。rejectedはその申請が登録にならなかった証拠である。長い沈黙や公開検索の空結果は、どちらの代わりにもならない。

申請の存在や内容は機密になり得る。無権限操作には2201を返し、ポリシーにより情報を絞れる。公開面で見えないことは、その公開面の権限を説明するだけで、非存在を証明しない。

割当後に読むべき四つの面

最終panDataがallocatedでも、インターネット上で利用可能とは限らない。まずRFC 5731ドメインオブジェクトを読む。次にレジストリやRDAPの公開、親ゾーンの委任、権威DNS回答、サービス到達性を別々に観測する。

割当済みなのにオブジェクトがなければレジストリのプロビジョニングを調べる。オブジェクトがあり委任がなければゾーン公開か登録者設定を見る。委任後に権威回答がなければDNS運用、DNSが正常でサービスがなければアプリケーションやネットワークの問題である。

Running-Code Primacyが求めるのは、各面に観測した事実だけを語らせることだ。EPPはEPP状態、レジストリ読出しはオブジェクト、RDAPは公開投影、DNSは時点と観測地点での回答、接続はサービス観測を証明する。最初の受領証に全層を代表させてはならない。

保存すべき証拠の接合

重要な判断には少なくとも次を結ぶ。

  1. クライアント・サーバーのトランザクションID、作成時刻、クライアント、ドメイン、接続先、結果。
  2. フェーズ、サブフェーズ、形式、ポリシー版、有効期間、割当手順。
  3. applicationID、初期pendingCreate、ローンチ状態、閲覧権限。
  4. 適用方針が求める場合だけ、検証者、マーク、署名、コード、通知の来歴。
  5. 順序付き状態とpoll、取得・確認、状態省略の理由、例外。
  6. allocatedまたはrejectedの最終domain:panData。
  7. 割当時のRFC 5731ドメインオブジェクト。
  8. レジストリ/RDAP、親ゾーン、権威DNS、サービスの時刻付き独立観測。
  9. 機密性の根拠、フィルター、認可読者、保存期間、監査責任者。

この接合は手続きを増やすためではない。申請者は受理を証明でき、レジストリは受理と割当を分けられ、検証者は最終判断を横取りせず作業を示せる。機密な申請内容を公開しなくても、どこで待ちが生じたか説明できる。

RFC 8334は未完了の時間に、ID、履歴、終点を与えた。applicationIDが待ちを識別し、状態とpollが経過を残し、panDataが閉じる。ガバナンスの失敗は、その三つを一つの緑色の「成功」に潰すところから始まる。

出典