要約

  • iRegistry GmbH は、購入単位が未加工のドメイン名ではなく、ICANN 向けコンプライアンス業務、レジストラ向け継続性、不正利用対応、データ保護規律、そしてより大規模な技術バックエンドへの依存というパッケージである、レジストリサービスアカウントとして理解するのが最も適切である。
  • 最も直接的な公開証拠は、iRegistry と.richトップレベルドメイン、ベルリンの住所、ICANN レジストリ契約、公開不正利用およびポリシーページ、そして IANA リスト（Identity Digital が技術連絡先と RDAP インフラを提供）を結びつけている。
  • 投資ケースは、不足している非公開指標によって制約される。公開情報源は、更新率、アクティブなレジストラの貢献、バックエンド料金、サポートチケット件数、不正利用キュー、プレミアム名販売、粗利益率、顧客集中度を開示していない。
  • 競合は小規模レジストリ事業者よりも広い。購入者は、内製レジストリスタックの構築、大規模バックエンドレジストリプロバイダーとの契約、ccTLD パートナーとの連携、レジストラ限定流通への問題縮小、または名前空間の放棄を行うことができる。
  • この製品は制約下の信頼である。レジストラパートナーが、iRegistry が名前解決を維持し、サポートケースに対応し、不正利用報告を処理し、プライバシー規則を遵守し、バックエンド移行を乗り切ることができると信じれば、小規模な名前空間でも高い公開ボリュームがなくとも商業的に存続可能である。

購入者の決断は更新時期に始まる。TLD 所有者、ブランドスポンサー、またはレジストラチャネルパートナーは、委任された名前空間を新しい運営モデルに置き換えるよりも、継続する方が安価で安全かどうかを判断しなければならない。購入者が実際に購入するのは、ウェブサイト、ネーミングのアイデア、または一回限りの立ち上げプロジェクトではない。購入単位は、稼働中のレジストリアカウントである。すなわち、認定レジストラがドメイン名の作成、更新、移管、ロック、照会、サポートを行える常設サービスであり、その間、事業者は規制当局に対応し、登録データを預託し、DNS サービスの可用性を維持し、RDAP アクセスを実行し、不正利用通知を処理し、TLD をルートに維持するための書類業務を続ける。iRegistry GmbH にとって、このアカウントは特に欧州的な形状を持つ。公開記録は、同社をベルリンに位置づけ、.richに結びつけ、その価値が生の技術ホスティングと同様に法的継続性とチャネル信頼に依存するレジストリ運営を示している。

この枠組みは重要である。なぜなら、価格比較の様相を変えるからだ。iRegistry の代替案は、単なる「別の小規模レジストリ」ではない。最初の代替集合には、内製レジストリスタック、大規模バックエンドレジストリプロバイダー、ccTLD パートナー、レジストラ限定流通、そして名前空間の放棄が含まれる。各オプションは負担の移動方法が異なる。内製スタックは制御をもたらすが、24 時間体制のエンジニアリング、EPP 運用、DNS の専門知識、プライバシー対応、ICANN コンプライアンス能力を要求する。大規模バックエンドプロバイダーは運用リスクを低減するが、TLD 所有者を集中型プラットフォーム内の小口アカウントにしてしまう可能性がある。ccTLD パートナーは、公共信頼の経験と国家レジストリの規律をもたらすかもしれないが、必ずしも同じ商業的柔軟性を持つとは限らない。レジストラ限定流通は、TLD 運営の負担を回避しながら販売への関心を維持できるが、レジストリ管理の経済性と権限を放棄することになる。名前空間の放棄は、コンプライアンスコストとサポートリスクを取り除くが、オプション価値、ブランドの希少性、既存の登録者基盤を破壊する。

最も明確な公開アンカーは、.richの IANA ルートゾーンエントリである。IANA は、スポンサリング組織として iRegistry GmbH（ベルリン、Friedrichstr. 171）を挙げ、登録日を 2014 年 1 月 16 日、最終更新日を 2025 年 6 月 23 日としている。同じ IANA エントリは、技術連絡先として Identity Digital をリストし、a0.nic.rich、a2.nic.rich、b0.nic.rich、c0.nic.richを権威ネームサーバーとして挙げ、TLD の RDAP エンドポイントとして Identity Digital の RDAP サービスを特定している：https://www.iana.org/domains/root/db/rich.html。これは完全なビジネスモデルではないが、運営アカウントの所在を特定するには十分である。iRegistry は公開委任記録におけるレジストリスポンサーであり、Identity Digital は技術層に可視的であり、レジストラと登録者はその結合された運営チェーンの継続性を通じて製品を体験する。

また、証拠の周りには境界がある。公開情報源は、iRegistry が.richに結びついていること、当該 TLD が ICANN レジストリ契約を有していること、レジストリが連絡先、ポリシー、不正利用資料を公開していること、ICANN が iRegistry TLD に関連するサービスリクエストを処理したこと、そして Identity Digital が技術および RDAP の役割に登場することを証明している。公開情報源は、レジストリ契約に組み込まれ TLD が委任されたままであることから、継続的なコンプライアンスおよびサポートのワークロードが存在することを示唆する。それらは、収益、収益性、更新の集中度、直接の人員配置、バックエンド料金水準、アクティブレジストラ数、実際のサポート応答時間、不正利用チケット量、訴訟エクスポージャー、または iRegistry とその技術サプライヤー間の商業条件を証明しない。単一の非公開指標が判断を変える可能性がある。少数のプレミアム更新とレジストラアカウントが、ICANN コンプライアンス、バックエンドサービス、データ保護作業、エスカレーション業務の固定費を上回るかどうかである。

歴史も重要である。ICANN の.rich向けレジストリ契約ページは、現在のレジストリ事業者として iRegistry GmbH を挙げ、元の契約日を 2013 年 11 月 21 日と記録している：https://www.icann.org/en/registry-agreements/details/rich。元の.rich契約本文は、I-REGISTRY Ltd., Niederlassung Deutschland（ドイツ支店）を参照しており、その後の修正資料は iRegistry GmbH への移行を記録している：https://itp.cdn.icann.org/en/files/registry-agreements/rich/rich-agmt-html-21nov13-en.htmおよびhttps://itp.cdn.icann.org/en/files/registry-agreements/rich/rich-amend-1-pdf-06oct20-en.pdf。購入者にとって、この継続性は表面的なものではない。TLD はルートゾーン依存性と登録者義務を持つ契約資産である。事業者識別、技術サプライヤー、サービス設計の変更は、通常のホスティングベンダーを交換するのとは異なる。それらは、ICANN 通知、レジストラの期待、ポリシー継承、データアクセス義務を経由し、場合によっては IANA ルートゾーン更新を伴う。

.onlの歴史は、同じタイプの運用負担を示すため有用だが、過大評価すべきではない。IANA は現在、.onlのスポンサリング組織として Jolly Host, LLC を挙げ、2026 年 3 月 4 日に更新され、リンクされた移転レポートがある：https://www.iana.org/domains/root/db/onl.html。これは、.onlが現在、iRegistry がまだ TLD をスポンサーしている証拠ではないことを意味する。代わりに、それは以前の iRegistry 関連の名前空間の証拠であり、TLD が所有者を変えるときに発生しうる移転イベントの一種の証拠である。ICANN の公開契約資料には、.onlに関する 2026 年の譲渡・承継と、.onlおよび.richの更新期間に言及した 2023 年の更新通知が含まれる：https://itp.cdn.icann.org/en/files/registry-agreements/onl/onl-assign-pdf-01-02-2026-en.pdfおよびhttps://itp.cdn.icann.org/en/files/registry-agreements/onl/onl-renewal-1-16-09-2023-en.pdf。重要な教訓は、.onlが iRegistry 製品であり続けているということではない。レジストリアカウントは正式な移行経路を通じてのみ移動可能であり、その移行リスクがレジストリサービス労働の価格の一部を成すということである。

レジストリ契約は、こうした観察をコスト構造に変換する。gTLD 事業者は、データエスクロウ、月次報告、登録データの公開、レジストリ相互運用性、権利保護措置、無差別のレジストラアクセス、公開 DNS ルックアップサービス、コンプライアンス監査準備、事業継続手段、緊急移行義務、技術パフォーマンス記録、個人データ保護措置を維持しなければならない。これらの義務は、マーケティング用語から推測されるのではなく、.rich契約本文に可視的である。商業的な要点は、各義務が反復的な作業を生み出すことである。誰かがカレンダーを回し、ファイルを照合し、レジストラの質問に答え、ポリシーページを最新に保ち、サービス可用性を監視し、データ預託を検証し、ICANN の通信に対応し、サービス設計の変更がコンセンサスポリシー義務を破らないようにしなければならない。小規模な名前空間では、これらのタスクがコストベースを支配しうる。購入される製品は、この地味な作業を続ける事業者の意欲である。

EPP は最初の技術的インプットだが、機能リスト上の単なるプロトコル略語ではない。RFC 5730 は、Extensible Provisioning Protocol を、共有の中央リポジトリに保持されたオブジェクトのプロビジョニングと管理のためのアプリケーション層のクライアント・サーバープロトコルとして定義している：https://www.rfc-editor.org/info/rfc5730。RFC 5731 はそのモデルをドメイン名に適用する：https://datatracker.ietf.org/doc/html/rfc5731。商業的には、EPP はレジストラ向けの生産ラインである。レジストラは、名前の作成、更新、移管、連絡先更新、ステータスコード適用、顧客ワークフローの安定化にこれを使用する。レジストリ事業者は、単に EPP を話すことに対して報酬を得るのではない。報酬は、レジストラが実装を信頼し、オンボーディングおよびテスト環境が機能し、価格とプレミアム名ルールが理解可能であり、ロックやホールドコマンドが予測通りに動作し、サポートスタッフが更新時に注文が失敗した場合に回答できるから得られる。

DNS は第二のインプットであり、顧客が障害時にしか気づかない部分である。IANA の.richエントリには、nic.rich配下の 4 つの権威ネームサーバーが、IPv4 および IPv6 アドレスと共にリストされている。そのリストは、サービス境界の公開の兆候であり、すべての運用詳細の証明ではない。購入者が気にするのは、エニーキャストの多様性、DNSSEC、ルートゾーン委任の衛生、変更管理、インシデント対応、監視である。ICANN のレジストリパフォーマンス義務は、この問題を技術的かつ契約的なものにする。TLD の解決が不十分であれば、レジストラは顧客クレームに直面し、登録者はビジネス中断に直面し、事業者は信頼喪失に直面する。これが、登録ボリュームが低い場合でも、小規模なレジストリアカウントが意味のある固定費を持ちうる理由である。DNS 層は、キャンペーン資産ではなく、インフラとして運用されなければならない。

データエスクロウは第三のインプットであり、登録者がほとんど目にしないため過小評価されがちである。ICANN は、レジストリデータエスクロウを、レジストリが障害を起こした場合や移行が必要な場合に登録者を保護するために必要な登録データを、レジストリ事業者が保存するメカニズムと説明している：https://www.icann.org/resources/data-escrow-services-en。.rich契約のエスクロウ仕様は、定期的な全量および差分預託を要求し、タイミング、フォーマット、検証の期待を設定する。これにより、預託の生成、暗号化と送信、例外の解決、連絡先役割の最新維持、エスクロウプロバイダーとの調整、不一致の照合といった複数箇所で作業が発生する。小規模 TLD では、エスクロウ作業が一般の想像以上に運営コストの大きな割合を占める可能性がある。エスクロウ要件は継続性に価格を付ける。それは、レジストリが継続できない場合に登録者と ICANN に道筋を与え、事業者に回復可能なデータ規律の維持を強制する。

したがって、コストの段落は、ある一つの公的な料金項目というよりも、固定的な義務に関するものである。iRegistry を検討する購入者は、EPP 可用性、権威 DNS、DNSSEC 維持、データエスクロウ、RDAP サービス、不正利用トリアージ、ICANN 報告、法的通知対応、レジストラサポート、プライバシー審査、ポリシー更新、サービス変更申請、管理時間の年間コストを比較しなければならない。ICANN のアサインメントページは、アサインメント審査手数料がケースバイケースで設定され、通常、単一 TLD の新たなレジストリ事業者へのアサインメントについて 19,000 米ドルを超えないとしている：https://www.icann.org/resources/assignments。これは完全な切り替えコストではないが、正式な事業者変更にもプロセス費用が伴うことを示唆している。市場の反対側では、大規模バックエンド契約に関する業界報道が、高ボリュームのレジストリバックエンドサービスが場合によっては 1 ドメインあたり 1 ドル近くになる可能性があることを示唆しているが、そのベンチマークは低ボリュームのプレミアムまたは専門 TLD に直接適用できるものではない。小規模な名前空間では、関連する単位コストは、薄い登録ベースで割られた固定労務費に、レジストラの信頼を維持するためのリスクプレミアムを加えたものである。

RDAP と登録データポリシーは別の層を追加する。ICANN は、gTLD レジストリとレジストラは RDAP サービスを提供する必要があり、2025 年 1 月 28 日以降は WHOIS サービスを提供する必要がなくなったと述べている：https://www.icann.org/en/contracted-parties/registry-operators/resources/registration-data-access-protocol。ICANN の登録データポリシーは、移行期間を経て、2025 年 8 月 21 日に契約当事者に対して発効した：https://www.icann.org/en/announcements/details/icann-registration-data-policy-now-in-effect-for-contracted-parties-21-08-2025-en。iRegistry にとって、IANA エントリの RDAP 参照は Identity Digital の RDAP サービスを指している。このことは、製品の一部が調整サービスであることを意味する。レジストリスポンサーは、登録データアクセスルールが変更されたときに、自らの公的義務、サプライヤーのパフォーマンス、レジストラの期待が整合するようにしなければならない。

欧州のプライバシー法はその調整をより困難にする。欧州委員会は、管理者を、個人データの処理の目的と手段を決定する当事者と説明し、処理者は管理者に代わって個人データを処理するとしている：https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/controllerprocessor/what-data-controller-or-data-processor_en。レジストリの文脈では、実際の作業はプライバシー文言の作成に限らない。事業者は、誰が登録データを受け取るか、どのような公開データが公開されるか、法執行機関や不正利用の要請がどのように処理されるか、どのようなレジストラデータが保持されるか、アクセスがどのように記録されるか、サプライヤーの役割がどのように文書化されるかを理解しなければならない。国際的なバックエンドを通じて業務を行うベルリンのレジストリスポンサーは、このデューデリジェンスをサービスに価格付けしなければならない。コンプライアンス業務は、脇の事務所ではない。それは、レジストラと TLD 所有者に販売されるレジストリ製品の一部である。

不正利用対応は、コンプライアンスがチャネル信頼と出会う場所である。.richの公開ポリシーページは、不正利用報告連絡先を特定し、レジストリが追跡しうる指標の種類（不正利用報告受信件数、レジストラへの照会、レジストリによる直接措置、解決時間、アンチスパムブラックリスト参照、フィッシングサイトの稼働時間を含む）を説明している：https://www.nic.rich/policies.php。同ページはまた、孤立グルーや保留ステータスについても論じており、保留がドメインをゾーンから削除し、悪意のあるドメインを停止するためのツールであるという考えを含む。ICANN の 2024 年の DNS 不正利用義務に関する勧告は、マルウェア、ボットネット、フィッシング、ファーミング、スパム（配信メカニズムとして使用される場合）といった不正利用カテゴリに対する緩和措置を義務付けるために、レジストリとレジストラの義務がどのように修正されたかを説明している：https://www.icann.org/en/contracted-parties/advisories/documents/advisory-compliance-with-dns-abuse-obligations-in-the-registrar-accreditation-agreement-and-the-registry-agreement-05-02-2024-en。これにより、不正利用対応が運営コストと信頼性テストに変わる。

不正利用の経済学は微妙である。小規模で高価格の名前空間は、マスマーケット TLD よりもクレームが少ないかもしれないが、各クレームは依然として実際の判断を必要とする可能性がある。事業者は、問題がレジストラに属するかどうか、証拠が信頼できるかどうか、直接的な保留が正当化されるかどうか、登録者に通知すべきかどうか、プライバシー規則が開示を制限するかどうか、そしてその決定が異議を申し立てられた場合に防御可能かどうかを決定しなければならない。迅速な停止は申立人を満足させるかもしれないが、証拠が弱い場合に信頼を損なう。ゆっくりとした対応は適正手続を保護するが、名前空間を風評被害にさらす可能性がある。レジストラが気にするのは、予測不能に停止したり深刻な不正利用を無視したりするバックエンドを望まないからである。その意味で、不正利用対応は単なるリスク管理ではない。それは、レジストリアカウントの観察可能な機能の一つである。

レジストラの信頼は中心的な商業チャネルである。.richサイトは、この名前空間をプレミアムアイデンティティの提案として提示し、ユーザーをレジストラチャネルに誘導する：https://www.nic.rich/。レジストリ契約は、登録が ICANN 認定レジストラを通じて行われ、統一されたレジストリ・レジストラ契約の下での無差別アクセスを要求している。つまり、iRegistry の直接の顧客問題は主にチャネル問題である。レジストラは、その TLD が掲載する価値があり、技術的に安定しており、サポートチームが理解可能であり、顧客紛争を避けるのに十分商業的に明確であると信じなければならない。レジストラが高価格、不明瞭なプレミアムルール、遅いサポート、または混乱を招くデータアクセス行動を見れば、その TLD は摩擦のある棚スペースになる。安定した EPP 動作、予測可能なポリシー、明確な連絡先、機能する不正利用エスカレーションを見れば、ニッチな TLD でもカタログに留まることができる。

サードパーティの市場見解は、この空間のプレミアム性を強調すると同時に、公開の可視性の限界も示している。TLD-List は、.richを複数のレジストラ小売オファー、DNSSEC サポート、および iRegistry GmbH へのレジストリ参照と共にリストしている：https://tld-list.com/tld/rich。小売価格ページは公式レジストリデータより遅れることがあり、ホールセールマージンを証明しないが、それらはチャネル提示に関する有用なシグナルである。高い広告小売価格を持つプレミアムまたは専門 TLD は、安価な大量ボリューム拡張とは異なるサポート姿勢を必要とする。レジストラは、顧客注文は少ないが、価値、更新コスト、移管ポリシー、適格性、プレミアム名、紛争処理についてより多くの質問を期待する。レジストリアカウントは、ボリューム単独ではなく、信頼を中心に設計されなければならない。

バックエンドプロバイダーの集中は、公開技術層に可視的である。Identity Digital は、IANA において.richの技術連絡先として登場し、Identity Digital の RDAP サービスが公開 RDAP エンドポイントとなっている。Identity Digital は、180 以上の他の gTLD、ccTLD、ドットブランド顧客向けのレジストリサービスを販売し、より大きな TLD セットの ICANN 指定事業者であると自らを説明している：https://identity.digital/registry。iRegistry にとって、この集中は強みであり依存でもある。これは、経験豊富なプラットフォーム、既存のレジストラ統合、成熟した RDAP および DNS 運用、小規模事業者が再現するのに苦労するであろうサポート慣行へのアクセスを提供する。また、レジストリスポンサーの運営上の評判が、優先順位、価格設定、ロードマップがより大きな顧客ベースによって形成されうるサプライヤーに部分的に依存することを意味する。

この依存は iRegistry に固有のものではない。CentralNic Registry は、165 以上のドメイン拡張向けのサービスを販売し、レジストリ、DNS、不正利用、チャネル機能を TLD 事業者に売り込んでいる：https://centralnicregistry.com/services/。Nominet は、1,000 万を超えるドメインがあると説明する.ukの運営経験からレジストリサービスを販売している：https://nominet.uk/registry-services/。Verisign は、.comや.netといった非常に大規模なレジストリプラットフォームを中心に、レジストラリソースと EPP 資料を提供している：https://www.verisign.com/resources/registrar-resources/epp-sdk/。これらは iRegistry のコストに関する直接の証拠ではない。それらは購入者の代替集合を定義する。購入者は、スケールのあるプラットフォームプロバイダー、国家名前空間の経験に根ざしたレジストリ、大規模な既存バックエンド、または商業的焦点とアウトソースインフラをバンドルする小規模スポンサーアカウントを選択できる。

ccTLD パートナーの代替案は別途注目に値する。例えば DENIC は、.deの長期運営経験に基づき、エニーキャストおよびレジストリ関連サービスを販売している：https://www.denic.de/en/products/anycast-for-tld-registries/。DENIC Services はまた、TLD 事業者向けのレジストリデータエスクロウサポートも説明している：https://www.denic-services.de/en/services/data-escrow。ccTLD に根ざしたパートナーは、運用の保守性、欧州の法的近接性、公共サービス文化を重視する購入者に訴求するかもしれない。トレードオフは、すべての ccTLD パートナーがニッチな gTLD の商業的負担を引き受けたがるわけではなく、すべての gTLD 所有者が国家レジストリスタイルのガバナンスを望むわけではないということである。iRegistry の潜在的なニッチは異なる。それは、コンプライアンスとレジストラ作業を特定の名前空間に結びつけたまま、TLD を国家レジストリのサービスカタログの一小項目にするのではなく、コンパクトな欧州スポンサーアカウントである。

内製の代替案は最も制御が重い。レジストリスタックを内部で構築するということは、EPP サーバー機能、DNS 運用、RDAP、課金ロジック、プレミアム名サポート、レジストラオンボーディング、不正利用ツール、データエスクロウ生成、ICANN 報告、ポリシー管理、24 時間対応のインシデントレスポンスを取得または開発することを意味する。それはまた、少数の名前しかない新しいバックエンドに対してほとんど忍耐を持たないレジストラからの信頼テストに合格することも意味する。ブランドや投資家は、かなりのボリュームが期待できる場合、あらゆる技術層をコントロールする戦略的理由がある場合、または多数の TLD を運営したい場合に、構築を正当化できる。単一のニッチな名前空間の場合、内製構築はしばしば固定費の罠に変わる。購入者は、市場がすでに共有インフラとして販売している能力を再現するためにエンジニアと弁護士に支払う。iRegistry のアカウントは、その固定費の罠を回避しつつ、重要な制御を維持する場合にのみ魅力的である。

レジストラ限定流通は逆の動きである。完全な TLD 運営を維持する代わりに、所有者は既存のレジストラやマーケットプレイスを通じて、ドメイン小売、再販パートナーシップ、プレミアム名ブローカレッジ、ブランドキャンペーンに集中できる。このモデルは、所有者がもはや TLD をスポンサーしない場合、または名前空間が別の事業者に移管される場合に、ICANN 向けの負担を軽減する。商業的資産が望ましい名前のリストであって、長期的な名前空間の権限でない場合に理にかなう可能性がある。しかし、レジストラ限定流通はガバナンスポジションを犠牲にする。所有者はもはや、レジストリ契約、直接的なポリシー設定、サービス変更要求、データアクセス姿勢、長期的な名前空間戦略を管理できない。.richにとって、その公開ピッチが排他性とステータスに依存しているため、レジストリ管理を放棄することは、プレミアム価格設定を支える希少性のストーリーそのものを弱める可能性がある。

名前空間の放棄は最終的な代替案であり、失敗ではなく戦略に見えるため議論するのが最も難しい。しかし、それは現実の経済的選択肢である。更新収入、プレミアム名販売、レジストラの棚価値が固定コンプライアンスコストとバックエンド依存をカバーしない場合、撤退は合理的でありうる。問題は、撤退の価格がゼロではないことだ。登録者には道筋が必要であり、ICANN の継続性義務が適用され、ブランド価値が損なわれる可能性があり、将来の市場状況が改善した場合に事業者はオプション性を失う可能性がある。小規模 TLD は、アイデンティティ需要、プレミアム名の希少性、レジストラチャネルリーチに関する長期オプションでありうる。したがって、それを放棄する決断は、コストゼロのシャットダウンという幻想ではなく、最低限の実行可能品質でアカウントを存続させるコストと比較検討されるべきである。

サービス変更要求は、レジストリ作業が静的でないことを示している。ICANN の Registry Services Evaluation Process ページは、レジストリロック、ラベルブロッキング、ドロップゾーン、IDN サービス変更要求を含む、.onlや.richに関連する要求を列挙している：https://www.icann.org/registries/rsep/。2024 年のレジストリロック要求は、serverUpdateProhibited、serverDeleteProhibited、serverTransferProhibitedなどのサーバーサイドステータスコードを説明している：https://itp.cdn.icann.org/en/files/consensus-policy/rsep-2024035-onl-et-al-request-25oct24-en.pdf。2023 年のラベルブロッキング要求は、iRegistry と影響を受ける TLD をリストしている：https://itp.cdn.icann.org/en/files/consensus-policy/rsep-2023092-onl-et-al-request-17nov23-en.pdf。2025 年の IDN 変更要求は、言語テーブルとルールを管理し続ける必要性を示している：https://itp.cdn.icann.org/en/files/consensus-policy/rsep-2025015-onl-et-al-request-01-06-2025-en.pdf。これらの提出は、サービス証拠であり、収益証拠ではない。それらは、アカウントが継続的な ICANN 向け作業を必要とすることを示している。

レジストリロックは、製品が労働と信頼である理由の良い例である。顧客はロックを、価値あるドメイン名を不正な更新、移管、削除から保護するセキュリティ機能と見るかもしれない。レジストラは、サポートと責任のワークフローを見る。レジストリは、適格性、手順、認証ステップ、緊急経路、ステータスコードの動作、解除メカニズムを定義しなければならない。プロセスが緩すぎる場合、ロックは信頼されない。厳しすぎる場合、正当な緊急変更が困難になる。事業者は、バックエンド機能、レジストラ指示、顧客コミュニケーション、ICANN サービス承認を調整しなければならない。この調整は、サポートスタッフが一貫して実行できる場合にのみ販売可能な機能である。

ラベルブロッキングと IDN 変更も同様の商業的論理を持つ。ブロッキングサービスはブランド保護、紛争リスクの低減、バリアント露出の管理に役立つが、ブロックされたラベル、適格性ルール、価格設定が不明確な場合、レジストラや顧客を混乱させる可能性もある。IDN サービス変更は言語リーチを拡大するが、テーブル、バリアント、表示ルール、レジストラ実装詳細を管理しなければならないため、運用負担を増加させる。ニッチな TLD にとって、そのような機能の追加は自動的に利益を生むとは限らない。それは防御的なものかもしれない。レジストラの期待と互換性を保ち、不正利用、混乱、ブランド安全性への異議から保護する方法だ。事業者は、今日、申請とサポートのコストを支払い、明日のチャネルの信頼性を守る。

したがって、切り替えコストは新しいプロバイダーを選ぶ行為以上のものである。バックエンド移行は、EPP エンドポイント、レジストラ認定、テストシステム、本番資格情報、DNS 公開、DNSSEC 署名、RDAP、データエスクロウ、課金調整、プレミアム名ルール、ステータスコード動作、不正利用キュー、サポート連絡先、公開ポリシーページ、ICANN 通知に触れる。レジストラは、統合の更新、料金ロジックの確認、コマンドの再テスト、カスタマーサポートチームの準備が必要になるかもしれない。IANA ルートゾーンリストは、技術連絡先やネームサーバーの変更を必要とするかもしれない。レジストリは、移行中に名前を失ったり、更新を破壊したり、登録者を混乱させたりするのを避けなければならない。.onlの移管は、移行が起こりうることを示しているが、正式な移行経路の存在が移行を安価にするわけではない。それは単に可能性を示すだけである。

切り替えには力の不均衡もある。大規模バックエンドプロバイダーは、多くの顧客、確立されたプラットフォーム、反復可能な移行プロセスを持っている。小規模 TLD スポンサーはより少ないレバーしか持たない。スポンサーがあるバックエンドを去る場合、新しいサービスが少なくとも以前と同程度に信頼できることをレジストラに納得させなければならない。スポンサーが留まる場合、サプライヤーの価格設定、サービスロードマップ、運営上の選択にある程度の依存を受け入れなければならない。最良のレジストリアカウントは、その依存を透明に管理するものである。すなわち、明確な役割、明確なエスカレーション経路、強力な文書化、テストされた継続性計画、品質に対価を支払うのに十分な商業的マージンである。iRegistry の公開姿勢は、これらのサプライヤーおよびチャネル関係が秩序立っている限りにおいてのみ信頼性がある。

.richブランドの提案は問題を激化させる。マスマーケット TLD は、ボリューム、ディスカウント、幅広いレジストラ自動化に頼ることができる。プレミアムアイデンティティ TLD は、希少性、ポジショニング、信頼で価格を正当化しなければならない。.richの公開サイトは、この拡張子を排他的なオンラインアイデンティティ空間として提示しており、これは登録者が DNS 委任とともにシグナリング価値を購入していることを意味する。そのシグナリング価値は、レジストラがその TLD を不明瞭と扱ったり、サポートが薄く見えたり、不正利用管理が弱く見えたり、所有の歴史が混乱して見えたりすると崩壊する。iRegistry にとって、レジストリ運営は隠れたバックオフィスではない。それは、プレミアムの主張が運営上の実体を持つ証拠である。

レジストラチャネルはまた、サポート労働を運転資本の一種に変える。レジストラはエンドカスタマー関係を担う。更新が失敗したとき、移管がブロックされたとき、不正利用報告が届いたとき、ロック要求が停滞したとき、RDAP の回答がプライバシー問題を提起したとき、レジストラがまず対応しなければならない。レジストリが遅かったり一貫性がなかったりすると、レジストラは風評コストを吸収する。だからこそ、レジストリサポートは臨時の管理業務として価格付けできない。それは、レジストリがレジストラの顧客信頼を借りるメカニズムである。ニッチな名前空間では、少数の経験豊富なレジストラが実際の流通の大部分を占めるかもしれない。そのうちの一つを失うことは、少数の投機的登録を失うことよりも重大でありうる。

月次報告と監査準備は同じ点を補強する。レジストリ契約は ICANN への報告を義務付け、ICANN に監査権を与える。これらの要件は、公開市場がほとんど見なくても、アカウントを規制当局に観測可能にする。事業者は、いくつの名前が存在するか、サービスレベルがどのように機能しているか、レジストラアクセスがどのように管理されているか、どの価格が変更されているか、データがどのように預託されているか、どのサービスがアクティブか、どのポリシーコミットメントが最新かを把握していなければならない。これは華やかな機能ではないが、買い手が即席の内製チームよりも専門アカウントを選ぶ理由の一つである。専門家は、レジストリを回避可能な違反リスクから守る日付、フォーマット、連絡先、証跡をすでに知っているはずである。

同じ分析が価格通知にも当てはまる。レジストリ契約の価格変更条項は、レジストラに初回登録と更新の事前通知権を与える。プレミアム名前空間は価格設定の柔軟性を必要とするが、柔軟性はレジストラの期待と顧客の公平性と調和させなければならない。突然の、または混乱を招く更新変更は、許可されている場合でもチャネルを損なう可能性がある。したがって、レジストリアカウントは、価格設定を単なる収益レバーではなく関係機能として扱わなければならない。iRegistry が高価値の名前を販売している場合、その運用品質は、レジストラがサプライズなく顧客にコストを説明できるかどうかによって部分的に測られる。

これらいずれも iRegistry がスケールを持っていることを証明しない。公開データはその逆を示唆するかもしれない。.richは、幅広い消費者拡張ではなく、小規模でプレミアムまたは専門 TLD として現れる。しかし、スケールだけがレジストリアカウントが合理的でありうる唯一の方法ではない。固定費が抑えられ、バックエンドサービスが共有され、プレミアム更新が十分なマージンを運び、レジストラカバレッジが適切で、不正利用量が管理可能で、事業者が高価な紛争を回避すれば、小規模 TLD は機能しうる。また、近い将来の利益が控えめであっても、戦略的資産として機能しうる。なぜなら、委任された名前空間管理は希少であり、再作成に時間がかかるからである。問題は、公開証拠ではどのバージョンが当てはまるかを確認できないことだ。利益が始まる前に支払わなければならない義務を示すことしかできない。

投資家や取引相手にとって、デューデリジェンスの質問はしたがって具体的である。レジストラ別、更新コホート別、価格帯別のアクティブ登録ベースは何か。プレミアム価格で更新される名前はいくつあるか。ホールセール価格表は何であり、どのくらいの頻度で変更されるか。どのレジストラが受動的な掲載ではなく実際の登録を生成しているか。バックエンド料金と最低コミットメントは何か。毎月何件の不正利用報告が届き、そのうち何件がレジストリによる直接措置を必要とするか。最後の DNS、RDAP、EPP のインシデントは何だったか。直近のエスクロウ預託はどの程度クリーンだったか。プライバシー、レジストラ契約、苦情、ICANN 通知にどれだけの法務時間が費やされているか。それらの答えが、iRegistry が耐久性のある低ボリュームアカウントなのか、薄利のコンプライアンス負担なのかを決定するだろう。

公開証拠はまた、価値が改善されうる場所も示唆している。レジストリは、レジストラ文書を見つけやすくし、ポリシーページを最新に保ち、不正利用指標を明確にし、RDAP とプライバシー慣行をより顧客フレンドリーな方法で提示し、プレミアム名の論理を価格決定力を弱めることなく説明できる。これらの変更のいずれも、より大きなバックエンドを所有する必要はない。注意深いアカウント管理が必要である。小規模 TLD では、より良い文書化が人員数の代わりになりうる。なぜなら、繰り返される質問を減らすからだ。より迅速な不正利用トリアージはレジストラの信頼を守ることができる。より明確な価格通知はチャネル摩擦を減らすことができる。より強力な公開継続性メッセージングは、プレミアム名前空間を脆弱に感じさせないようにできる。

課金の信頼は、特に取り上げる価値がある。なぜなら、それはプレミアムレジストリアカウントの最も敏感な部分の一つだからだ。レジストラは、名前が作成できることだけでなく、作成時、更新時、移管時にその名前がいくらかかるか、その名前が標準かプレミアムか、料金変更がどのように伝達されるか、支払い失敗や更新失敗の状況がどのように処理されるか、サポートエスカレーションが登録者が自信を失う前に紛争を解決できるかどうかを知る必要がある。.richのような TLD では、小売価格がマスマーケット拡張よりもはるかに高くなりうるため、曖昧さは高くつく。レジストラのサポート担当者は、更新価格が予想外または不公平だと考える顧客に対して即興で答えることはできない。したがって、レジストリの商業製品には価格の衛生が含まれる。すなわち、安定した料金公開、明確なレジストラ通知、予測可能なプレミアム分類、課金に関する質問をバックオフィスのノイズではなく信頼イベントとして扱うサポート経路である。

その価格の衛生は ICANN の義務と結びついているが、それらによって尽きるものではない。契約上の通知ルールは特定の価格変更の事前通知を要求しうるが、優れたレジストリアカウントはさらに進まなければならない。価格表がレジストラのカート内でどのように見えるか、プレミアム名がどのようにフラグ付けされるか、更新リマインダーがどのように表現されるか、移管試行が現在のステータスをどのように反映するか、紛争がレジストラとレジストリ間でどのようにエスカレーションされるかを考えなければならない。この公開記事は、iRegistry の非公開料金ファイルやレジストラとのコミュニケーションが強力かどうかを語ることはできない。それは、アカウントの経済性がそれらに依存していると言える。低ボリュームのプレミアム TLD では、少数の失敗した、または紛争となった更新が、多数の通常の低コスト登録と同じだけのサポート時間を消費しうる。チャネル信頼が製品である場合、課金の明確さはサービス可用性の一部である。

バックエンドサービスの証拠も注意深い解釈を必要とする。IANA の.richエントリは、Identity Digital をスポンサリング組織とはしない。Identity Digital を技術および RDAP 役割において可視的にする一方、iRegistry はスポンサーであり続ける。この分割は商業的に重要である。スポンサーは、レジストリ事業者の関係と公開ポリシー姿勢を保持しながら、より大規模なプラットフォームの運営深度から利益を得ることができることを意味する。レジストラは、舞台裏で責務が分割されていても、バックエンドの技術的信頼性とスポンサーの契約上のアイデンティティを一つのサービスとして経験するかもしれない。何かがうまくいけば、レジストラは TLD を評価するかもしれない。何かが壊れれば、レジストラはその失敗がスポンサー、バックエンドプロバイダー、RDAP サービス、DNS 変更、レジストラ統合のどこにあるかを気にしないかもしれない。アカウントは、チャネルに届く前にその複雑さを吸収しなければならない。

この分割は、バックエンドプロバイダーが技術的作業の多くを担っている場合でも、切り替えコストが持続する理由も説明する。購入者は、ある確立されたバックエンドから別のものへの移動はほとんどベンダー変更であると想定するかもしれない。レジストリアカウントでは、その移動はレジストラ認定、サービス文書化、DNSSEC のタイミング、ステータスコード動作、ロック手順、RDAP レスポンス、エスクロウ生成、課金マッピング、不正利用ルーティングを再開する可能性がある。スポンサーはまた、外部向けのナラティブも処理しなければならない。すなわち、なぜ変更が行われているのか、レジストラが行動を起こす必要があるかどうか、登録者が何らかのリスクに直面するかどうか、プレミアム価格設定が影響を受けるかどうか、既存の保留やロックが有効であり続けるかどうかである。小規模 TLD にとって、コミュニケーションコストは技術的作業とほぼ同じくらい重要でありうる。技術的に問題のない移行でも説明が不十分であれば、チャネル損害を引き起こしうる。

規制エクスポージャーは ICANN に限らない。欧州のレジストリスポンサーは、グローバルなドメイン名ルールと欧州のデータ保護法の相互作用の中で生きなければならない。事業者は、欧州外からの不正利用報告、複数法域からのレジストラデータ、法執行機関の関心、権利保護苦情、再販業者発の顧客質問、登録データアクセス要求を受け取る可能性がある。各要求は、合法的根拠、開示、最小化、保持、役割割り当てに関する疑問を提起しうる。たとえバックエンドプロバイダーが運営ツールを提供していても、スポンサーはプライバシーをリモートサプライヤーの問題として扱うことはできない。スポンサーの名前は公開レジストリの文脈に現れ、レジストラコミュニティはサービスが首尾一貫した全体として振る舞うことを期待する。だからこそ、データ保護労働は製品価格に含まれる。

同じエクスポージャーが不正利用対応を形作る。不正利用作業には直接的な労働コストがあるが、オプション価値もある。十分に裏付けられた不正利用報告に確実に対応するレジストリは、セキュリティ研究者、消費者保護当局、権利者、レジストラ、ICANN コンプライアンスからのより広範な圧力の可能性を減らすことができる。不規則に反応するレジストリは、小さなインシデントをチャネル不信に変えうる。プレミアム名前空間にとって、風評の問題は特に深刻である。ステータスや排他性を中心に販売される TLD は、不正利用の逃げ場と見なされる余裕はないが、正当な高価値登録者が不安を感じるような恣意的な停止を行う余裕もない。事業者は、深刻な危害には十分迅速で、争いのあるケースには十分慎重な決定慣行を維持しなければならない。

公開証拠が薄く感じられる理由の一つは、最も経済的に意味のある作業が成功しているときは通常見えないことである。クリーンなエスクロウ預託、正確な月次報告、予想された料金と一致するレジストラ請求書、正しい公開フィールドを返す RDAP 回答、手順に従ったロック解除、適切なレジストラに照会された不正利用報告、失敗しない DNSSEC ロールオーバー、紛争を回避する更新通知に誰も気づかない。価値は危機の不在として現れる。これにより、小規模レジストリアカウントは外部から過小評価されやすくなる。それらは、実際の資産が ICANN、レジストラ、登録者を驚かせないという機能している習慣であるときに、少数のウェブページと古い TLD リストに見えるかもしれない。

サポート労働は、複数の小さな問題が同時に発生したときに最も価値がある。レジストラがなぜプレミアム更新が変わったのか尋ねているかもしれず、セキュリティ報告者が緊急の停止を求めているかもしれず、バックエンド通知が DNS メンテナンスウィンドウを必要とするかもしれず、プライバシー要求が注意深いデータアクセスレビューを要求するかもしれない。これらのイベントのいずれも存亡にかかわる必要はない。一緒になると、それらは、レジストリアカウントがチャネルを落ち着かせるのに十分な判断力とキャパシティを持っているかどうかをテストする。事業者は、どの問題が時間的に重要か、どれが委任できるか、どれが ICANN 通知を必要とするか、どれが法的レビューを必要とするか、どれがより明確なレジストラコミュニケーションで解決できるかを決定しなければならない。このトリアージはルートゾーンリストには見えないが、それは購入者がレジストリ運営をアウトソースすることで回避しようとしているまさにその労働である。アカウントの人員が薄かったり文書化が不十分だったりすると、通常の摩擦が風評損害になる。

逆もまた真である。公開された継続性は弱い経済性を隠しうる。TLD はほとんど成長を生み出さずに委任されたままでありうる。ポリシーページは存在しうるが、サポートキャパシティが薄い。バックエンドプロバイダーは DNS と RDAP を機能させ続けることができるが、スポンサーの商業的勢いは限られている。アクティブな需要が低いときでさえ、レジストラの掲載は持続しうる。これが、この記事の判断が iRegistry を高品質なビジネスと呼ぶのを控える理由である。公開記録は、アカウントの性質についての主張を支持するが、その収益性を支持しない。より強い主張を裏付けるためには、購入者は、更新コホート、プレミアム名の貢献、レジストラ集中度、バックエンド最低額、サービスレベル履歴、未解決の不正利用事例、プライバシー要求、コンプライアンスオーバーヘッド後の粗利益に関する非公開証拠を必要とするだろう。

近い将来の成長が控えめであっても、そのようなアカウントを維持する戦略的理由がある。委任された TLD 管理は希少で、規制されており、置き換えが遅い。良好な状態で TLD を維持するスポンサーは、将来の価格設定、パートナーシップ、ブランド再ポジショニング、プレミアム名販売、防御サービス、可能な移管価値に対するオプション性を保持する。このオプション性は、固定費が抑えられている場合、現在の登録ボリューム以上の価値がありうる。しかし、レジストラの信頼が弱まると、そのオプションは減価する。委任されているがサポートが不十分な名前空間は、売却が難しく、移行が難しく、復活が難しくなる。したがって、運営アカウントは現在のキャッシュフローと将来のオプション性の両方を守らなければならない。コンプライアンス労働はそのオプションの保有コストであり、チャネル信頼はそれを存続させる条件である。

そのため、適切な比較対象は一般的なドメインビジネスではなく、プレミアムな商業的ラッパーを持つ小規模な規制ユーティリティである。レジストリスポンサーは狭いリソースを管理し、共有インフラに依存し、規制された仲介者とやり取りし、不正利用とプライバシーの要求に応え、サービス障害を回避することで生き残る。その成長はより良いポジショニングから来るかもしれないが、そのダウンサイドは信頼性によって統治される。これが、この記事が管理上に見える義務にこれほど重きを置く理由である。通常のソフトウェアビジネスでは、報告、エスクロウ、ポリシー通知、監査準備は間接費かもしれない。TLD アカウントでは、それらは販売を続けるためのライセンスの一部である。それらを無視する購入者は、ブランドに過剰に支払い、作業に過小予算を割り当てるだろう。

しかし、アカウント管理が解決できることには上限がある。市場が提供された価格で.richの名前を望まなければ、運営の卓越性は大量の需要を生み出さない。レジストラの経済性が魅力的でなければ、チャネルパートナーは積極的に TLD を推進しない。バックエンド料金が更新収入よりも速く上昇すれば、スポンサーのマージンは圧縮される。データ保護や不正利用義務がより要求が厳しくなれば、固定労働が増加する。より大規模なプロバイダーが同じチャネル信頼をより低コストで提供できるなら、小規模スポンサーは、焦点、法的継続性、ブランド管理、商業的柔軟性を通じて自らの存在を正当化しなければならない。購入者の決断は、iRegistry が義務を負っているかどうかではない。明らかに負っている。決断は、それらの義務を負う方法が代替案よりも安価で信頼できるかどうかである。

iRegistry の最も強力なケースは、委任の下での専門化である。同社は公開証拠において、幅広い消費者レジストラ、大規模なバックエンドプラットフォーム、国家レジストリとして提示されてはいない。それは、ベルリンの法的拠点と背後により大規模な技術プロバイダーを持つ特定の TLD のスポンサーとして現れる。これにより、それは希少な権限のコーディネーターとなる。その商業的仕事は、TLD の法的、技術的、チャネル層を整合させることである。すなわち、ICANN 契約、IANA リスト、バックエンド運用、レジストラアクセス、データポリシー、不正利用対応、プレミアムポジショニングである。この調整が機能すれば、顧客は全機構を構築することなく機能する名前空間を受け取る。失敗すれば、顧客は全層にわたって一度に露出する。

最終的な判断は、iRegistry の製品は、委任された名前空間管理を中心にパッケージ化されたコンプライアンス労働とチャネル信頼である。公開記録は、運営アカウントとその主要な義務を特定するのに十分強力だが、収益やマージンの主張を裏付けるには薄すぎる。最も重要な証拠は、登録名数の見出し数ではない。それは、.richスポンサーシップ、Identity Digital の技術的依存、ICANN 契約義務、公開不正利用およびポリシーコミットメント、RSEP 活動、レジストラチャネル提示の継続的な組み合わせである。この組み合わせは、なぜ小規模な TLD アカウントでさえ運営にコストがかかり、置き換えが難しいかを説明する。また、購入者が技術的能力と並んで運営の忍耐を評価すべき理由も説明する。

選択肢を比較する購入者は、冒頭の代替集合に立ち返るべきである。内製レジストリスタックは制御を提供するが、固定費の過剰構築を招くリスクがある。大規模バックエンドレジストリプロバイダーはスケールを提供するが、購入者を他者のプラットフォーム上の小口アカウントに縮小する可能性がある。ccTLD パートナーは運営の信頼性を提供するが、ニッチな商業 TLD に適合しないかもしれない。レジストラ限定流通は負担を軽減するが、レジストリの権限を放棄する。名前空間の放棄はコンプライアンスの請求を終わらせるが、委任のオプション価値を破壊する。iRegistry は、これらの選択肢の間の狭い空間に位置する場合にのみ存続可能である。すなわち、名前空間に関心を持つほど焦点を絞り、ICANN とレジストラを満足させるほど専門的であり、コンプライアンス労働とチャネル信頼が購入者の次善の代替案よりも低コストであるほど経済的である場合である。