要約

  • RFC 3632 の -Approve:No は、現スポンサーが送れば移管の拒否、申請元が送れば自らの申請の取消しになった。認証セッション、役割、処理前状態、時刻がコマンドの制度的意味を決めた。
  • 200 Command completed successfully は RRP コマンド処理の成功を示す。登録者の意思、人的同意、DNS 公開、利用者から見た結果まで証明するものではない。
  • 有効な証拠は payload だけでなく、主体、役割、対象、前状態、規則、期限、応答、後状態、帯域外通知を結ぶ。文字を忠実に保存しても、話者を失えば行為は復元できない。

一行を読む前に、話者を読む

RFC 3632 は 2003 年 12 月に Informational として公開され、VeriSign Registry Registrar Protocol 2.0.0 を記録した。Internet Standard ではなく、現在 RRP を採用するための手引きでもない。それでも証拠設計の教材として強いのは、payload が自分自身の意味を完結させない例を残したからだ。

現スポンサーの registrar は -Approve:No で別の registrar から来た移管要求を拒否した。元の申請 registrar は同じ値で自らの要求を取り消した。拒否は他者の要求に対する判断であり、取消しは自分の行為の撤回である。同じ否定語でも、権限の向きが逆になる。

RFC Editor の情報、IETF Datatracker、文書履歴、errata 検索が示すのは公開状態である。特定事業者の実装、遵守、移管結果を示す資料ではない。本稿が取り出すのは、仕様中に明記された主体依存性である。

主体はコマンド欄ではなくセッションにいた

先行する RFC 2832 では、移管を要求する registrar の識別子は現在の認証済みセッションから得られた。registry は対象ドメインの現スポンサーも把握していた。誰が接続しているか、対象とどの関係にあるかを結んで初めて、許可された操作が分かる。

payload に「自分はスポンサーだ」と書くこととは異なる。自己申告は権限を作らない。セッションの認証結果と registry のオブジェクト状態が、その主張を検証する。無関係な registrar が承認または拒否を試みれば失敗しなければならなかった。

さらに、失う側になり得る registrar にはメールやレポートなど帯域外で通知する必要があった。移管の事実は一つの通信路に閉じていない。認証記録、プロトコル交換、registry 状態、通知配送がそれぞれ違う部分を証言する。

RRP 自体は応答に時刻や transaction identifier を返さなかった。記述された日次・週次レポートは registry のローカル時刻を使った。後の調査では、時刻基準と関連付けを別途保存していなければ、正しい二つの記録を正しく並べられない。

取消し可能性には有効期限があった

RFC 3375 は役割を要件として整理した。申請 registrar が移管を開始し、判断前なら取り消せる。現スポンサーは承認または拒否できる。権限を持たない主体の試みは拒絶される。双方が pending と完了を監視できなければならない。

RFC 3632 は取消しを RRP に加えたが、新しい語を作らず既存の Approve:No を再利用した。取消しが成立するのは、スポンサーが明示的に承認・拒否する前、または registry のタイマーによる暗黙の判断が成立する前だけである。

したがって時刻は検索用メタデータではなく、操作の妥当性を決める入力だった。server receive time、時計の基準、当時の timer policy、pending を閉じたイベント、処理前後の状態が必要になる。client time だけでは、決定権を持つサーバーでの順序を示せない。

不可逆点は pending が閉じた瞬間にある。その後に別手続で修正できても、過去の申請を未決の状態へ戻すことはできない。最終状態しか残らなければ、遅い取消し、タイマーとの競合、正当な拒否を区別できない。

200 は「何が成功したか」を限定して読む

RFC 3632 の取消し例は 200 Command completed successfully を返す。これは RRP サーバーがコマンドを完了したという価値ある receipt である。receipt が狭いことは、弱いことと同じではない。

ただし、登録者が取消しを望んだこと、registrar 内部で承認されたこと、最終スポンサーが変わったこと、DNS delegation が更新されたこと、利用者が別の応答を得たことは示さない。各主張は別の issuer と観測点を持つ。

Lu Heng の On Authority and Beliefを当てはめれば、registry response は registry の処理について権威を持つ。その権威を登録者の心証やネットワークの結果にまで伸ばしてはいけない。

監査画面では、顧客承認、registrar 操作、registry sponsorship、DNS 公開、サービス観測を別行または別列に置くべきである。相互確認はできるが、一つの緑表示が他の未知を消してはならない。

EPP は動作名を分けたが、運用責任までは代行しない

後の RFC 5731 は、移管操作を request、cancel、approve、reject、query に分けた。pending transfer には request client、request date、action client、action date、状態を含められる。RFC 5730 は client/server 双方の transaction identifier を扱う。

この表現はログを読みやすくする。同じ否定値を外部文脈だけで分類する必要が減り、相関キーも得られる。しかしフィールドは自ら保管されない。collector が ID を落とせば相関できず、時計が不確かなら日付は順序を保証しない。request client は登録者ではなく、成功応答は DNS 観測でもない。

RFC 3730 は EPP の以前の世代を示すが、特定の移行や実装を証明しない。標準が可能にした receipt と、稼働システムが実際に残した receipt を分ける必要がある。

510 が確認したのは符号化境界である

RFC 3632 は ADD/MOD における不正なドメイン名符号化に 510 を追加した。後の RFC 5890 は国際化ドメイン名の用語を精密化している。

入力形式が受理されたなら、当時の構文と registry policy を通過したことが分かる。商標権、組織の本人性、登録者の意図、表示上の安全性、実際の delegation までは分からない。510 も名称に対する普遍的判断ではなく、その interface の拒否である。

「valid」という語には対象を残すべきだ。どの文法に対して、どの時点のどの実装が受理したのか。対象を省くと、parser の権限が制度全体へ拡張される。

IPv6 を保存できることと、到達できること

RFC 3632 は nameserver object に完全形または圧縮形の IPv6 address を格納できるようにした。RFC 4291 は address architecture、RFC 5952 は後の標準的な文字表現を扱う。

文字列の構文受理、object 保存、親 zone または root への公開、route 到達性、authoritative DNS 応答は別の事実である。「IPv6 対応」という一つのラベルでは、どの段階が確認されたか分からない。

証拠は host object、delegation set、zone publication、routing view、複数地点からの DNS 観測を分けて持つ。一致すれば信頼が増す。不一致は障害ではなく、どの reality layer がずれたかを示す診断材料になる。

557 は通常経路の権限外を示した

557 は top-level domain と関連する nameserver object が locked であることを示し、registry support との帯域外調整を求めた。変更不能という意味ではなく、通常の registrar 経路に単独権限がないという意味だった。

現在の IANA root-zone 管理は別の仕組みである。root-zone management、TLD 管理案内、同意手続、nameserver technical requirements、RZMS API は、credential、限定 permission、contact や manager の同意、技術検査、実装、事後確認を分離している。複数 TLD に影響する nameserver IP 変更では他の当事者も関与し得る。

これらの現行資料を過去の RRP transaction の証拠にしてはいけない。そこから得られるのは境界の比較である。registry object、root request、root publication、実サービスは相互に関連しても同一ではない。

最小 receipt は巨大なメッセージではなく結合キーである

移管の最低証拠は、protocol/build version、認証 session、client ID、申請者と現スポンサー、対象、request time、before state、command bytes、policy/timer version、authorization evaluation、response、after state、notification、最終判断を結ぶ。DNS の主張をするなら、publication と観測を追加する。

Heng の Minimum Initial Specificationが示すように、共通最小面を作ることと、全権限を一か所へ集めることは違う。registry は顧客承認や到達性の裁判官になる必要はない。自分の判断を他の証拠と安全に結べるようにすればよい。

On Reality Layersは command、制度判断、登録記録、DNS、利用者体験を別の層として提示する。Running Code Primaryは仕様上の可能性ではなく、実行された遷移を見ることを求める。

同じ No を二度読む必要があったのは、仕様が曖昧だったからではない。server が知っていた話者と状態を、後の監査 export が捨てたからだ。正確な文字列は、正確な権限帰属の代わりにはならない。

出典

  1. RFC 3632 — VeriSign Registry Registrar Protocol 2.0.0
  2. RFC 3632 テキスト版
  3. RFC Editor の RFC 3632 情報
  4. IETF Datatracker の RFC 3632
  5. RFC 3632 文書履歴
  6. RFC 3632 errata 検索
  7. RFC 2832 — Registry Registrar Protocol 1.1
  8. RFC 3375 — Registry–Registrar Protocol 要件
  9. RFC 3730 — Extensible Provisioning Protocol
  10. RFC 5730 — Extensible Provisioning Protocol
  11. RFC 5731 — EPP Domain Mapping
  12. RFC 5732 — EPP Host Mapping
  13. RFC 4291 — IPv6 Addressing Architecture
  14. RFC 5952 — IPv6 テキスト表現
  15. RFC 5890 — IDNA 定義
  16. IANA — Root Zone Management
  17. IANA — Top-Level Domain の管理
  18. IANA — Root Zone 変更の同意
  19. IANA — Nameserver Technical Requirements
  20. IANA — Root Zone Management System API
  21. Lu Heng — On Authority and Belief
  22. Lu Heng — On Reality Layers
  23. Lu Heng — Running Code Primary
  24. Lu Heng — Minimum Initial Specification