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.We will strictly fulfill our core responsibility of coordinating DS record changes between DnssecRSP and IANA.Emergency key rotation is only initiated in the event of serious security incidents such as DNSSEC key leakage, loss, tampering, etc. that threaten domain name resolution security in DnsecRSP: DnssecRSP first notified the center through both phone and email channels to initiate the rotation and complete preparations such as backing up old keys. Upon receiving the notification, we immediately activated the emergency response team, verified the incident, and determined whether to execute the rotation and synchronously informed DnssecRSP; After both parties confirm the rotation, set up an online emergency group, hold coordination meetings, clarify the rotation time window, key generation standards, DS record format, and emergency rollback plan; After verifying that the new public key provided by DnssecRSP corresponds to the correct DS record, we will proceed with parsing deployment and loading, and submit update requests through the official IANA system interface. In emergency situations, we will separately apply to IANA via email to increase the priority of work order processing; In the future, we will work together with DnssecRSP and IANA to monitor the integrity of the DNSSEC key trust chain and the success rate of resolution. At the same time, we will track the progress of IANA work orders in real time and synchronize it with DnssecRSP to coordinate and resolve resolution issues in a timely manner. 2. For external DnssecRSP, we adopt a multidimensional collaborative mechanism to ensure smooth rotation:Require them to initiate rotation notifications through both telephone and email channels and keep traceable records, establish a dedicated online emergency group to synchronize key generation, record verification, and other key information in real time, organize online coordination meetings during key rotation stages to align risks, details, and rollback plans, and continuously synchronize IANA work order progress, resolve anomalies, and other full process information with them. 3. Our coordination and communication with IANA follow the principles of standardization and efficiency:Strictly submit DS record update requests through the official IANA system interface to ensure process compliance and traceability. In emergency situations, notify IANA of the severity of the incident via email and apply for an increase in work order priority. Track work order progress in real time through official channels and respond promptly to node issues. During the transition period, synchronize key trust chains, resolution success rates, and other monitoring data to IANA. Provide immediate feedback on abnormal situations and collaborate to develop solutions.

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?

No - Currently, although we have not introduced IaC into the field of operation and maintenance management, we have implemented numerous measures and processes aimed at reducing the potential security and stability risks arising from manual operations in operation and maintenance management. Firstly, through service process management, we strictly regulate every aspect of the service delivery, service launch, service change, and service decommissioning processes, involving multi-level approval processes. These processes are executed after being approved by the technical supervisor. For major operations involving the overall stability of the system, they must be reported to senior management for final confirmation before implementation, and we ensure that every delivery and change of the service deployment package is traceable and reversible. The service deployment package undergoes unit testing, integration testing, security testing, and other stages in the R&D department to ensure that the code deployment does not affect system stability. After being delivered to the operation and maintenance management department, the operation and maintenance management department verifies the functions of the service deployment after launch through gray release, and can perform rollback operations at any time if there are issues. In addition, for operations involving changes to database metadata or business data, the DBA strictly controls the change statements, performs change and deployment verification in the OT&E environment, and then deploys and upgrades in the production environment. Secondly, a log audit system is deployed on the execution operation terminal and server to record all manual operations in their entirety and ensure they cannot be tampered with. And through real-time monitoring, core indicators related to manual operations (such as DNS resolution success rate, system response time, key status, etc.) are monitored in real-time, with multi-level alarm thresholds set. In the event of operational anomalies (such as resolution failure due to configuration errors), the system alarm is immediately triggered to ensure that operation and maintenance personnel respond promptly.

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

No - We have adopted Ansible for configuration management to enhance work efficiency, reduce the risks associated with manual operations, and ensure consistency, repeatability, and verifiability in executing large-scale operations and maintenance tasks. Some services utilize Docker containerization technology to simplify service deployment and launch processes, but we have not yet employed Kubernetes for container orchestration and management.

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

N/A

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

Our EPP system currently supports RFC 3915, RFC 5910, and RFC 8334, all of which are registered in the IANA registry. No other extensions are supported at this time. Should additional extensions become necessary in the future, we will implement them and register them with IANA accordingly.

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.

According to the general requirements of the RSP program, our RDAP service has implemented the following extension protocol: 1.RFC 9537: “redacted” extension. 2.icann_rdap_response_profile_1. 3.icann_rdap_technical_implementation_guide_1.

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.

Please find detailed response in the attachment.

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

1. URS Lock： When a domain name is in URS lock status, the following EPP statuses will be activated to prevent the domain name from being updated, transferred, or deleted: I.serverUpdateProhibited II. serverTransferProhibited III. serverDeleteProhibited RDAP statuses when a domain name is in URS Lock. I. server update prohibited II. server transfer prohibited III.server delete prohibited 2. URS Suspension： A domain name may be suspended as part of the final decision of a URS Complaint. The NS and DS information for the domain name will be updated. The domain with URS Suspension status will be redirected to a webpage that mentions that the domain name has been suspended because of a URS Complaint. 3. URS Rollback: This process is initiated upon request from the URS Provider to revert the domain to a non-URS status. We restore the domain's original information that was originally present in the domain name before the URS status.

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.

Registration lifecycle： 1、Available 2、Add-grace period：5 days 3、Registered：（1-10 year term） 4、Transfer lock period：60 days after registered 5、Renew grace period：30 days before expired 6、Expired 7、Auto-renew grace period：45 days after expired 8、Redemption period：30 days after auto-renew grace period 9、Pending delete：5 days after Redemption period 10、Released

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

Please find the details in the attached file.

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.The status of the host after creation is OK, and users can modify the client status of the host. Hosts that are not referenced by domain names and have no status restrictions can be deleted. When deleting a domain name, the internal hosts that use it as their parent domain must also be deleted. The host status will be presented in the host query of RDDS. 2.The host state set by the client must be prefixed with 'client' before the state value; The host state set on the server side must be prefixed with 'server' before the state value; If there is no prefix before the status value, it indicates that the status value is managed by the server-side. The client cannot directly modify it through the update command. The host state value set on the server side cannot be modified on the client side; The host state value set on the client side can be modified by the server and client according to corresponding policy constraints. 3. The coexistence and mutual exclusion relationship of various state values of the host is as follows: 'ok' can only coexist with the 'linked' status. ""pendingDelete"" is mutually exclusive with ""clientDeleteProhibited"" and ""serverDeleteProhibited"". 'pendingUpdate' is mutually exclusive with 'clientUpdateProhibited' and 'serverUpdateProhibited'. Each pending state is mutually exclusive (pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate). 4. The correspondence between host status values and RDAP status values is as follows (RDAP status values are on the right side of ""=""): clientDeleteProhibited = client delete prohibited clientUpdateProhibited = client update prohibited linked = associated ok = active pendingCreate = pending create pendingDelete = pending delete pendingTransfer = pending transfer pendingUpdate = pending update serverDeleteProhibited = server delete prohibited serverUpdateProhibited = server update prohibited 5.Based on the relationship between hosts and the registry, they are classified into internal hosts and external hosts. A host operated by a registrar that has configuration permissions for a Top-Level Domain (TLD) is defined as an internal host. When creating an internal host, it is necessary to include the host's IP address and support both IPv4 and IPv6 addresses. When creating an internal host, its parent domain name cannot be in any pending state. 6. When an internal host is not referenced by a domain and has no special status restrictions, it can be deleted, or when its parent domain is deleted, the host will also be synchronously deleted. Generally, after the internal host is deleted, the resource records in the zone file with this host as the NS record will also be deleted. For orphaned host, we will notify the registrar of the orphaned host to delete it.

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.

1. Creating a contact can carry real-name extension information, support DCP strategy, and the status of the created contact is set to ""ok"". Contacts referenced by domain names cannot be deleted. Each contact object must have at least one associated status value. The contact status set by the client must be prefixed with ""client"" before the status value. The contact status set by the server must be prefixed with ""server"" before the status value. If no prefix is added before the status value, it indicates that this status value is managed by the server. The contact status value set by the server cannot be modified by the client. The contact status value set by the client can be modified by both the server and the client according to the corresponding policy constraints. 2. The coexistence and mutual exclusion relationships among various state values of contacts are as follows: ""ok"" can only coexist with the ""linked"" state, ""pendingDelete"" is mutually exclusive with ""clientDeleteProhibited"" and ""serverDeleteProhibited"", ""pendingTransfer"" is mutually exclusive with ""clientTransferProhibited"" and ""serverTransferProhibited"", ""pendingUpdate"" is mutually exclusive with ""clientUpdateProhibited"" and ""serverUpdateProhibited"", The pending states (pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate) are mutually exclusive, Various state values other than those mentioned above can coexist. 3. The correspondence between the EPP status value and the RDAP status value of the contact is as follows (RDAP status values are on the right side of ""=""): clientDeleteProhibited = client delete prohibited， clientTransferProhibited = client transfer prohibited， clientUpdateProhibited = client update prohibited， linked = associated, ok = active， pendingCreate = pending create， pendingDelete = pending delete， pendingTransfer = pending transfer， pendingUpdate = pending update， serverDeleteProhibited = server delete prohibited， serverTransferProhibited = server transfer prohibited， serverUpdateProhibited = server update prohibited. 4. Orphaned Contacts: Orphaned contacts refer to those contacts that are no longer associated with any domain name. They generally appear after a domain name is deleted or transferred. We plan to regularly delete such contacts, except for registrars with special policies. Exceptions apply to contact with EPP statuses of clientDeleteProhibited, serverDeleteProhibited, pendingDelete (corresponding RDAP statuses are client delete prohibited, server delete prohibited, pending delete).

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.

It supports full and incremental (diff) data generation modes, extracts corresponding data by mode, and generates data files in the format required by Registrar Data Escrow (RDE). It then validates, compresses, encrypts the data files, generates summaries, and finally uploads them to the designated DEA for escrow.

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

Provide MAIN RSP services for the new generic top-level domains (.xn--xhq521b/.xn--1qqw23a), without any service interruptions in the past six months.