要約

  • Richard Laagerは提案2026.4で、自分の親NETから別組織へ詳細再割り当てを行うと、親側APIキーによる子NETのハンドル指定GETが拒否されると報告した。同じ側のキーで削除とmostSpecificNetによる範囲検索は可能で、受け手側のキーならハンドルGETもできたという。
  • ARINは2026年3月30日、既存の検索手段と今後の開発計画を検討した結果、現時点でAPI権限の変更は不要と回答した。提案は提出者の同意を得て終了した。

子NETの識別子を入力すると読めない。アドレスの両端を入力すると見つかる。削除の操作も親側には残る。Richard LaagerがARINの提案2026.4に書いた再現手順は、APIの認可が対象物だけで決まらないことを示した。まず自分のNETから別の組織へ詳細再割り当てを行う。次に親側のAPIキーで、作成した子NETのハンドルを指定してGETする。返答は権限不足だった。

詳細再割り当てでは、記録に関わる組織が一つから二つになる。ARINの資源管理案内によれば、受け手はOrg IDを持ち、再割り当てされたアドレスを管理できる。直接登録した元の組織には、その再割り当てを回収する力が残る。IRRオブジェクトと逆引きDNSでは管理が共有される。双方が同じ子NETに関係を持つ。だからこそ、どの関係をどのAPI操作が認めるのかが問題になる。

Laagerは複数の入口を列挙した。受け手組織のAPIキーはハンドル指定GETに成功する。親側キーはそこで拒否されるが、mostSpecificNetに開始・終了IPアドレスを渡せば子NETを取得できる。親側からのDELETEも可能だという。匿名のWhoisでも、ハンドルかアドレスから同等の公開情報が見られる。秘匿すべきデータを遮断した、という単純な説明では収まらない。親側の身元と「ハンドル指定」という入口の組み合わせが拒否されている。

Reg-RWSのメソッド案内は、各入口を別々に定義している。GET /rest/net/NETHANDLEはNETのデータを返す。GET /rest/net/mostSpecificNet/STARTIP/ENDIPは範囲に対する最も具体的なNETを探す。DELETE /rest/net/NETHANDLEは再割り当てまたは再配分の削除についてチケット付きの要求を起こす操作であり、直接割り当ての一般的な即時削除ではない。PUT /rest/net/NETHANDLEは送信したデータでNETを変更する。範囲検索が通っても、ハンドル指定の読取りが通る保証は生まれない。

この違いは自動化で重くなる。再割り当てを作った管理システムは普通、返された子NETハンドルを記録する。次の照合でそのハンドルを読めなければ、アドレス範囲も保存し、別のメソッドを呼び、返ってきたハンドル、親、範囲、受け手組織を確認して初めて同一の記録と判断する。Whoisは人の調査に役立つが、認証付きの登録APIとは別の証拠経路だ。読取りの失敗を「存在しない」と扱って削除・再作成へ進めば、顧客の登録記録をデバッグ用の使い捨て品にしてしまう。

LaagerはGETを広く認めるよう求めた。親が子を削除して作り直せるならPUTで直接変更できるべきだとも論じた。読取りと書込みは別の権限判断である。NET変更案内が扱うネットワーク名、連絡先ハンドル、公開コメントを書き換える権限は、公開済みの情報を取得する権限より重い。PUTの拡張は提出者の提案であり、ARINの決定ではない。

ARINの回答は3月30日付だ。既存の別の検索方法と将来の開発予定を検討し、現時点でAPIの権限チェックを変更する必要はないとした。提案はLaagerの同意を得て閉じた。回答はハンドルGETの修正を発表していない。使える別の道を使うよう、利用者側に判断を置いた。

現在の本番環境で両組織のキーを使い、文書化された各呼び出しを試した記録があれば、3月以降もこの拒否が続いているか確定できる。公開資料が示すのは報告された手順と、ARINが現行チェックを維持したという決定だ。それだけでも運用上の差は明白である。ハンドルGETの権限エラーとNETの不存在を同じ分岐に置く設計は危うい。

一つの子NETに複数の関係が残り、入口ごとに答えが変わる。ARINはその門の配置を維持した。母NETを管理する組織のソフトウェアは、名前で開かない記録を住所から探し、同じものかどうかを毎回証明することになる。

提案2026.4とARINの回答 · Reg-RWSメソッド · 資源管理案内 · NET変更案内