Applicant Information

Does or will this RSP have a publicly verifiable, 3rd 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

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

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

Yes

If RFC 8334 (“Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)”) is not applicable to this RSP, describe the mechanism to support sunrise and claims in EPP. Please answer with “Not Applicable” or “N/A” if this RSP does or will implement RFC 8334.

Not Applicable

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

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 list of EPP extensions used in the ZDNS EPP SERVER are as follows: Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Allocation Token Extension for the Extensible Provisioning Protocol (EPP) Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

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

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

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

For Proxy RDAP, ZDNS' Proxy RDAP function is to forward the RDAP response results from the true backend side of TLD. Therefore, for Proxy RDAP, the usage of RDAP extensions depends on the actual backend usage of the TLD. However, ZDNS' PROXY RDAP has already implemented the latest RDAP specification, the 2024 version, which involves RDAP extensions such as: icann_rdap_response_profile_0 icann_rdap_technical_implementation_guide_0 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 defined 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

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

The system has established the domain lifecycle based on ICANN's relevant RFC sDtandards and actual business needs, including: Available, Preaudit, Registered, Autorenew Period, Redemption Period, and Pending Delete. Among these, Preaudit is an optional lifecycle phase added to ensure that domain registration complies with local policies and regulations. After a domain is created, it first enters the Preaudit lifecycle phase (EPP status is pendingCreate, RGP status is N/A). Following a manual review by the registry, the domain officially takes effect and enters the Registered lifecycle phase (EPP status is serverTransferProhibited for the first 60 days, then changes to ok; RGP status is addPeriod for the first 5 days, then changes to N/A), with the review process taking no more than 5 working days. The diagram below illustrates the lifecycle transition process of a domain from creation, activation, expiration to its final deletion. In fact, the true lifecycle is managed by the actual MAIN RSP, with the PROXY RSP responsible for instruction forwarding, and the actual results ultimately being based on the actual MAIN RSP.

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

The Proxy RSP does not manage the lifecycle of domains; this is handled by the actual RSP. For example, operations such as domain expiration and takedown are managed by the actual RSP. If a user retrieves domain information through Proxy RDAP and the domain is a restricted term, a message will indicate that the domain is a restricted term.

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.

Proxy RSP does not manage the nameserver host lifecycle; this is handled by the actual RSP.

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.

Not Applicable.

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

N/A

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.

We implement Proxy Data Escrow in the following aspects to comply with Specification 2 of the ICANN Registry Agreement (version 2024): Scope of Data Held in Escrow: Since the Proxy RSP acts as an intermediary layer between registrars and the actual RSP, it only manages the registration data of registrars that are Proxy. Therefore, Proxy Data Escrow is responsible only for the domain registration data of the PROXY registrars. Full escrow of TLD data is handled by the actual RSP. Categories of Data Held: Proxy Data Escrow uses the Full category for data escrow, archiving all data up until 23:59:59 UTC of the current day. Frequency of Data Escrow: Data is held in the Full category every day. File Format Standards for Data Escrow: Proxy Data Escrow generates escrow files following RFC 8909 and RFC 9022, using UTF-8 character encoding. Data Integrity and Confidentiality: Original files are compressed into tar files. GunPG is used to encrypt the files and calculate signatures to ensure the security and integrity of the escrowed data. Notification of Data Escrow: Along with the escrow files, Proxy Data Escrow uploads a rep file to the escrow holder's SFTP server, which reports the contents of the escrow data. Proxy Data Escrow does not submit this report to ICANN. File Naming Conventions: Proxy Data Escrow adheres to the "file naming rules" defined in Specification 2 of the ICANN Registry Agreement (version 2024). Verification and Troubleshooting of Data Escrow: The escrow holder verifies the escrow files uploaded by Proxy Data Escrow. Upon receiving the escrow notification from the escrow holder, if the data escrow is unsuccessful, Proxy Data Escrow will repeat the escrow process within 24 hours continuously until successful.

Does or will this RSP regularly exercise registry continuity actions?

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 Registry Agreement (version 2024).

The list of gTLD currently being served is as follow: shop vip icu online site fun store tech work cloud cyou club website yoga co space ink love art pw biz wiki tv fit link 购物 host uno design press click bond beer luxe fans fashion law There have been no service disruptions in the past six months.