Applicant Information

Does or will this RSP have a publicly verifiable, third-party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Does or will this RSP implement BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance's Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Describe the processes and procedures to be used to practice and ensure a successful KSK rollover for both emergency and non-emergency situations, including coordination with the DNSSEC RSP and IANA.

The Key Signing Key (KSK) rollover process is a critical operation for maintaining the integrity and security of DNSSEC-signed zones. This RSP implements a structured approach to both scheduled and emergency KSK rollovers, ensuring operational readiness, minimal service disruption, and full compliance with ICANN requirements. Coordination with the DNSSEC RSP and IANA is a fundamental component of the procedure. 1. Planning and Preparation ● A detailed KSK rollover policy is maintained, defining rollover frequency, cryptographic requirements, and assigned responsibilities. ● All rollovers are pre-tested in a staging environment simulating the production setup to validate procedures. ● All participating personnel are trained and rehearsed on the rollover process. ● Contact lists for DNSSEC RSP and IANA are actively maintained for immediate coordination when required. 2. Routine (Non-Emergency) Rollover Procedure ● New KSK Generation: A new KSK pair is securely generated using an HSM. The public key is documented and the private key securely stored. ● Pre-Publication: The new KSK is published alongside the current KSK in the DNSKEY RRset. ● DS Record Update: Coordination with the parent zone and IANA is conducted to submit the new Delegation Signer (DS) record derived from the new KSK. ● Propagation Period: A defined waiting period allows global resolvers to update their trust anchors. ● Activation: The new KSK begins signing the DNSKEY RRset. ● Deactivation and Removal: The old KSK is retired from signing operations, then removed from the zone only after validation is confirmed across the ecosystem. ● Monitoring: Continuous DNSSEC validation and logging confirm operational integrity. 3. Emergency Rollover Procedure ● Trigger Conditions: Emergency procedures are invoked upon KSK compromise, HSM failure, or cryptographic algorithm vulnerabilities. ● Immediate Action: A new KSK is generated offline, signed, and the new DS record is rapidly submitted to the parent zone via secure coordination with IANA. ● Notification and Escalation: All relevant parties, including DNSSEC RSP, IANA, and security teams, are immediately notified. ● Validation: After update propagation, validation monitoring confirms the new trust chain is operational. ● Post-Incident Review: Lessons learned are incorporated into the updated policies and documentation. 4. Coordination and Communication ● Coordination with the DNSSEC RSP ensures timely synchronization of cryptographic material and awareness of changes. ● IANA procedures are strictly followed for DS record submissions, timeline adherence, and accuracy checks. ● Secure channels (e.g., GPG, encrypted mail) are used for key material exchange. 5. Documentation and Compliance ● The DNSSEC Policy and Practice Statement (DPS) is maintained and includes lifecycle management of KSK/ZSK, access control, audit trails, and destruction protocols. ● All rollovers are logged, and periodic audits ensure adherence to policy and ICANN specifications, including RFCs 4033, 4034, 4035, 6781, and 7583.

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies?

Yes

Does or will this RSP have on-site backups of registration data?

Yes

Does or will this RSP have off-site backups of registration data?

Yes

Does or will this RSP practice data retention policies with regard to backups of registration data?

Yes

Does or will this RSP practice documented standards regarding media and data backups for registration data?

Yes

Does or will this RSP practice regularly scheduled validation of registration data backups, separately from recovery practices?

Yes

Does or will this RSP practice regularly scheduled recovery of registration data backups?

Yes

Does or will this RSP forbid the use of production data in testing and/or development environments?

Yes

Does or will this RSP encrypt registration data at-rest in the data store?

Yes

Does or will this RSP encrypt registration data in-transit to and from the data store?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP use modern and known-secure cryptographic algorithms for the encryption of registration data at-rest and in-transit with regard to the data store?

Yes

Does or will this RSP implement RFC 5730 (“Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP implement RFC 5731 (“Extensible Provisioning Protocol (EPP) Domain Name Mapping”)?

Yes

Does or will this RSP implement RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)?

Yes

Does or will this RSP implement RFC 5910 (“Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 5732 (“Extensible Provisioning Protocol (EPP) Host Mapping”)?

Yes

If applicable, does or will this RSP implement RFC 5733 (“Extensible Provisioning Protocol (EPP) Contact Mapping”)?

Yes

Does or will this RSP implement RFC 8334 (“Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 8748 (“Registry Fee Extension for the Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP forbid access to contacts via EPP to registrars other than the sponsoring registrar?

Yes

Provide a list of all EPP extensions to be used that are registered in the IANA EPP extensions registry, and an attestation that all EPP extensions to be used are registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”).

The Registry Services Provider (RSP) operates a fully RFC-compliant Extensible Provisioning Protocol (EPP) 1.0 server in accordance with RFC 5730 through RFC 5734. The EPP server enables only IETF standards-track EPP extensions that are formally registered in the IANA “Extension Registry for the Extensible Provisioning Protocol”, as required by RFC 7451. No proprietary, experimental, draft, legacy, or unregistered EPP extensions are enabled or used in production. The authoritative registry of EPP extensions is maintained by IANA and is available at: https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml Supported EPP Extensions ● DNSSEC Extension (Version 1.1) The registry supports the EPP DNSSEC extension as defined in RFC 5910 (secDNS-1.1). This extension is used for DNSSEC data handling in Domain Info, Create, and Update commands. ● Redemption Grace Period (RGP) Extension (Version 1.0) The registry implements the EPP RGP extension in full compliance with RFC 3915, including the Restore command and Restore Report functionality. ● Launch Phase Mapping Extension (Version 1.0) The registry implements the EPP Launch Phase Mapping extension in accordance with RFC 8334, supporting Sunrise and Landrush phases. Compliance Attestation The Registry Services Provider hereby attests that: ● All EPP extensions enabled in production are officially registered in the IANA EPP Extensions Registry, in compliance with RFC 7451. ● Only the EPP extensions explicitly listed above are enabled in production environments. ● No proprietary, draft, experimental, legacy, or unregistered EPP extensions are deployed or supported. This EPP implementation satisfies the applicable requirements of the RSP Program and Registry System Testing (RST) criteria with respect to EPP protocol and extension usage.

Does or will this RSP forgo the use of any EPP extensions which are not registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”)?

Yes

Does or will this RSP implement and operate EPP according to the performance requirements defined in the standards established in Specification 10 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP have controls to prevent EPP misuse and ensure all registrars have fair and equal access to EPP per the standards established in Specification 9 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) notwithstanding RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)? Note: while RFC 9325 covers TLS and DTLS, EPP only uses TLS.

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure EPP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure EPP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to EPP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the EPP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to EPP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP implement RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 7481 (“Security Services for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all currently operated gTLDs?

Yes

Does this RSP plan to continue to implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement RFC 9082 (“Registration Data Access Protocol (RDAP) Query Format”)?

Yes

Does or will this RSP implement RFC 9083 (“JSON Responses for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all currently operated gTLDs?

Yes

Will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Technical Implementation Guide?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Response Profile?

Yes

Provide a list of all RDAP extensions to be used.

Mandatory ICANN RDAP Extensions Our service implements the following mandatory extensions: • Extension Identifier: icann_rdap_technical_implementation_guide_1 ◦ Description: This extension signifies compliance with the February 2024 RDAP Technical Implementation Guide, covering technical requirements for query and response handling. • Extension Identifier: icann_rdap_response_profile_1 ◦ Description: This extension signifies compliance with the February 2024 RDAP Response Profile, ensuring standardized formatting of RDAP output for gTLD registries. • Extension Identifier: redacted ◦ Description: This extension is utilized to identify data elements that have been removed or hidden in accordance with the Registration Data Policy and global privacy regulations (e.g., GDPR).

Does or will this RSP forgo the use of any RDAP extensions which are not registered with the IANA as per RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP meet the standards established in the Service Level Agreements specified in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP?

Yes

Does or will this RSP implement methods to prevent mining of registration data via RDAP?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) with respect to RDAP?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure RDAP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure RDAP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to RDAP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the RDAP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to RDAP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv6?

Yes

Will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv6 if requested by a registrar?

Yes

Will this RSP provide tools and mechanisms to Registry Operators for the purposes of automated processing and identification of abusive domain registrations.

Yes

Describe the EPP and RDAP status values as they relate to domain name registrations considered to be abusive registrations and those not considered to be abusive registrations.

The Extensible Provisioning Protocol (EPP) and the Registration Data Access Protocol (RDAP) use status values to convey the current condition and administrative state of a domain name. These codes are critical to domain lifecycle management and help distinguish between normal operational states and those involving restrictions or potential abuse. EPP Status Values EPP, as specified in RFC 5730 and related documents, is used by registrars to manage domain objects. EPP status codes are assigned either by the registrar (client) or the registry (server) and fall into two main categories: • Normal Status Values (Non-Abusive Domains): o ok: Indicates that the domain is active with no restrictions. o addPeriod: Applied during the initial registration grace period. o autoRenewPeriod: Applied after domain expiration and automatic renewal. • Restrictive Status Values (May Apply to Abusive or Constrained Domains): o clientHold / serverHold: Suspends DNS resolution; often used in abuse mitigation or dispute handling. o clientDeleteProhibited / serverDeleteProhibited: Prevents domain deletion. o clientTransferProhibited / serverTransferProhibited: Blocks transfer to another registrar. o clientUpdateProhibited / serverUpdateProhibited: Restricts updates to domain data. Restrictive statuses can prevent unauthorized or malicious changes and help maintain registry integrity. RDAP Status Values RDAP, defined in RFC 7482 and related specifications, provides a web-based interface for accessing domain registration data. RDAP statuses are derived from EPP and shown in a human-readable format: • Normal: o active: Equivalent to EPP’s ok; domain is fully operational. • Restrictive: o Includes values such as serverHold, clientHold, deleteProhibited, transferProhibited, and updateProhibited, which reflect the EPP status codes and indicate operational limitations. Relation to Abusive Domains Restrictive status values are often applied in response to abuse cases but are not definitive proof of malicious behavior. Examples include: • A phishing or malware domain may be placed on serverHold to prevent resolution. • deleteProhibited may be applied to preserve domain data during investigations. • Transfer or update prohibitions may prevent evasion by bad actors. However, these same codes may also result from: • Legal disputes • Administrative enforcement • Non-payment issues Therefore, while restrictive status values can indicate abuse, they must be interpreted with supporting context. A restrictive status is a signal for review, not a final determination. The RSP ensures that all EPP and RDAP status values are accurately maintained and reflect real-time domain conditions. We utilize both automated tools and manual reviews to detect anomalies, support abuse mitigation, and maintain compliance with ICANN policies.

Describe the EPP and RDAP status values and their applicability to Uniform Rapid Suspension (URS).

The Registry Operator implements the Uniform Rapid Suspension (URS) mechanism in strict accordance with the ICANN URS Technical Requirements and Consensus Policies. We confirm that serverHold is NOT applied during URS proceedings to ensure the domain continues to resolve to the mandatory URS placeholder page. 1. URS Lock and Suspension Implementation • No serverHold: We do not apply serverHold. Applying this status would stop DNS resolution globally, preventing the redirection to the URS placeholder page. • Redirection: Upon a "Suspension" determination, we update the nameservers to those provided by the URS Provider. • Locking: To prevent changes, transfers, or deletions, we apply specific server-level prohibitions. 2. EPP to RDAP Status Mapping (RFC 8056 Compliance) We have updated our RDAP output to strictly match the IANA Registry for RDAP JSON Values and RFC 8056. The following list defines the mapping between EPP statuses applied during URS and their corresponding RDAP values: • Normal State (Pre-URS): ◦ EPP: ok ◦ RDAP: active • URS Lock / Suspension Active: ◦ EPP: serverUpdateProhibited ◦ RDAP: server update prohibited ◦ Description: Registry-level lock preventing updates. ◦ EPP: serverTransferProhibited ◦ RDAP: server transfer prohibited ◦ Description: Registry-level lock preventing transfers. ◦ EPP: serverDeleteProhibited ◦ RDAP: server delete prohibited ◦ Description: Registry-level lock preventing deletion. 3. Lifecycle Stages • Lock Phase: Upon complaint notification, serverUpdateProhibited, serverTransferProhibited, and serverDeleteProhibited are applied. • Suspension Phase: If upheld, nameservers are updated to the URS provider's servers. The three server-level locks remain. The domain remains in the DNS zone (no serverHold). • Termination: If the suspension ends or is successfully appealed, locks are removed, and the status returns to active.

Does or will this RSP implement the Registry Operator-related elements of RFC9361

Yes

Describe all potential registration lifecycle(s) of domain names supported in the system.

Our RSP supports two fully automated, ICANN compliant domain registration lifecycles. Both lifecycles operate on MySQL NDB Cluster with synchronous replication across the Tokyo primary site and a geo remote DR site. All transitions are executed using ACID transactions, logged through EPP poll messages, and fully auditable according to ICANN requirements. 1. Standard General Availability (GA) Lifecycle This lifecycle applies to all domains available for open registration. The states are as follows: Available The domain is unregistered and may be created via an EPP create command. Add Grace Period (5 days) Immediately after registration, the domain enters a 5 day Add Grace Period. If the registrar deletes the domain during this period, a full refund applies. Active (1 to 10 years) The domain is fully registered. EPP and RDAP both report status ok. DNS resolution and all registry services are active. Auto Renew Grace Period (45 days) When the domain expires, an automatic renewal is applied by the system. If the registrar deletes the domain within this period, the domain moves into Redemption. Auto renewal billing may be reversed depending on registrar policy. Renew Grace Period (45 days) Applies after an explicit renewal by the registrar. A delete during this period may result in a refund. Redemption Grace Period (30 days) If deleted, the domain enters Redemption. It is not active in DNS. The registrar may submit a restore request under RFC 3915. Pending Restore (7 days) If a restore request is submitted, the domain is placed in Pending Restore for up to 7 days while the required restore report is reviewed. Pending Delete (5 days) If no restore occurs, the domain enters a 5 day pending delete period. No further changes may occur. Purged After Pending Delete, the domain is removed from the registry and becomes Available again. This lifecycle supports DNSSEC, IDN, registry lock, RGP reports, and all standard ICANN grace periods. 2. Premium and Launch Phase Lifecycle This lifecycle is used for premium domains and new gTLD startup phases. It implements the following stages: Claims Phase Trademark Clearinghouse (TMCH) claims notices are returned via EPP check responses. This phase lasts 90 days. Sunrise (60 days) Trademark holders may register domains using an SMD file. Allocation follows trademark validation or defined policies. Landrush (30 days) Open registration period for applications. Allocation is determined by auction or first come first served rules. Premium General Availability Domains require a valid allocation token and may have premium pricing defined by the registry. Once registered, the domain follows the Standard GA lifecycle. This lifecycle uses the following ICANN approved extensions: EPP Launch Phase Extension (RFC 8334) Allocation Token Extension (RFC 8495) Registry Fee Extension (RFC 8748) 3. System Characteristics Across Both Lifecycles All transitions are executed with zero downtime using MySQL NDB Cluster ACID transactions. All lifecycle events are logged through EPP poll messages and RDAP event data. No custom or proprietary status values are used; all EPP and RDAP statuses follow IANA registered values. TMCH, premium pricing, allocation tokens, DNSSEC, and IDN policies are fully supported. This describes all domain registration lifecycles supported in the system. Detailed EPP and RDAP status mappings are provided in MAIN.10.2.

Describe the registration lifecycle(s) of domain names with respect to EPP status values and RDAP status values.

Our platform implements domain registration lifecycles in strict accordance with RFC 5731, RFC 3915, and ICANN policies. We have corrected all RDAP status strings to strictly match the IANA RDAP JSON Values registry and RFC 8056 (using space-separated lowercase). We also confirm the correct EPP statuses for AGP and Registry Lock. 1. Standard Domain Lifecycle Mappings • Available ◦ EPP: (No Object) ◦ RDAP: n/a (Returns HTTP 404 Not Found) • Add Grace Period (AGP) ◦ EPP: ok (combined with RGP status addPeriod) ◦ RDAP: active, add period ◦ Description: We confirm pendingCreate is NOT used here. • Active ◦ EPP: ok ◦ RDAP: active • Auto-Renew Period ◦ EPP: ok (combined with RGP status autoRenewPeriod) ◦ RDAP: active, auto renew period • Renew Grace Period ◦ EPP: ok (combined with RGP status renewPeriod) ◦ RDAP: active, renew period • Transfer Grace Period ◦ EPP: ok (combined with RGP status transferPeriod) ◦ RDAP: active, transfer period • Redemption Period ◦ EPP: pendingDelete (combined with RGP status redemptionPeriod) ◦ RDAP: pending delete, redemption period • Pending Restore ◦ EPP: pendingRestore ◦ RDAP: pending restore • Pending Delete ◦ EPP: pendingDelete ◦ RDAP: pending delete 2. Launch Phase Mappings • Sunrise/Landrush: EPP pendingAllocation maps to RDAP pending allocation. • General Availability: EPP ok maps to RDAP active. 3. Cross-Lifecycle Statuses (Locks and Holds) • Registrar Lock: ◦ EPP: clientTransferProhibited, clientDeleteProhibited, clientUpdateProhibited ◦ RDAP: client transfer prohibited, client delete prohibited, client update prohibited • Registry Lock: ◦ EPP: serverTransferProhibited, serverDeleteProhibited, serverUpdateProhibited ◦ RDAP: server transfer prohibited, server delete prohibited, server update prohibited • DNS Suspension: ◦ EPP: clientHold / serverHold ◦ RDAP: client hold / server hold • Transfer Process: ◦ EPP: pendingTransfer ◦ RDAP: pending transfer 4. Technical Compliance We confirm compliance with the 2024 gTLD RDAP Profile. Queries for non-existent domains return a proper HTTP 404 response structure.

Describe the nameserver host lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names. This should include a description of nameservers as either attributes of domains or as host objects.

Our RSP manages nameservers as independent EPP host objects in accordance with RFC 5732. Status mappings follow RFC 8056. 1. Nameserver (Host) Types • Subordinate (Internal) Host: A host whose FQDN is a subdomain of a domain registered in this registry. These must have IP addresses (glue) to be published in the zone. • External Host: A host whose FQDN is NOT a subdomain of a domain in this registry. Stored as references without IP addresses. 2. EPP to RDAP Status Mapping (RFC 8056 Compliance) We use strictly compliant IANA RDAP status values (lowercase with spaces): • EPP: ok ◦ RDAP: active ◦ Description: Host is operational. • EPP: linked ◦ RDAP: associated ◦ Description: Host is used by at least one domain. • EPP: pendingCreate ◦ RDAP: pending create • EPP: pendingDelete ◦ RDAP: pending delete • EPP: clientDeleteProhibited ◦ RDAP: client delete prohibited • EPP: serverDeleteProhibited ◦ RDAP: server delete prohibited • EPP: clientUpdateProhibited ◦ RDAP: client update prohibited • EPP: serverUpdateProhibited ◦ RDAP: server update prohibited 3. Lifecycle & Deletion Policy • Orphaned Glue Prevention: To maintain zone integrity and prevent "orphaned glue," when a Superordinate (parent) domain is deleted, our system policy cascades this deletion to associated Subordinate Hosts, provided they are not linked to other domains. • Linked Status: If a subordinate host has the linked status (used by other third-party domains), the parent domain deletion is rejected (EPP error 2305) to preserve the delegation of those third-party domains. • RDAP 404: Non-existent hosts return an HTTP 404 response structure, not an "inactive" object. • DNSSEC: DNSSEC information (DS records) is NOT included in the nameserver response; it is provided in the domain object response.

If applicable, describe the contact lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names and nameservers. Include a description of the deletion of orphaned contacts.

The Registry adopts a Thin Registry Model, whereby contact information (such as registrant, administrative, and technical contact details) is not stored in the Registry database. Implementation Policy: Under the Thin Registry Model, all contact information associated with domain names is managed and maintained by each Registrar within their own systems. The Registry database stores only the minimum technical information necessary for domain delegation, including domain names, nameservers, status codes, and sponsoring Registrar identification. Implementation in EPP/RDAP: - EPP Protocol: Creation or reference of contact objects is not required during domain registration or updates. Domain objects do not include associations with contact handles or contact IDs. - RDAP Service: In RDAP responses, domain objects contain only Registrar information (sponsoring Registrar's IANA ID and abuse contact information). Queries for detailed contact information are handled through referrals to each Registrar's RDAP service. This approach enhances data privacy protection and facilitates compliance with personal data protection regulations such as GDPR.

Does or will this RSP be capable of removing orphaned glue in accordance with the standards established in Specification 6 of the ICANN Registry Agreement (version 2024)?

Yes

Describe how this RSP will meet the standards established in Specification 2 of the ICANN Registry Agreement (version 2024), and describe any other data escrow processes. This includes escrow extensions for data related additional registry services.

Data escrow is a critical mechanism for ensuring the continuity and security of domain name registration data. It involves depositing copies of this data with a trusted third party, to be held securely and released under specific conditions. RSPs must adhere to established standards and processes for data escrow to maintain the integrity of the domain name system. Here's an overview of how an RSP meets data escrow standards: ● Compliance with Specification 2: ○ RSPs adhere to the requirements outlined in Specification 2, which mandates the regular submission of registry data to an escrow agent. ○ This includes the frequency of deposits (e.g., weekly full deposits), the format of the data, and the method of delivery. ○ RSPs ensure that the escrow agent is an independent and reputable entity, as required by the agreement. ● Data Escrow Agreement: ○ RSPs establish a formal data escrow agreement with the designated escrow agent. ○ This agreement defines the responsibilities of both parties, the conditions for data release, and the security measures in place to protect the escrowed data. ○ The agreement also typically designates the beneficiary (i.e., the entity that can receive the data under specific circumstances). ● Types of Deposits: ○ RSPs provide two main types of data deposits: 　　■ Full Deposits: A complete copy of all registration data, typically submitted on a weekly basis. ● Data Format and Delivery: ○ RSPs format the data according to the specified technical requirements, ensuring that it is complete, accurate, and usable. ○ Data is typically delivered to the escrow agent electronically, using secure transmission protocols to protect its confidentiality and integrity. ○ RSPs implement checksums and other validation mechanisms to verify the accuracy of the data transfer. ● Escrow Agent Responsibilities: ○ The escrow agent is responsible for securely storing the deposited data and ensuring its availability under the conditions specified in the data escrow agreement. ○ They must have robust security measures in place to protect the data from unauthorized access, loss, or damage. ○ Escrow agents may also be required to perform periodic verification of the deposited data to ensure its integrity and readability. ● Verification and Testing: ○ RSPs may conduct periodic testing and verification of the data escrow process to ensure that it is functioning correctly. ○ This may involve simulating data retrieval scenarios to confirm that the escrowed data can be successfully accessed and used. ● Escrow Extensions for Additional Services: ○ As RSPs offer additional data-related registry services beyond basic domain name registration, they may need to implement escrow extensions. ○ These extensions involve defining additional data elements and formats that need to be included in the escrow deposits to cover the new services. ○ RSPs work with the escrow agent to establish the necessary procedures and specifications for these escrow extensions. By adhering to these standards and processes, RSPs ensure that critical domain name registration data is securely protected and can be accessed if necessary, contributing to the stability and resilience of the domain name system.

Does or will this RSP regularly exercise registry continuity actions?

Yes

Does or will this RSP be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the ICANN Registry Agreement (version 2024).

In accordance with Specification 10 of the ICANN Registry Agreement (2024 version), this section documents the registry service provider’s current DNS service responsibilities and confirms that no service disruptions have occurred within the past six months. gTLDs Served As of the date of this application, the RSP provides authoritative DNS services for the following gTLDs: .shop, .tokyo, .okinawa, .nagoya, .yokohama, .ryukyu, .kyoto, .jcb, .nissan, .otsuka, .datsun, .infiniti, .canon, .suzuki, .gmo, .toshiba, .dnp, .hitachi, .nhk, .kddi, .ggee, .lotte, .sharp, .kia, .hyundai, .nico, .goo, .yodobashi, .goldpoint, .toyota, .sony, .ricoh, .komatsu, .honda, .nec, .panasonic, .brother, .toray, .softbank, .epson, .bridgestone, .fujitsu, .playstation, .mitsubishi, .hisamitsu, .firestone, .lexus. Service Disruption Criteria Per Specification 10, a service disruption is defined as: ● More than 5% of DNS queries taking longer than 300 milliseconds in a calendar month (Section 2.1) ● DNS service being entirely unreachable (Section 2.3) ● Failure to resolve valid domain names (Section 2.4) Service Disruption Record (Past Six Months) There have been no service disruptions across the above gTLDs during the six-month evaluation period. All authoritative DNS services remained fully compliant with ICANN SLA requirements and performance thresholds. Monitoring and SLA Compliance The RSP ensures SLA compliance through the following practices: ● Global telemetry and real-time alerting across diverse monitoring nodes ● Redundant health checks on query responsiveness and zone propagation ● SLA dashboards and monthly internal audits During the reviewed period, no SLA violations or reportable incidents occurred. DNS services for all supported gTLDs operated within the ICANN-defined parameters without interruption.