要約

  • draft-gould-regext-epp-server-validation-00 は同期、非同期、定期検証の器を定めるが、検証タイプはサーバーポリシーに委ねる。
  • success は最後の実行結果にすぎず、日時、原因操作、遷移履歴、失敗理由は任意である。
  • 定義、版、観測点、入力、時刻、受信者、poll ID、確認、是正を結ぶ検証状態受領証が必要だ。

レジストリはDNS解決やDNSSECなどを検証し、変換コマンドの応答、info、後日のpollで結果を返せる。定期検証で状態が変わった場合もキューに入る。独自通知を共通形式にする利点は大きい。

しかしdnsとdnssecは例で、typeの意味はサーバー方針次第だ。リゾルバ、観測地域、許容アルゴリズム、再試行、入力が違えば、同じsuccessでも同じ検査ではない。

任意の時計は証拠の限界である

実行日、原因操作、前回成功、最初の失敗、回復前の最終失敗はすべて任意だ。理由も任意のサーバー固有テキストで、複数・言語付きにできる。欠落は「なかった」ではなく「不明」である。

DNSのレコード、署名、委任、キャッシュ、経路は変化する。正しい表現は「このサーバーが最後にXを実行した際に成功した」だ。「ドメインは健全だ」では継続性と認証を勝手に足してしまう。

poll確認は是正ではない

RFC 5730ではクライアント別キューの先頭メッセージにIDと件数が付く。クライアントが受領確認するとサーバーは出隊する。これは配送の証明で、人が読んだことや問題を直したことの証明ではない。

実行、入隊、取得、確認、社内エスカレーションの時刻を分ける必要がある。サーバーはスポンサーと非スポンサーへの開示を変え、理由をスポンサーだけに示してよい。受信者と開示方針がなければ、正当な差を不整合と誤解する。

対象操作は作成、更新、更新期間延長、移転、一部削除、復元、自動処理、独自処理に広い。要求側に要素は増えず、同期結果は応答に入る。何をいつ検査するかはサーバーが握る。

出隊前に受領証を保存する

受領証はタイプ定義、ポリシー版、観測点、パラメータ、入力、実行時刻を固定する。原因操作または定期・手動起源、履歴、不明欄も残す。さらに対象、受信者区分、poll ID、キュー日、取得、確認、内部引渡しを記録し、チケット、是正、再検証、終了を別イベントにする。

これは本稿の提案である。2026年7月19日付の文書は個人Internet-Draftで、Datatrackerは正式なIETF支持、RFCストリーム、予定ステータスなしと表示する一方、文書見出しはStandards Trackとする。RFCでも導入証拠でもない。

情報源