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 Registry does not perform DNSSEC signing operations and does not act as a DNSSEC RSP. All DNSSEC key generation, key management, and signing activities are performed by a designated external DNSSEC RSP. In our role as the Main Registry Service Provider (Main RSP), our responsibilities are limited to coordinating the rollover process, managing DS records in the SRS, and leading communication with IANA/PTI.The Registry does not perform DNSSEC signing operations and does not act as a DNSSEC RSP. All DNSSEC key generation, key management, and signing activities are performed by a designated external DNSSEC RSP. In our role as the Main Registry Service Provider (Main RSP), our responsibilities are limited to coordinating the rollover process, managing DS records in the SRS, and leading communication with IANA/PTI. For non-emergency (planned) KSK rollovers, the Main RSP initiates the process in coordination with the DNSSEC RSP and confirms the planned timeline and readiness. The DNSSEC RSP performs all technical DNSSEC operations and, once the new KSK is prepared, provides the corresponding DS record to the Main RSP through an authenticated communication channel. The Main RSP registers the new DS record in the SRS and submits a request to IANA/PTI, via the authorized IANA Account Holder, to add the new DS record to the root zone while retaining the existing DS record during the transition period. The Main RSP tracks the request, coordinates timing with the DNSSEC RSP, and confirms successful publication. Once the DNSSEC RSP confirms that the old KSK is no longer in use, the Main RSP submits a request to IANA to remove the obsolete DS record and updates the SRS accordingly. For emergency KSK rollovers, such as in the event of key compromise, loss, or other critical incidents identified by the DNSSEC RSP, the DNSSEC RSP immediately notifies the Main RSP and provides an emergency DS record as soon as it becomes available. The Main RSP activates an expedited change process and submits an emergency DS update request to IANA/PTI, clearly identifying the request as time-sensitive. The Main RSP closely coordinates timing and status updates with the DNSSEC RSP and monitors confirmation from IANA to minimize the risk of DNSSEC validation failures. After resolution, obsolete DS records are removed, and the incident is documented and reviewed. To ensure ongoing readiness, the Main RSP maintains documented procedures, validated communication channels with the DNSSEC RSP and IANA, and conducts periodic coordination reviews to ensure both planned and emergency rollovers can be executed in a controlled and timely manner.

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

All extensions used are registered with IANA as per RFC 7451: - RGP: urn:ietf:params:xml:ns:rgp-1.0 - secDNS: urn:ietf:params:xml:ns:secDNS-1.1 - launch: urn:ietf:params:xml:ns:launch-1.0 - secure-authinfo-transfer: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 All listed extensions are IANA registered and RFC-compliant.

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_technical_implementation_guide_1 icann_rdap_response_profile_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.

Statuses we will set for abusive registrations (registry action) When an investigation determines a domain is being used for well-evidenced abuse (e.g., phishing, malware, etc.), we will apply server (registry) statuses so the name is removed from DNS and administratively frozen: 1) Abuse suspension (takedown) EPP statuses we will set - serverHold -> removes DNS delegation publication (domain will not resolve) - serverUpdateProhibited -> prevents updates - serverTransferProhibited -> prevents registrar transfer - serverDeleteProhibited -> prevents deletion while the case is handled (preserves continuity/evidence and avoids immediate re-registration) Equivalent RDAP status values that will appear - server hold - server update prohibited - server transfer prohibited - server delete prohibited Optionally, where our RDAP implementation includes it, we may also surface: locked (informational) to indicate the object is not changeable during the suspension window 2) Abuse investigation hold (case open, takedown not yet required) If a case is under active investigation and we need to prevent changes before deciding on DNS takedown, we will apply an administrative freeze without taking it out of DNS: EPP statuses - serverUpdateProhibited - serverTransferProhibited - serverDeleteProhibited RDAP status - server update prohibited - server transfer prohibited - server delete prohibited - locked 3) Restoration after mitigation Once abuse is remediated and verified, we will remove the suspension statuses (at minimum serverHold, and any prohibitions that were applied) so the domain can return to normal operation (active/ok)

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

1. URS Lock Upon receipt of a valid URS Notice, we apply URS Lock within 24 hours, using only the three mandatory EPP server statuses required by the URS procedure: • serverUpdateProhibited • serverTransferProhibited • serverDeleteProhibited No additional EPP statuses (such as serverHold or clientHold) are applied during URS Lock, as they are not part of the URS Lock definition. EPP to RDAP Status Mapping (per RFC 8056) In accordance with RFC 8056, the EPP server statuses applied during URS Lock are reflected in RDAP using the following direct one-to-one mappings: serverUpdateProhibited = server update prohibited serverTransferProhibited = server transfer prohibited serverDeleteProhibited = server delete prohibited These RDAP status values are defined by RFC 8056 and accurately represent that the domain name is restricted from update, transfer, and deletion while under URS Lock. 2. URS Suspension If the URS Determination requires suspension, we implement URS Suspension exactly as specified: • the domain remains registered, • the domain cannot function normally, and • the domain name is redirected to a webpage indicating that it has been suspended due to a URS Complaint, as required by the URS Technical Requirements. No hold statuses are applied during this phase, since they are not part of the URS procedure. Registration data output reflects that the domain is under URS Suspension in accordance with the URS process.

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.

New Domain name - active Auto Renewal Period (45 Days) - renew period Redemption Period (30 Days) - pending delete Pending Delete (7 Days) - pending delete

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

New Domain name - active Auto Renewal Period (45 Days) - renew period Redemption Period (30 Days) - pending delete Pending Delete (7 Days) - pending delete If transfered it will have status of "pending transfer", after 5 days it will auto approve and move to new registrar and changed the status to "active"

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.

1. Host Object Creation A registrar can create a host object using the EPP <host:create> command. When an in-zone (subordinate / in-bailiwick) host is created, it must be associated with an existing parent domain object. If the parent domain is deleted (when permitted), the subordinate in-zone host lifecycle is affected and the subordinate host must be cleaned up, provided it is not referenced by any other domain. 2. Host Object Lifecycle States A host object may transition through the following EPP status values: • ok The default status, indicating that the host object is active and available for delegation. • linked Indicates that the host object is associated with one or more domain objects. A host in linked status cannot be deleted until all references are removed. RDAP Representation of Host Status In RDAP, host objects are represented as nameserver objects. RDAP displays the same lifecycle information by exposing status values that correspond to the underlying EPP states: • EPP ok → RDAP active • EPP linked → RDAP associated RDAP responses provide: • Nameserver hostname • IPv4 / IPv6 addresses (if present) • Links/relationships to related objects (where supported by the registry’s RDAP implementation) • Status values showing the current operational or policy constraints This ensures transparency and alignment between EPP-based provisioning flows and RDAP’s public data model. 3. Behavior When the Parent Domain of an Internal Host Object Is Deleted In our registry implementation, a parent domain cannot be deleted if there are still internal subordinate host objects (child hosts) derived from that domain which are actively used (i.e., still linked/referenced) by other domains. The parent-domain deletion is only permitted after those dependencies are removed and the subordinate hosts are no longer linked.

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.

Our registry supports contact objects following RFC 5733 (EPP Contact Mapping) and provides full transparency of status values through both EPP and RDAP. A contact object may have multiple operational or policy-related statuses applied to it. These statuses indicate whether the contact can be updated, transferred, deleted, or associated with other objects. # EPP Contact Status Codes and Their RDAP Equivalents The following contact-related EPP statuses are supported, together with their corresponding RDAP status codes presented to the public: EPP: ok RDAP equivalent: active The contact is active and has no pending or prohibited operations. EPP: linked RDAP equivalent: associated The contact is associated with at least one domain, host, or other registry object. Deletion Protection: A contact cannot be deleted while it remains linked to any domain or host. The registry system enforces this at the database level. It's instantly deleted if it's an orphaned contact

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.

The RSP performs scheduled queries to extract all required registration data fields, including: Domain Namew Domain Name Repository Object ID (ROID) Registrar ID (IANA ID) Domain Statuses Creation Date Last Updated Date Expiration Date Name Server Names The extracted data is converted into an XML-formatted file in accordance with ICANN’s data escrow format specifications. This XML file is then compressed into a TAR.GZ archive and digitally signed to verify data authenticity and integrity. Once the signature is generated, the compressed file is encrypted using OpenPGP to ensure confidentiality during transfer. The encrypted file is then securely transmitted to an ICANN-accredited Data Escrow Provider (to be finalized prior to production) via SFTP over an encrypted connection. Data escrow submissions are performed on a weekly schedule, and all transfer activities are verified through checksum validation (SHA-256) to confirm file integrity and successful receipt by the escrow provider. Locally retained copies of escrow files are stored securely for a period of seven (7) days before being archived or purged according to retention policy. At present, the data escrow process is conducted manually under controlled operational procedures. However, the RSP is actively developing a fully automated escrow submission system to further enhance reliability, consistency, and compliance monitoring. In the event that additional registry services are introduced, the RSP will extend its escrow mechanism to include all related data types, ensuring full adherence to ICANN’s specifications for data protection and business continuity.

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

We implement the same application as the registry domain of .id registry. So we will provide the service distruption in the past six months based on the .id registry application