要約

  • IANAの.cc委任記録は、eNIC Cocos (Keeling) Islands Pty. Ltd. d/b/a Island Internet Servicesを現在の管理組織として記載する。同じ記録はeNICの管理連絡先とVerisign Global Registry Servicesの技術連絡先を分けている。これは説明責任を持つ役割の証拠であって、全作業が一社の単一制御系で行われる証拠ではない。
  • IANAは現在、IPv4とIPv6の双方を持つ四つの権威ネームサーバー、DNSSECのDS情報、WHOISサーバー、Verisignが提供するRDAPベースURLを掲示する。これらはある時点の権威状態と構成を示すが、常時可用性、全観測地点での正答、鍵更新の成功、全登録データの正確性を保証しない。
  • 2008年のICANNとeNICの書簡交換は、eNICをVerisignの完全子会社と説明し、権威ネームサービス、ルート連絡先、ゾーン更新、WHOIS、技術標準に関する責任を記す。同文書は法的効果も限定しており、包括的保証、所有権、運用品質の認証として扱うことはできない。
  • Verisignのレジストラ向け資料は、契約、財務、技術準備、Shared Registration Systemへの接続条件を説明する。これは運営者による能力と手続の記述であり、可用率、取引成功率、不正利用対応、復旧の独立測定ではない。
  • IANAのRDAPブートストラップはccをVerisignの.cc用サービスへ対応付け、現在の一回の照会ではnic.ccの構造化RDAPオブジェクトが返った。この結果が示すのは観測時点の探索経路と応答であり、長期サービス水準や全オブジェクトの品質ではない。
  • 継続的な費用の中心は、権限と連絡先の監督、レジストリとレジストラ状態の統合、DNSとDNSSECの保守、WHOISとRDAPの照合、曖昧な取引の処理、緊急権限の維持、事業者変更時に名前、データ、鍵、証拠を失わないための検証である。
  • 調査資料はeNIC独自の人工知能モデル、独立した製品信頼性スコア、帰属可能な顧客本番成果を示していない。モデル能力、製品信頼性、顧客成果は別々の証拠階層であり、一つを他の代替にしてはならない。

グローバル名前空間の端にある具体的な会社

最初の統制は会社の境界を正確に保つことである。BTWのディレクトリ項目は、eNIC Cocos (Keeling) Islands Pty. Ltd. d/b/a Island Internet Servicesという完全名称を使う。IANAルートゾーン記録も同じ名称を.ccの管理組織として掲示する。IANA WHOISオブジェクトは、組織としてeNIC、管理連絡先としてeNIC側担当、技術連絡先としてVeriSign Global Registry Servicesを示し、ネームサーバー、DS、登録サービスの情報も列挙する。ディレクトリと権威台帳の一致は、対象企業を似たブランドや関連会社と取り違えないための強い同一性根拠になる。

ただし、関連する全組織をeNICとみなすことはできない。Public Technical IdentifiersはIANA命名機能を担い、ICANNは関係とガバナンスの資料を公開する。Verisignは資料によって親会社、レジストリサービス運営者、技術連絡先、ルートゾーン保守者という異なる立場で現れる。レジストラはレジストリシステムに接続し、登録者は通常レジストラを通じて手続する。さらに再販事業者、DNSホスティング、ネットワーク運営者、認証局、アプリケーション運営者が下流に存在し得る。

一つの公開ドメイン名が多くの組織に依存しても、責任は層ごとに異なる。ネームサーバー応答が失われた場合、原因は権威DNS、経路、ファイアウォール、観測地点のいずれにもあり得る。登録者が変更できない場合は、レジストラ認証、レジストリ状態、契約、残高、ポリシーが候補になる。ウェブサイト停止はDNSが正しくてもホスティングやアプリケーションで起きる。境界がなければ、調査は目に見える管理組織へ原因を早計に帰属させる。

2008年の書簡は役割の内容を具体化する。eNICは権威プライマリおよびセカンダリネームサーバーを安定かつ安全に運用し、連絡先変更をIANAへ知らせ、定期的なゾーン更新を生成し、WHOISを提供し、関連技術標準へ貢献する責任を持つと記される。これらは能力と説明責任の明示であるが、非公開の構成、要員、委託契約、ソフトウェア、鍵管理、障害履歴を明らかにしない。本稿は不明な内部構造を推測しない。

書簡は制度上の限界も示す。協力関係は名前空間の私有、全サービス結果の保証、関係法人の法的責任の統合を意味しない。資料から得られる妥当な結論は、当事者、責任、接続点、更新すべき情報が明示されているという範囲にとどまる。技術作業を委託していても、管理組織は状態を理解し、変更を認可し、通常経路が失われた場合に復旧を導く能力を保持する必要がある。

eNICのccNSO加入申請も同社を.cc管理組織として示す一方、ccNSO会員資格はICANNとの個別関係やIANAサービスの受領から独立すると説明する。したがって会員資格は主権、所有、運用品質を証明しない。制度参加は調整の場を提供するが、稼働システムの観測に代わらない。

公開連絡先は運用上の身元管理でもある。メールアドレスや電話番号は、認可されたチームに到達し、代理担当が存在し、本人確認を回復でき、緊急手順が機能するときに初めて有効になる。公開台帳は内部統制を証明しないが、配送、認可確認、応答時間、代替経路を試験する基点を与える。

ルートゾーン台帳は権限を記録し、性能を保証しない

IANAのルートゾーン管理説明は、管理組織と技術委任情報を権威ある参照記録として維持する機能を示す。.ccにはac1.nstld.comからac4.nstld.comまでの四名称があり、それぞれIPv4とIPv6アドレスを持つ。WHOIS、RDAP、DNSSEC DSも記録され、世界の再帰リゾルバーが同じ委任起点を使えるようにする。

これらの項目が答えるのは権限の問いである。誰が管理組織として認識されるか、ルートはどのサーバーへ委任するか、どのDSがDNSSEC信頼連鎖を子ゾーンへつなぐか、登録データをどこで探すかを示す。一方、年間稼働率、全地域の応答、IPv4とIPv6の実効同等性、全鍵更新の無事故を示すものではない。

堅牢な運用では、承認された状態と観測された状態を照合する。ルートのNS集合を子ゾーンのNS、glue、内部資産台帳、複数ネットワークからの測定と比べる。DSを稼働DNSKEY、署名、独立検証リゾルバーと比べる。連絡先、URL、証明書を実際の責任者と比べる。差異は担当者、原証拠、暫定措置、修正、独立確認、期限を持つ例外として扱う。

これは「レジストリは記録者であり、主権者ではない」という考え方に合う。台帳は一意性と共通の権威参照を提供するが、全パケットを監視し、全契約を執行し、全アプリケーションを保証するわけではない。現実の層は、記録された権限を稼働サービスと継続して突き合わせる作業にある。

管理連絡先と技術連絡先の分離は統合費用を可視化する。平常時には一体のサービスに見えても、例外時には診断、認可、実行、レジストラ通知、最終検証が別組織に分かれる可能性がある。契約で義務を分配できても、データ、鍵、担当者を用いた演習なしに連携の実効性は証明できない。

ルート変更にも完全なライフサイクルが必要である。申請者の権限を検証し、提出情報を技術検査し、承認済み変更を実装し、子ゾーンと監視で結果を確認する。担当者退職、証明書期限、認証端末紛失、供給関係変更は単純な更新を止め得る。継続性計画は代替身元と認可経路を事前に試さなければならない。

権威DNSとDNSSECは稼働中の制御面

IANAの権威ネームサーバー要件は基本統制を示す。サーバーは到達可能で対象ゾーンに権威を持ち、BGPで観測される起点自律システムを基準に少なくとも二つのトポロジ的に異なるネットワークへ分散し、glueと権威アドレスを一致させ、親委任と子NSを一致させ、複数サーバーで整合したデータを返し、公開再帰を提供してはならない。

これは技術的な基準であって永久保証ではない。経路、拠点、ファイアウォール、OS、DNS実装、機器、供給契約は変化する。四名称が四つの独立故障領域を意味するとは限らない。anycast一名称が多数拠点を使う場合も、複数名称が同じ制御系に依存する場合もある。地理、ネットワーク、ソフトウェア、アカウント、人員の独立性は具体的観測で判断する必要がある。

整合性はプロトコルとサーバーごとに測る。IPv4が正常でもIPv6が失敗し得る。一拠点だけ古いserialを返し得る。親のglueと子の権威アドレスがずれる場合もある。健康な拠点に近い再帰リゾルバーが地域障害を隠すこともある。監視は正確なNSへ直接問い合わせ、SOA、NS、glue、肯定・否定応答を複数地点で確認し、時刻、質問、完全応答、観測位置を残すべきである。

DNSSECが提供するのは検証可能な真正性の連鎖である。.ccのDSにより、検証リゾルバーは署名済みルートから子ゾーンのDNSKEYへ信頼を接続できる。DNS問い合わせを暗号化せず、容量攻撃を防がず、登録者のウェブ、メール、アプリケーションを自動保護しない。鍵、署名、時刻、各層のデータが正しい範囲でDNSデータの真正性を証明する。

鍵ロールオーバーは複数システムと時間窓をまたぐ。鍵生成と保管、DNSKEY公開、親DS更新、TTLとキャッシュ収束、署名有効期間、外部観測、後戻り計画が必要である。旧鍵を早く除去すれば検証が壊れ、緊急対応のため権限を無制限に広げれば別の危険になる。保守には職務分離、保護されたバックアップ、正確な時計、変更記録、実際に試した復旧経路が含まれる。

故障モードはeNICで実際に起きた事例のように書いてはならない。親子NS不一致、古いglue、片方のIP系統のみの不達、署名期限切れ、古いDS、ゾーン配布遅延、誤った応答、測定地点不良は、検証すべき一般シナリオである。対応は証拠を保存し、影響を限定し、最小権限で修正し、独立地点から確認する。

共有基盤は規模と経験をもたらす一方、アカウント、知識、変更経路、供給者依存を集中させ得る。Verisignとの関係だけで危険または安全と断定できない。問うべきは、eNICが重要状態を観測し、誤りを異議申立てし、必要な行為を認可し、通常供給経路を失ったときに実行可能な選択肢を持つかである。

レジストラ接続が一つのレジストリを共同システムにする

Verisignのレジストラになるための資料は、申請情報、財務条件、技術準備を説明する。Shared Registration Systemは、複数レジストラがVerisign運営TLDでサービスを提供できるようにするハードウェアとソフトウェアの集合とされる。.ccについては、汎用TLD用のICANNレジストラ認定が必須ではない一方、所定の接続と契約条件は残る。

共有システムは一意なオブジェクトと共通取引規則を提供するが、接点を増やす。作成、更新、移管、変更、削除、復元は認証、検証、一回限りの適用、記録、請求を経て、必要に応じて登録データとDNSへ反映される。通信確認だけでは後続処理の完了を証明できず、エラー表示だけではネットワーク、認証、残高、ポリシー、オブジェクト状態のどこが原因か分からない。

タイムアウトは典型例である。切断前に命令が受理されたかレジストラが判断できない場合、盲目的再試行は変更済み状態と衝突する。堅牢な処理は永続的な要求識別子を使い、権威オブジェクトを再読し、結果コードを分類し、双方の記録を照合する。サポート説明は取引証拠の代わりにならず、取引成功もDNSやデータサービスへの最終反映を証明しない。

証明書、パスワード、許可IP一覧、担当者、クライアント版は老朽化する。初回接続試験を通ったことは保守を不要にしない。プロトコル、ポリシー、安全要件が変われば、レジストリ実装、レジストラソフトウェア、文書、支援、監視を同期させる必要がある。移行中の差異には範囲と終了日が要る。

信頼性は取引全体で測る。受理と拒否、その理由、処理待ち時間、最終オブジェクト状態、DNS公開遅延、WHOIS/RDAP整合、財務照合、エスカレーション解決を分けて記録する。一つの成功率では、受理されたが保存されない取引や、データベース更新後に権威DNSへ反映されない状態を隠し得る。

顧客成果はさらに下流にある。登録が成功しても、ホスティングDNSの誤設定、証明書、経路、ウェブ、メール、アプリケーションで失敗し得る。帰属には共通時刻、オブジェクトID、各境界の証拠が必要である。公開資料に帰属可能な顧客事例はなく、本稿は顧客、基準値、成果を創作しない。

WHOISとRDAPは権威の発見経路

WHOISは伝統的にテキスト形式の登録情報を提供し、RDAPはHTTPと構造化JSONを用いる。IANAはRDAP DNSブートストラップ登録表と機械可読JSONを公開する。現在のデータはccをVerisignのサービスへ対応付ける。RFC 9224は、クライアントが対象範囲の権威RDAPサービスを発見する方法を説明する。

発見と提供は別の層である。IANAは照会先を示し、指定サービスが応答する。ブートストラップが古ければクライアントは誤った場所へ向かう。サービス停止なら正しい発見でもデータを得られない。オブジェクトが不完全ならHTTP 200は応答だけを証明し、内容の完全性や新鮮さを証明しない。

IANAのRDAP要件は、公開前の基本動作と最低限の適合性試験を含む。この範囲を越えて解釈してはならない。参加時の試験は長期可用性監査でも全オブジェクト検査でもない。現在のnic.cc RDAPオブジェクトが構造化応答を返したことは、一時点の有用な観察である。

WHOISとRDAPは、複製遅延、プライバシー編集、スキーマ対応、キャッシュ、日付や状態の解釈によって違い得る。成熟した監督は、標本オブジェクト、更新時刻、状態、ネームサーバー、イベントを比較し、TLS、レート制限、エラー、アクセス方針、サービス移行も確認する。差異の修正には、まずどのデータ源が権威かを決める必要がある。

エンドポイント保守には、ドメイン所有、証明書、HTTP挙動、JSON構造、元データ、濫用防止、利用者周知が含まれる。ベースURL変更はIANA登録、クライアント実装、移行期間と調整する。リダイレクトだけでは、全クライアントが正しくパスを構築し新フィールドを扱うことを保証できない。

登録データは説明責任とプライバシーを結ぶ。連絡先と状態は理解に役立つが、公開範囲は適用ポリシーに従う必要がある。レート制限はサービスを保護し、正当な大規模確認には例外を生み得る。用途を分類し、要求証拠を残し、比例的な接続や異議申立て経路を用意することが必要である。

利用価値も「端点がオンライン」だけでは測れない。研究者、レジストラ、ネットワーク運営者、権利保護担当者は異なる項目と新鮮さを必要とする。信頼性指標は用途に合わせ、更新時間、エラー種別、変更通知、訂正経路を測るべきである。

ガバナンス記録は接点を定義し、主権を作らない

ICANNのccTLD関係資料一覧には複数種類の文書があるが、法的・技術的な範囲は同一ではない。eNICの書簡は協力、連絡先、責任の一部を示し、ccNSO申請は会員資格を示し、IANA記録は現在の委任を示す。合わせれば責任地図を作れるが、どれか一つを全運用結果の保証にできない。

IANAのccTLD委任・移管案内は、管理組織、地域関係者、関係政府、IANA/PTI、ルートゾーン保守者の手続を説明する。運用技術能力、公共利益の支持、連絡先、技術検査、安定した移行が評価対象になる。名前空間の継続性は多者間の接点であり、単一組織の所有宣言ではない。

ccTLD取消枠組みは、重大で継続的な問題に対する是正と継続性の文脈を提供する。本稿にはeNICがその手続にあるという証拠はなく、そう示唆もしない。引用の目的は、ガバナンスに段階的対応、是正、最終継続経路が必要だと理解することにある。

地理的所有やコミュニティ所有という言葉だけでは運用証拠にならない。地域利益、政策参加、公益は重要でも、NS整合、DS正確性、取引照合、データ新鮮さ、復旧権限は稼働コードと記録で確認する。許可の物語は誤委任や失効鍵を修正しない。

ガバナンス品質は接点で評価できる。誰が変更を要求・承認し、誰が実施し、危険な操作を誰が止め、結果を誰が検証し、紛争証拠をどこに保存し、通常関係が失われたときどう移行するか。回答は現在の担当者だけに依存せず、人員、供給者、技術の変化に耐える必要がある。

隠れた運用費用は整合性の維持にある

第一は監督である。管理・技術連絡先、NS、アドレス、鍵、DS、WHOIS、RDAP、証明書、レジストラアカウント、ポリシー版、復旧材料、供給依存を把握する。各項目に所有者、権威情報源、確認周期、例外経路が必要である。公開台帳だけでは内部資産と権限の全体を示さない。

第二は統合である。ルートと権威DNS、DNSSECと稼働鍵、取引とデータベース・ゾーン・WHOIS・RDAP・請求、公開連絡先と実認可、ポリシーと契約・ソフトウェア・支援・報告を一致させる。接点が増えるほど、局所成功と全体失敗が同時に起こりやすい。

第三は保守である。ソフトウェア、OS、証明書、鍵、プロトコル、データ形式、レジストラ実装、担当者、組織関係が変化する。バックアップ作成は復元可能性を証明せず、文書作成は当番が実行できることを証明しない。保守には復元演習と独立確認を含める。

第四は例外処理である。古い連絡先、親子差異、DS誤り、取引タイムアウト、WHOIS/RDAP差異、不十分な不正利用報告、主要供給経路停止は異なる権限と証拠を必要とする。例外記録には対象、影響、証拠、担当、暫定措置、検証者、期限を持たせ、暫定回避を恒久化させない。

供給者集中は自動的な失敗でも無料の信頼性でもない。共有基盤は規模、経験、統一運用を与える一方、知識、アカウント、展開、復旧依存を集中させる。eNICが状態を理解し、誤りを争い、緊急操作を認め、必要なら移行できる観測性と権限を持つことが重要である。

移植性は運用能力である。ゾーン、登録オブジェクト、取引記録、ポリシー版、監査証拠を理解可能な形式で出力でき、鍵、資格情報、連絡先、緊急権限に移行計画があり、レジストラ接続とルート変更認可を継続できる必要がある。演習は形式、身元、時間の隠れた依存を発見する。

公開資料はeNICの予算、人員、障害件数、復旧時間を数値化しないため、本稿も数値を作らない。しかし費用が存在する理由は示せる。組織境界は監督を要求し、共有状態は照合を要求し、資格情報は老朽化し、例外は認可と検証を要求する。

障害になる前に故障モードを記録する

身元の故障には、連絡先失効、アカウント復旧不能、承認権限不明、供給者変更後の記録不一致がある。修復は一項目の書換えではなく、行為者の権限を再証明し、権威記録と依存システムを更新し、代替連絡経路を試す作業である。

委任の故障には、親子NS差異、古いglue、異なるSOAや誤ゾーンを返す一部サーバーがある。根、子、複数ネットワークから正確な応答を集め、伝播、キャッシュ、経路、実構成を区別する。変更作業の完了ではなく、稼働照会の再確認で閉じる。

DNSSECの故障には、DS/DNSKEY不一致、署名期限、時刻ずれ、アルゴリズム不整合、輪番順序誤りがある。旧鍵保持、新材料公開、キャッシュ待機、検証地点確認が必要になり得る。緊急に検証連鎖を外す操作は影響と終了条件を持たなければならない。

取引の故障には、認証失敗、重複要求、タイムアウト後の不明状態、財務保留、オブジェクトロック、レジストラ・レジストリ表示差異がある。要求ID、時刻、前後状態、双方記録を使い、利用者の画面だけで原因を決めない。

データサービスの故障には、古いブートストラップ、TLS問題、WHOIS/RDAP差異、複製遅延、誤ったレート制限、フィールド変更がある。発見、接続、プロトコル、構造、データ新鮮さ、アクセス方針を分けて検査する。

継続性の故障には、主要連絡先不達、鍵やバックアップが一供給者にしかない、データ形式を移行できない、復旧環境未試験、組織変更による法的認可断絶がある。日常可用時には見えにくいため、実障害前の演習が必要である。

測定も故障する。一観測地点のDNS、TLS、ネットワーク問題は偽警報を作り、キャッシュは本当の問題を隠す。問い合わせと応答を保存し、独立ネットワークで再確認する。そうしなければ顧客側問題をレジストリへ誤帰属し、地域障害を端末問題と誤解する。

能力、信頼性、顧客成果は別の証拠である

能力証拠は「何をする権限または機能があるか」を答える。IANA委任、NS、DS、WHOIS、RDAP、責任書簡、レジストラ接続資料は、.cc制御面とeNICの管理役割を確認する。これらだけでは長期挙動を答えない。

信頼性証拠は「定義した条件と期間でどう動いたか」を答える。反復測定、分母、観測地点、保守時間、障害記録、復旧演習、独立確認が必要である。資料には.ccのDNS可用率、取引成功率、データ新鮮さ、復旧時間の完全な独立系列がないため、本稿は信頼性点数を作らない。

顧客成果は「識別可能な導入が基準と比べて何を生んだか」を答える。レジストリが正常でも顧客サイトはホスティングで停止し得る。登録成功は事業成果を自動生成しない。基準、時系列、帰属可能な介入なしに成果をeNICへ帰属できない。

人工知能も別に証明する。公開資料はeNIC独自モデル、学習データ、評価、顧客AI導入を示さない。自動異常検知が存在するとしても、証拠なしにAIと呼べない。評価には誤検知、見逃し、人間監督、変更、異議申立て、障害時の代替が必要である。

三層を分けると意思決定が改善する。能力は技術評価への参加条件、信頼性は冗長性とリスク予算、顧客成果は事業価値に使える。能力説明を信頼性に、一回の応答を長期SLAに、名前空間の存在を顧客成功に置き換えてはならない。

証拠に基づく説明責任の評価表

身元と権限では、ディレクトリ会社名、IANA管理組織、管理・技術連絡先、供給者役割、承認権限を照合する。合格は名称の類似ではなく、重要操作が現在の認可主体まで追跡できることである。

委任とDNSでは、ルートNS、glue、子ゾーン、SOA、複数地点応答を比較し、IPv4とIPv6を分ける。承認データと観測データが一致し、差異に期限付き対応があれば合格となる。

DNSSECでは、DS、DNSKEY、署名、アルゴリズム、時刻、輪番手順を検査する。通常検証、異常警報、統制された後戻り、独立確認が必要で、DS一件の存在だけでは足りない。

レジストラ取引では、永続ID、結果コード、データベース、DNS、WHOIS/RDAP、請求を照合し、タイムアウト後の冪等性を試す。接続成功ではなく最終状態を証明する。

登録データでは、IANA引導、WHOIS、RDAP、TLS、構造、更新時刻、アクセス方針を調べる。正しいサービスを発見でき、主要オブジェクトが整合し、例外を訂正できることが条件になる。

運用継続では、代替連絡、資格情報復旧、鍵アクセス、バックアップ復元、縮退運転、供給者移行を試す。文書の存在ではなく、証拠を使い認可操作を期限内に完了できることを確認する。

例外統治では、影響、証拠、担当、暫定措置、検証者、期限を各記録に持たせる。回避措置が撤去され、根本修正を独立確認して初めて閉じる。

証拠品質では、権威台帳、第一者能力説明、一時点観察、長期測定、顧客成果を区別する。弱い証拠を強い結論へ昇格させず、欠測を想像値で埋めない。

本稿は合成点数を付けない。資料が精密な重みや評価値を支えないからである。信頼性結論には、複数ネットワークの長期DNS/DNSSEC観測、取引標本、WHOIS/RDAP新鮮さ、連絡演習、復旧試験、変更履歴が追加で必要になる。

結論

eNIC Cocos (Keeling) Islandsはインターネット基盤で実在し、公に確認できる役割を持つ。IANAは同社を.cc管理組織として記録し、委任、DNSSEC、WHOIS、RDAPを公開する。資料はVerisign、ICANN/PTI、ルートゾーン保守者、レジストラ、登録者の異なる責任も示す。

長期的な工学課題は整合性である。台帳上の管理権限を有効に保ち、ルート情報を権威DNSと一致させ、DSを稼働鍵と一致させ、取引を登録状態と公開に一致させ、WHOISとRDAPの探索性と合理的整合を保ち、連絡先、資格情報、証拠、復旧経路を組織・供給者変更に耐えさせる必要がある。

公開能力証拠は製品信頼性ではなく、製品信頼性は顧客成果ではない。資料はeNIC制御面と運用費用を分析するには十分だが、構成、基準値、障害、可用率、人員、AI、顧客、復旧成果を創作する根拠にはならない。

レジストリ台帳の価値は、一意で追跡可能な権限を作ることにある。台帳自体がネットワークを動かすという意味ではない。記録、稼働コード、安全メタデータ、組織関係、例外判断、継続性証拠が揃って初めて、通常経路が失敗しても名前空間を利用可能かつ説明可能に保てる。

情報源

  1. BTWディレクトリ：eNIC Cocos (Keeling) Islands Pty. Ltd. d/b/a Island Internet Services ストラテジックサークル限定
  2. IANAの.cc委任記録
  3. IANAの.cc WHOISオブジェクト
  4. ICANNとeNICの2008年書簡
  5. ICANN ccTLD関係資料一覧
  6. eNICのccNSO加入申請
  7. Verisignのレジストラ資料
  8. IANA RDAP DNSブートストラップ登録表
  9. IANA機械可読RDAP DNSデータ
  10. IANA RDAPサーバー要件
  11. RFC 9224：権威RDAPサービスの発見
  12. IANA権威ネームサーバー技術要件
  13. IANA ccTLD委任・移管案内
  14. IANAルートゾーン管理概要
  15. IANA ccTLD取消枠組み
  16. 現在のnic.cc RDAPオブジェクト
  17. Wikimedia Commons：Some of DataOne's server racks
  18. Verisign .cc RDAP基底エンドポイント