要約

  • APNICは2026年第3四半期を目標に、すべてのIRTメールアドレスを継続的に追跡し、静的なアカウントロックフラグではなく、ログイン時点の有効性を確認する改善を掲げている。
  • 公開された計画が変えるのは、アクセス判定の情報源と時点である。6か月ごとの検証、15日後のInvalid表示、30日後のMyAPNIC制限を廃止するとは書かれていない。
  • メールアドレス、検証チャレンジ、IRTオブジェクト、アカウントの適用範囲、ログイン判定は別々の状態であり、一つの真偽値では由来を保てない。
  • 状態版、期限、集約規則、判定元を記録するプライバシー保護型のIRTアクセス判定レシートがあれば、アドレスや検証コードを公開せずに結果を再現できる。

古い結論を入口に置き続けない

IRT連絡先が未検証だった時点で、あるアカウントに制限が計算されたとする。その後、連絡先が検証を完了しても、ログイン側が以前コピーしたフラグしか見なければ、原因が消えた後も制限が残りうる。逆に、連絡先の有効性が変化した後も、以前の許可が残る可能性がある。

APNICは特定の会員にこの事象が起きたと述べてはいない。公開ロードマップでは、アカウントが誤ってロックまたはアンロックされたままになることを「防ぐべき結果」として示している。提案された解決策は、すべてのIRTメールを継続的に追跡し、静的ロックフラグではなくログイン時に有効性を確認することだ。担当はMembershipチーム、対象製品はAPNIC LoginとWhois、目標は2026年第3四半期である。

ロックフラグは、ある時点の証拠から導かれた結論にすぎない。連絡先の現在の有効性は、その結論を再計算する入力である。アクセス要求の瞬間に入力を読む設計は、証拠と決定がずれる時間を短くする。

ただし、ロードマップは最終的なデータ構造や展開日、複数のIRTオブジェクトを持つアカウントの扱い、複数メールの集約方法を公表していない。稼働済みとも述べていない。「現在」という言葉には、参照した集合、時刻、規則が必要である。

既存制度には三つの時計がある

APNICでは prop-125 が実施済みとして記録されている。現行の番号資源ポリシーは、各資源レコードにIRTオブジェクトを求める。そこに記載された email と abuse-mailbox は監視され、届いた不正利用の通報には速やかに対応しなければならない。

検証には三つの時間軸がある。連絡先は定期的、または6か月ごとに検証される。検証メールを受けたアカウント保有者には15日が与えられ、失敗するとWhois上のIRTオブジェクトがInvalidと表示される。30日後も失敗が続けば、検証が完了するまでMyAPNICへのアクセスが制限される。

2019年の実施案内は、制度の開始を2019年6月30日としている。公開検証フォームでは、メールで受け取った固有コードを入力する。完了イベントは、その時点でメッセージへアクセスできたことの証拠になる。

ログイン時の確認が、これら三つの時計を置き換えるとは示されていない。6か月は新しい証拠が必要になる時期、15日はオブジェクトの表示状態、30日はポータルアクセスへの影響を決める。ログインは、それらの結果を読む判定時点である。

したがって「制限中」という結果だけでは足りない。検証期限、15日または30日の境界、オブジェクト変更、別の連絡先、古いスナップショットのどれが理由かを残す必要がある。

一つのフラグの背後に五つの状態がある

メールアドレスには機微な値と履歴がある。検証チャレンジには発行、配送、期限、完了がある。IRTオブジェクトにはキー、版、属性がある。APNICのIRTオブジェクトガイドは e-mail と abuse-mailbox を分け、mnt-by で変更を許可するメンテナーを示す。

さらに、どの資源、IRTオブジェクト、連絡先がアクセスに関係するかというアカウント範囲がある。最後に、規則の版と状態スナップショットを使い、許可または制限と理由を返すログイン判定がある。

これらは連結されるが、同じものではない。一つのアドレスの検証は二つ目を自動的に有効にしない。オブジェクトの編集で対象アドレスが変わる。複数資源を持つアカウントは複数のIRTを参照しうる。ある瞬間に正しかった判定も、次の検証や編集後には古くなる。

継続追跡を意味あるものにするには、結合関係を明示しなければならない。APNIC Loginは、対象オブジェクト、関連する属性、各状態を生んだイベント、結果をまとめる規則を知る必要がある。そうでなければ、不透明な静的フラグが不透明なライブ照会に置き換わるだけだ。

難所は複数連絡先の集約規則

一つのIRTに二つの不正利用窓口と一般メールがある場合、三つすべてが有効でなければならないのか。一つの abuse-mailbox で足りるのか。同じアドレスが複数オブジェクトに現れるとき、一回の検証はすべてを更新するのか。資源ごとのIRT状態が食い違えば、アカウント全体、特定機能、該当資源のどこまでを制限するのか。

公開ロードマップに回答はない。本稿は回答を推測しない。ただし、選ばれた規則に名称と版が必要だとは言える。「ログイン時に有効性を確認した」という説明は、確認対象と集約方法が分かって初めて再現可能になる。

原証拠と派生判定は階層化できる。イベントは、あるアドレス識別子のチャレンジが完了した時刻を記す。状態レコードは、有効期間と次の期限を示す。IRT評価は採用した状態を列挙する。アカウント判定はその評価と規則版を参照する。後の修正は以前の証拠を消さずに結論を更新できる。

この分離は障害対応にも効く。10時04分に検証が完了し、10時05分のログインが制限された場合、伝播遅延か、別の期限切れアドレスか、範囲規則の違いかを切り分けられる。それぞれ担当も対処も異なる。

メールの支配と苦情対応は別の証拠

prop-125は、不正利用対応者へ連絡できる状態を保つことを目指す。しかしコード入力が証明するのは、そのメッセージにアクセスできる誰かがチャレンジを完了したことだけである。その後の全通報が正しいキューへ入り、フィルターを通り、人に読まれ、解決されたとは証明しない。

反対に、チャレンジの期限切れは、メールボックスの不存在や特定通報の無視を証明しない。配送、アクセス、監視、トリアージ、解決は別々の観測である。

この境界は双方を守る。通報者に「有効」という表示だけで良好な処理を保証してはならない。会員を、検証期限が過ぎただけで不正利用の当事者と断定してもならない。MyAPNIC制限は連絡先検証に結びついたアカウント管理上の結果であり、司法判断、資源取消し、ネットワーク行為への裁定ではない。

判定元を残すレシート

APNICは、IRTアクセス判定レシートによって新しい制御を監査可能にできる。これは本稿の提案であり、APNICが公表した約束ではない。レシートはアドレスとコードを秘匿しながら、次を記録する。

  • 判定時刻とプライバシー保護されたアカウント参照；
  • 対象IRTオブジェクトのキーと版；
  • 各メールのマスク済み識別子またはハッシュ；
  • 直近の成功イベント、現状態、その発効時刻；
  • 6か月、15日、30日の各期限；
  • 範囲、集約、ポリシー規則の版；
  • APNIC Loginが実際に読んだスナップショット；
  • 許可・制限、理由コード、判定元；
  • 再審査、訂正、後続判定への参照。

移行中の「判定元」は、ライブなIRT評価と旧フラグ由来の結果を区別する。両者を並行計算し、差異を分類し、説明不能な差が十分に減ってから旧経路を廃止できる。

閲覧範囲は分けられる。会員にはマスク済み連絡先と期限、サポートには追加のイベント参照、外部証明にはレシートのダイジェストと型付き状態だけを示せばよい。監査可能性はメールアドレスの公開を意味しない。

情報源