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.

1. In-house DNSSEC RSP If a gTLD operator chooses us to serve both the MAIN RSP and DNSSEC RSP roles, all Zone updates, signed zone transfers, DNSSEC-related cryptographic operations, including Key Signing Key (KSK) rollovers, are fully managed in-house. The applicant maintains detailed procedures for both planned and emergency KSK rollovers. As there is no third-party DNSSEC RSP involved, coordination is limited to IANA for DS record submission and validation. The applicant uses secure channels and follows IANA’s published procedures for DS record updates (Root Zone Management System). 2. Externa DNS RSP If a gTLD operator chooses to use an external DNSSEC RSP, and we, as the MAIN RSP, are required to coordinate DNSSEC operations. The responsibilities are divided as follows: • External DNSSEC RSP: Responsible for key management (KSK/ZSK), key rollovers, signing operations, publishing signed zone data, and maintaining DNSSEC policy. • MAIN RSP (we): Responsible for provisioning interface (EPP/UPDATE), integrating the signed zone into the SRS workflow, validating DS data, and communicating DS changes to IANA via the standard Root Zone Management (RZM) processes. In a Typical (Planned) DNSSEC Key Rollover: • Notification and Planning The external DNSSEC RSP notifies us of the rollover plan within the agreed SLA, providing the new DS parameters (key tag, algorithm, digest, digest type), timing, and required sequencing. Both parties confirm timing and propagation windows to avoid signature validity gaps. • DS Submission / Update Process. The external DNSSEC RSP provides us the new DS record(s). We validate the DS parameters (format, algorithm compatibility, syntax checks). As the MAIN RSP, we submit DS updates to IANA via the RZM interface according to the plan. • Monitoring. Both the external DNSSEC RSP and us should monitor IANA processing status, DNS root propagation, and TLD DNSSEC state (e.g., DS present, signatures valid). Any discrepancies are communicated promptly to the external DNSSEC RSP. An emergency rollover may be required in cases such as suspected private-key compromise or operational failure. • Immediate Notification：The external DNSSEC RSP informs us via the designated 24×7 emergency contact channels. The notice includes the reason, severity, required actions, and new DS data (if applicable). • Accelerated DS Update: We treat the DS change as a critical emergency request. We submit the DS update to IANA immediately through the expedited RZM contact path. We maintain continuous communication until the root zone is updated and validated. • Stability Monitoring: We track DNSSEC chain of trust recovery, DNS propagation, and validation success. Any anomalies are reported to the external DNSSEC RSP for rapid remediation. Our role as the MAIN RSP coordinating with IANA during Rollover is to ensure the root zone always reflects accurate and authenticated DS information. Technical Interface With the External DNSSEC RSP： • Deply Secure DNS Dynamic Update （RFC2136/RFC3007）to update zone data to External DNSSEC RSP； • Accepting zone data or delegated signer records through secure zone transfer (TSIG-protected); • Verifying that the zone is signed correctly • Ensuring zone data integrity and proper propagation to authoritative DNS operators.

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”).

EPP extentions we used are : urn:ietf:params:xml:ns:secDNS-1.1 urn:ietf:params:xml:ns:launch-1.0 urn:ietf:params:xml:ns:rgp-1.0 These URNs are registered EPP extensions that define protocol commands: "urn:ietf:params:xml:ns:secDNS-1.1" : This is the EPP extension for DNS Security (DNSSEC). It defines the EPP commands and objects needed to manage DS (Delegation Signer) records for a domain, allowing registrars to add, remove, and view DNSSEC data. It is registered in the IANA EPP extentsions registry as "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)"(RFC5910) "urn:ietf:params:xml:ns:launch-1.0": This is the Launch Phase Mapping extension. It provides the EPP commands for managing domain registrations during special launch phases (like Sunrise and Claims periods), which often require trademark validation. It is registered in the IANA EPP extensions registry as "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)"(RFC8334) "urn:ietf:params:xml:ns:rgp-1.0": This is the **Registry Grace Period (RGP)** extension. It defines the EPP commands and statuses related to the "Redemption Grace Period," allowing registrars to manage and restore domains that have been deleted. It is registered in the ANA EPP extensions registry as "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)"(RFC3915)

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.

icann_rdap_response_profile_1 icann_rdap_technical_implementation_guide_1 redacted

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.

EPP and RDAP Status Values for Abusive Registrations When a domain is identified as potentially involved in abusive behavior (such as phishing, malware distribution, or spam), the following status values(EPP/RDAP) will be applied to suspend or restrict its operation: • serverHold/server hold: The domain is removed from the DNS zone and will no longer resolve. • serverTransferProhibited/server transfer prohibited: Prevents the domain from being transferred to another registrar, often used during abuse investigations. • serverDeleteProhibited/server delete prohibited: Prevents the domain from being deleted, preserving data for compliance and law enforcement actions. • serverRenewProhibited/server renew prohibited: This status code indicates your domain's Registry Operator will not allow your registrar to renew your domain. • serverUpdateProhibited/server update prohibited: This status prevents any updates to the domain These status values help contain potential harm, preserve forensic evidence, and allow time for proper investigation and mitigation. Other EPP/RDAP statuses, as defined in the EPP/RDAP RFCs, are available for non-abusive registrations. Note: Corresponding clientHold, clientTransferProhibited, etc., statuses set by the Registrar have similar effects and are also a vital part of the abuse-handling ecosystem. As the RSP, we primarily control the server statuses.

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

"This RSP supports and applies specific EPP and RDAP status values to enforce domain suspension actions mandated under the Uniform Rapid Suspension (URS) dispute resolution procedure, in full compliance with ICANN Consensus Policies. Applicability of EPP Status Values to URS：clientHold / serverHold,clientTransferProhibited / serverTransferProhibited,clientDeleteProhibited / serverDeleteProhibited,clientUpdateProhibited / serverUpdateProhibited. The RDAP response will reflect the same EPP status values to indicate the suspension like: "client Hold", "server Hold", "client Transfer Prohibited" , "server Transfer Prohibited", "client Delete Prohibited" , "server Delete Prohibited", "client Update Prohibited", "server Update Prohibited". Note that the server* codes mean the values are set by the domain's Registry. client* code means values are set by the domain's Registrar.

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.

The RSP supports the full domain lifecycle, including available, add grace period, registered/renewal period, auto-renew grace period, redemption grace period (RGP), pending delete period, These lifecycle states are implemented under the ICANN gTLD Registry Agreement and EPP standards, ensuring consistent domain behavior and policy compliance across supported TLDs.

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

The registry system supports a complete and standards-compliant domain name registration lifecycle, with each phase reflected through specific EPP status values and exposed to registrars and third parties via RDAP status values. The supported lifecycle states and their corresponding EPP/RDAP status indicators are as follows: 1. Available : The domain is not registered and can be registered by any eligible registrar. • EPP Status: Not applicable (no object exists yet). • RDAP Status: Not found / 404 response (object does not exist). 2. Add Grace Period ：A short window (typically 5–7 days) after registration during which the domain can be deleted with a refund. • EPP Status: addPeriod (automatically assigned by the registry) • RDAP Status: add Period 3. Registered / Renewal Period (including Transfer Grace Period) : The domain is active and in a registered state, or has been recently renewed or transferred. • EPP Status: ok (default if no restrictions apply)， clientTransferProhibited, serverTransferProhibited (if locked)，clientDeleteProhibited, serverDeleteProhibited (if protected) • RDAP Status: Reflects all EPP status values for transparency. Transfer Grace Period: If applicable, this is a sub-state under the registered phase. Although not shown as a distinct EPP status, the registry internally tracks it. The domain may still display ok, while eligible for refund upon deletion. 4. Auto-Renew Grace Period : After auto-renewal (on expiration), the domain enters a period (e.g., 45 days) where it can be deleted with refund of the renewal fee. • EPP Status: autoRenewPeriod • RDAP Status: auto Renew Period 5. Redemption Grace Period (RGP): After a domain is deleted, it enters RGP (usually 30 days), during which it can be restored. • EPP Status: pendingDelete，redemptionPeriod • RDAP Status: pending Delete, redemption Period 6. Pending Delete Period : After RGP, the domain enters a final 5-day period where it cannot be restored before being purged from the registry. • EPP Status: pendingDelete • RDAP Status: pending Delete The registry ensures all lifecycle transitions are recorded and reflected via the appropriate EPP status codes per [RFC 3915] and RDAP status fields per [RFC 7483], maintaining consistency and transparency for registrars, registrants, and ICANN compliance systems.

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.

This RSP supports both internal (in-bailiwick) and external (out-of-bailiwick) nameservers, with full compliance to the EPP protocol (RFC 5732) and RDAP standards. Nameservers are managed as host objects, which are referenced by domain objects to delegate DNS resolution. 1. Nameserver Registration Model In compliance with RFC 5731, which mandates that an EPP repository MUST support only one model for representing nameservers, this RSP exclusively supports the Host Object Model. Host Objects (Discrete EPP objects) Nameservers are created using the <host:create> command and managed as independent objects within the registry. This model provides superior referential integrity and security control over the host records and their associated IP addresses. Example: ns1.example.net is a Host Object with its own lifecycle, IP(s), and status values. 2. Host Object Lifecycle Host objects are managed through a dedicated lifecycle that ensures separation from the domain object lifecycle: • Creation (<host:create>) Registrars may create nameserver host objects. These may be: - In-bailiwick: Subdomains of the domain being managed, requiring "glue records" (e.g., ns1.example.tld). - Out-of-bailiwick: External to the domain (e.g., ns1.otherdomain.com). • Association with Domains Domains reference existing host objects as part of their delegation configuration. A domain may list 2–13 host objects as authoritative nameservers. • Update (<host:update>) IP addresses (IPv4 and/or IPv6) and status values of host objects can be updated independently via EPP commands without affecting any referencing domain objects. • Deletion (<host:delete>) Host objects can only be deleted if they are not referenced by any domain object. The registry enforces this through strict referential integrity constraints. 3. EPP and RDAP Status Values The EPP status value for the host object is defined in RFC5732 #section-2.3. The mapping between EPP and RDAP Status Values is defined in RFC8056. The following is the EPP and RDAP Status value for Nameserver (EPP value/RDAP value) • ok /active: Normal state; the host is active and ready for use. • linked/associated: Indicates the host object is currently associated with at least one domain for delegation. Deletion is prohibited. • clientDeleteProhibited / client delete prohibited: Set by the Registrar; prevents host deletion. • serverDeleteProhibited /server delete prohibited: Set by the Registry (RSP); prevents host deletion, often for regulatory reasons. • clientUpdateProhibited /client update prohibited: Set by the Registrar; prevents host update. • serverUpdateProhibited / server update prohibited: Set by the Registry (RSP); prevents host update, often for regulatory reasons. • pendingCreate/pending create, pendingDelete/pending delete, pendingTransfer/pending transfer, pendingUpdate/pending update: The requested action is pending。 4. Relationship to Domain Lifecycle • Nameservers (host objects) are essential to domain activation. A domain must reference at least two valid host objects to be eligible for publication in the authoritative DNS zone file. • When a domain is created, it must reference existing host objects or create new, required in-bailiwick host objects. • When a domain is deleted, the host objects remain unless they become orphaned (no longer referenced by any active domain). 5. Orphaned Host Cleanup The RSP implements a periodic scan and audit process to detect orphaned in-bailiwick host objects—i.e., host objects that are no longer referenced by any active domain. These orphaned objects are flagged and automatically cleaned up after a defined quarantine period to maintain the integrity and cleanliness of the registry database. 6. Compliance and Logging All host object operations are logged and auditable. The system strictly enforces referential integrity and complies with all ICANN requirements for: • WHOIS/RDAP display of host object data. • Status code transparency and mandated usage. • Enforcement of Host Object-to-Domain

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.

This RSP implements a lifecycle model for contact objects that aligns with the EPP specification (RFC 5733) and ICANN registry requirements. The lifecycle supports the creation, association, update, and deletion of contact objects, with safeguards in place to maintain data integrity and avoid orphaned references. ⸻ 1. Contact Object Lifecycle • Creation (<contact:create>) A contact object is created by a registrar using the EPP <contact:create> command. At this point, it exists independently and is not yet associated with any domain or host object. • Association with Domain Names or Hosts Once created, contact objects can be referenced in domain objects as: • Registrant Contact • Administrative Contact • Technical Contact • Billing Contact (if supported) • Update (<contact:update>) The contact data (e.g., name, email, address) can be modified by the sponsoring registrar. Status values such as clientUpdateProhibited or serverUpdateProhibited may prevent modification under certain policies or dispute conditions. • Deletion (<contact:delete>) A contact object can be deleted only if it is not currently linked to any domain or host object. Attempts to delete an “in-use” contact will result in an error response per EPP protocol. ⸻ 2. EPP and RDAP Status Values • Common EPP status values applied to contact objects include: • ok: Normal status, no restrictions • clientDeleteProhibited / serverDeleteProhibited: Prevent deletion • clientUpdateProhibited / serverUpdateProhibited: Prevent updates • RDAP represents these statuses in the status field of the contact object response, providing registrars and third parties visibility into the contact’s operational state. ⸻ 3. Orphaned Contact Management • Definition: A contact object is considered orphaned if it is no longer referenced by any domain name or host object. • Automatic Cleanup Policy: This RSP implements a scheduled cleanup process to identify and delete orphaned contact objects after a defined retention period (e.g., 30 days of inactivity and no associations). • Safeguards: • All deletions are preceded by integrity checks to ensure no references remain. • Audit logs of contact deletions are retained for ICANN compliance review. • Registrar Notifications (if applicable): Registrars may be optionally notified prior to deletion of orphaned contacts, depending on registry policy. ⸻ 4. Consistency and Compliance • The contact lifecycle is synchronized with the domain and host object lifecycles to maintain referential integrity. • All lifecycle transitions are logged and tracked for compliance with ICANN data retention and escrow requirements.

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.

This RSP meets all requirements under Specification 2 of the ICANN Registry Agreement (2024), Section 4. The following practices are implemented: Daily Full Deposit: A complete snapshot of registration data is generated daily at 00:00 UTC. • Escrow Format: Structured in CSV format, as specified in Section 4 of Specification 2. Encryption & Signing: • Encryption Algorithm: RSA (using escrow agent’s public key) • Signature Algorithm: SHA-256 Transport Protocol: Secure file delivery is performed over SFTP, with automatic retries and logging. • Automated Process: Data is extracted from PolarDB-X 2.0, serialized and verified by internal tooling (alirs-task), then securely transmitted. The system is fully automated, monitored, and auditable to ensure continuity and compliance with ICANN escrow obligations.

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).

Currently, this RSP is a new one. We are not serving any TLD on our platform.