要約

  • 「novacloud-admin」という正確なハンドルを持つ役割オブジェクト、人物オブジェクト、メールボックスは、調査対象のレジストリ資料では確認されていない。
  • 最も近い登録オブジェクトは、AS209874 に付属するメンテナー novacloud-mnt であり、メンテナーと管理役割は RPSL 上で別個の役割である。
  • AS209874（登録名 NovaCloud-Hosting Network）は組織オブジェクト ORG-MWUL2-RIPE＝Tech Tide Portugal Unipessoal LDA（PT、登録番号 517354420）に帰属し、admin-c/tech-c は役割オブジェクト novacloud-hosting（NA8939-RIPE）、abuse-c は NA8940-RIPE である。
  • AS214789（as-name nova-cloud-kz）は組織オブジェクト ORG-NC138-RIPE＝Nova Cloud LLP（KZ、登録番号 240440015497）に帰属し、別の運営者と別のabuse対応窓口を持つ。

役割アカウントが示さないもの

文字列「novacloud-admin」は管理的な機能を示唆するが、RIPEデータベースのオブジェクト解説によれば、役割（role）オブジェクトは一人以上の人間が担う役割を記述するために存在し、メンテナー（mntner）オブジェクトはオブジェクト生成を守護する別個の仕組みである。その作成手順とデータの整理方法、最初の役割・メンテナーの作成手順も公開文書になっている。つまり「admin」という語を含む表示名は、それ自体では管理権限の証拠にならない。今回調査した公開資料では、この正確なハンドルを持つオブジェクトは見つかっていない。

管理権限の実際の帰属先

AS209874 の aut-num オブジェクト（IP.SBのWHOIS/RDAPミラー、IPIP.NETのミラー）は、admin-c と tech-c に役割オブジェクト novacloud-hosting（NA8939-RIPE、2024-09-13作成）を指定し、abuse-c に NA8940-RIPE を通じて novacloud-hosting.com ドメインの abuse 型メールボックス を登録している。組織オブジェクト ORG-MWUL2-RIPE は Tech Tide Portugal Unipessoal LDA（ポルトガル、登録番号 517354420）であり、mnt-by には RIPE-NCC-END-MNT、SBL-MNT、novacloud-mnt が並ぶ。ミラー上のタイムスタンプでは、aut-num は 2026-02-26、組織オブジェクトは 2026-05-13 に最終更新されている。

一方、AS214789 の記録（CIDR Report、IPIP.NET）は、組織オブジェクト ORG-NC138-RIPE「Nova Cloud LLP」（カザフスタン、登録番号 240440015497）に帰属し、admin-c/tech-c は MV16118-RIPE、abuse-c は NA8821-RIPE（novacloud.kz ドメイン ドメイン）、mnt-by は RIPE-NCC-END-MNT と kz-novacloud-mnt である。aut-num は 2024-05-31 に作成され、2024-07-02 に最終更新された。両ASの間に同一の実益所有者を示す公開文書は確認されていない。

レジストリ記録と運営者自己提示の食い違い

運営者自身のサイト（as209874.net）は AS209874 を「NovaCloud-Hosting Network」として提示し、欧州全域の IP トランジットを提供すると説明するが、公表されている運用窓口は as209874.net ドメインの NOC 型メールボックス という NOC 型メールボックスである。これはレジストリ上の abuse 窓口（novacloud-hosting.com ドメインの abuse 型メールボックス ドメイン）とは異なる。運営者側の自己提示としては一般要件ドキュメント、インプリント、トラフィック統計、nodedata.ioの記録がある。さらに、役割オブジェクト novacloud-hosting の住所（ファロ）と組織オブジェクトの住所（カルテイラ）は同一登録者でありながら一致しない。公開記録内部のこの不整合は、表示名だけでは解決できない。

RDAP の構造化された表現

AS209874 の RDAP 応答は、fn「novacloud-abuse」、kind「group」、abuse 型のメールを持つエンティティを提示する。RDAP のエンティティ役割と vcard の「group」種別は RFC 9083 と IANA の rdap-json-values 登録簿で標準化されており、責任の所在は表示名ではなく構造化された役割フィールドで伝達される設計であり、RDAP応答プロファイルは応答の正確性と一貫性を求めている。

課責の仕組みはどこにあるか

RIPE の abuse-c 情報に関する文書と RIPE-705 は、abuse 対応の義務を組織または役割オブジェクトに付与し、abuse 問い合わせ先の照会方法も文書化されている。コミュニティでの要件形成の経緯は 2019-04 提案のアーカイブに記録されている。ICANN 側では 登録データポリシーが契約当事者の収集・公開データを規定し、コンプライアンス申立て窓口が公開連絡義務の不履行の経路を提供する（申立て）。ルーティングポリシーと管理の登録自体は RPSL（RFC 2622）とその拡張 RFC 2280 が定義する。すなわち、課責はオブジェクトに付随し、表示名には付随しない。

不確実性の境界

本稿のレジストリ詳細は第三者ミラーと公開ページの読み取りに依存しており、生の RIPE RDAP に対して遅延している可能性がある。ベンダーによる AS209874 の分類も食い違う（IPinfo は「hosting」、IPGeolocation.io は「ISP」）。AS209874 の割当日（2025-04-24）と最初に観測されたルート発信（2018-11-18）の矛盾は、番号の前保有者の存在を示唆するが確定していない。abuse 対応の実績や争議記録は、いずれの運営者についても確認されていない。ディレクトリ上の「COMPANY」ラベルは編集上の推定である。個別IPアドレスの帰属（194.164.115.241）も、運営者の公開面を補う観測点である。

番号資源の一次記録はRIPEデータベースの検索で直接照会でき、bgp.toolsのAS214789ページやbgpthingyのエンティティ記録は観測の補助源になる。