要約

  • RFC 5144 は IRIS-DREG の厳密な部分集合として軽量な DCHK を定義した。
  • active と inactive は DNS 公開の状態であり、登録可能性そのものではない。
  • reserved は通常の登録手続で取得できないことを明示する。
  • 紛争中や各種猶予期間は、単純な可否表示では保持できない。
  • 作成、削除、更新、復旧、移管、変更には pending または prohibited が付き得る。
  • actor、scope、サブステータスの権威は、誰の判断がどこまで及ぶかを示す。
  • ソース DB の最終更新時刻は、応答時刻や意思決定時刻とは別である。
  • 登録参照は次の問い合わせ先を示すが、その先の認可を保証しない。
  • IRIS の XML 層は認証とプライバシーをアプリケーション転送層に委ねる。
  • IANA の識別子が残っていても、稼働中の実装や普及率は証明されない。
  • RFC 5144 の IDN 前提は、廃止扱いの Nameprep をなお参照している。
  • 重要な判断には、照会、資格、コマンド受理、確定更新、DNS 公開を別々の証拠として残すべきだ。

名前の一致は、ポリシーの一致ではない

RFC 5144 は <idn> に Nameprep 形式の名前を置く設計で、RFC 3491 を参照している。ところが国際化ドメイン名の扱いはその後変化し、RFC 5891 は IDNA2008 の登録・検索プロトコルを定めた。RFC 5144 自体が形式上廃止されたという意味ではない。しかし、古い正規化規則の出力を現行レジストリの登録判断へそのまま持ち込めるという意味でもない。

表示文字列、正規化後のラベル、問い合わせに使った実体、登録システムが審査する実体を別々に記録する必要がある。同じ見た目でも異なるコードポイントやポリシー判断があり得る。逆に、異なる入力が同じ対象へ正規化される場合もある。照会結果が正しくても、対象同一性を取り違えれば意思決定は誤る。

ここで重要なのは、現行の特定レジストリが DCHK を運用していると主張しないことだ。本資料に導入状況の証拠はない。論点は仕様の境界であり、現在の商用サービスの評価ではない。

active は DNS の語彙である

DCHK の active は、委任または直接公開によって DNS で利用できる状態を指す。inactive は DNS で利用できない状態だ。日常語の「アクティブ」「非アクティブ」から、登録済み／未登録を推測してはいけない。

仕様には別に reserved があり、通常の登録手続では利用できないことを示す。DNS に出ていない予約名は矛盾ではない。紛争、作成後や更新後の猶予期間、移管後の猶予、削除後の redemption も同じ結果の文脈になり得る。

RFC 3915 の状態遷移では、削除された名前が redemption、復旧待ち、削除待ちを経て、消去後に初めて再登録可能になる。途中の時点で DNS 非公開だったとしても、その順序は省略できない。

動詞に完了を読み込まない

DCHK は作成、削除、更新、復旧、移管、変更を状態として表現できる。ただし disposition は pending または prohibited になり得る。移管という語が見えても、移管済みとは限らない。

EPP の RFC 5731 は、check が create 成功を予測するためのヒントであり、実際の要件はサーバーポリシーに属すると述べる。処理済みの変換コマンドも完了まで pending のままになり得る。DCHK と EPP の役割は違うが、問い合わせ、予測、受理、確定という段階は混同できない。

状態には適用日、チケット、説明、サブステータスを付けられる。サブステータスの値を定義した権威も必要だ。actor は registry、registrar、registrationServiceProvider を区別し、scope は文脈を限定する。これらを落とした要約は、局所的な判断を普遍的な事実に変えてしまう。

時刻と参照にも所有者がいる

lastDatabaseUpdateDateTime は、結果の元となったデータベースが最後に更新された時刻である。画面を開いた時刻ではない。API の低遅延も、データの新しさを保証しない。ソース時刻、受信時刻、キャッシュ時刻、判断時刻を独立して残すべきだ。

registrationReference は、レジストリの結果からレジストラや登録者サービスへ進む手掛かりになる。IRIS の参照や検索継続は別インスタンスにも渡り得るため、ループ回避の注意まで定められている。参照先へ到達できたことと、そこで認証され、審査に通り、更新が確定したことは別である。

RFC 3981 は XML 層自体が認証やプライバシーを提供しないと明記する。RFC 5144 は IRIS-LWZ 実装を必須とし、XPC と BEEP を任意とする。安全な輸送路が成立しても、業務上の権限までは運ばれない。

登録簿にあることと、動いていること

IANA には dchk1 の XML 名前空間とスキーマ、DCHK1 の S-NAPTR タグ、BEEP プロファイルが残る。RFC 5144 は Proposed Standard のままで、検証済み正誤表は “Straightforward-NAPTR” の綴りだけを直す。

これはプロトコル割当の証拠であって、稼働サーバー数や利用量の証拠ではない。RFC 9083 の RDAP JSON 応答は後年の情報モデルとして参照できるが、RFC 5144 を形式上置換したと断定する材料ではない。

運用判断では、規格のラベルより実際のコードと観測を優先する。ただし、観測できないことを「ゼロ」と書き換えてはいけない。未知は未知のまま記録する。

証拠を階段として設計する

最初の段には、入力文字列、正規化規則、問い合わせ先、プロトコル版、原文応答を置く。次にソース DB 時刻と全ステータス、actor、scope、disposition、チケット、サブステータス権威を置く。参照を追った場合は、参照元と参照先を別々に記録する。

その後で初めて、申請者の資格、ポリシー版、価格、コマンド提出、受理、審査、確定更新、DNS 委任、実際の名前解決を記録する。一段上の証拠は次の確認を始める理由にはなるが、下の段の完了証明にはならない。

情報源

  1. RFC 5144 HTML
  2. RFC 5144 テキスト
  3. RFC Editor 記録
  4. IETF Datatracker 記録
  5. 文書履歴
  6. RFC 5144 正誤表検索
  7. 検証済み正誤を含む表示
  8. IANA XML Registry
  9. IANA S-NAPTR Parameters
  10. IANA BEEP Parameters
  11. RFC 3981：IRIS コア
  12. RFC 3982：IRIS ドメインレジストリ型
  13. RFC 3983：BEEP 上の IRIS
  14. RFC 4992：IRIS の XML パイプライン
  15. RFC 4993：IRIS 軽量 UDP 転送
  16. RFC 3915：EPP 猶予期間
  17. RFC 5731：EPP ドメインマッピング
  18. RFC 3491：Nameprep
  19. RFC 5891：IDNA2008
  20. RFC 9083：RDAP JSON 応答
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy