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 response exceeds 4,000 characters, so it is included in the attached document.

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

N/A

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

The following EPP extension are used: - RFC 3915 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) - RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC 8334 - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) - RFC 9154 - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer

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?

No - We anticipate that very few clients will want to bootstrap an entity query, so we do not plan to implement RFC 8521 at this time. However, we will implement RFC 8521 in the future if necessary.

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

No - We anticipate that very few clients will want to bootstrap an entity query, so we do not plan to implement RFC 8521 at this time. However, we will implement RFC 8521 in the future if necessary.

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.

In accordance with the requirements of the 2024 gTLD RDAP profile, we will implement the following RDAP extensions: - icann_rdap_response_profile_1 - icann_rdap_technical_implementation_guide_1 We do not obtain registrant or contact data from the registrar. Since there is no data requiring redaction, we will not use the “redacted” extension. These extensions will be fully supported and maintained to ensure compliance with ICANN’s requirements for all gTLD registries and registrars. If additional RDAP extensions become mandated in the future, we will promptly implement them as required.

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

Yes

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

The EPP and RDAP statuses that are set when an unauthorized registration of a domain name is suspected are as follows. The appropriate status values defined in RFC 5731 are set. EPP/RDAP: serverHold/server hold serverDeleteProhibited/server delete prohibited serverRenewProhibited/server renew prohibited serverTransferProhibited/server transfer prohibited serverUpdateProhibited/server update prohibited For a domain name in normal status, we will set one of the following appropriate statuses as defined in RFC 5731. EPP/RDAP: ok/active inactive/inactive etc. Please note that the following conditions may be set on a transitional basis. EPP/RDAP: pendingTransfer/pending transfer pendingDelete/pending delete pendingCreate/pending create Values not defined in RFC 5731 will not be set.

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

In accordance with the Uniform Rapid Suspension (URS) technical requirements and the latest ICANN high-level technical requirements, the following EPP and RDAP status values are applied to domain names subject to URS procedures. Status Mapping Table: EPP Status | RDAP Status | Applicability to URS serverUpdateProhibited | update prohibited | Set when a domain name is in URS lock or URS Suspension serverTransferProhibited | transfer prohibited | Set when a domain name is in URS lock or URS Suspension serverDeleteProhibited | delete prohibited | Set when a domain name is in URS lock or URS Suspension (may be removed upon expiration) inactive | inactive | May be set if the domain is not delegated All status values are managed in accordance with URS and ICANN registry policy requirements to ensure the integrity and security of the domain during the URS process. When the URS procedure is completed and a URS Lock or URS Suspension is removed (Non-URS State/URS Rollback), the statuses such as serverUpdateProhibited, serverTransferProhibited, and serverDeleteProhibited are removed, and the domain status is restored to its previous state.

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 following is a list of domain name statuses: No.1: EPP status=“ok” and RGP status=“addPeriod” The state immediately after new registration. The grace period is five days. If a <delete> command is used within the grace period, the registration is deleted without a <restore> operation, and the domain name will be available for re-registration. The RGP status disappears after a five-day grace period (changes to status No. 2). Domain names in this status are extracted to the zone file. No.2: EPP status=“ok” and RGP status=“N/A” Name servers are set up and DNS name resolution is available. Domain names in this state are extracted to the zone file. No.3: EPP status=“ok” and RGP status=“autoRenewPeriod” This is the state after the domain name registration period expires and has automatically been resumed. The grace period is 45 days. If a <delete> command is used within the grace period, a <restore> grace period is given, and then a delete operation begins. The RGP status disappears after a 45-day grace period (changes to status No.2). Domain names in this status are extracted to the zone file. No.4: EPP status=“ok” and RGP status=“renewPeriod” The state immediately after the domain name registration period has been extended using the <renew> command. The grace period is five days. If a <delete> command is used within the grace period, a <restore> grace period is given, and then a delete operation begins. The RGP status disappears after a five-day grace period (changes to status No.2). Domain names in this state are extracted to the zone file. No.5: EPP status=“clientHold” and RGP status=“N/A” The domain is no longer valid at the registrar's request. Domain names in this state are not extracted to the zone file. No.6: EPP status=“serverHold” and RGP status=“N/A” The domain name is no longer valid due to the requirements of the registry. Domain names in this state are not extracted to the zone file. No.7: EPP status=“pendingTransfer” and RGP status=“N/A” The transfer request has been accepted and is currently awaiting confirmation from the current registrar. Domain names in this status are extracted to the zone file. No.8: EPP status=“ok” and RGP status=“transferPeriod” The state immediately after a transfer is made. The grace period is five days. If a <delete> command is used within the grace period, a <restore> grace period is given, and then a delete operation begins. The RGP status disappears after a five-day grace period (changes to status #2). Domain names in this status are extracted to the zone file. No.9: EPP status=“pendingDelete” and RGP status=“redemptionPeriod” This is the state immediately after the domain name has been deleted using the <delete> command, and it can be recovered. The grace period is 30 days. Requests for recovery are accepted during this grace period (move to status No. 10). Domain names in this status are not extracted to the zone file. No.10: EPP status=“pendingDelete” and RGP status=“pendingRestore” This is a state in which a recovery request has been received while the deleted domain name is in a recoverable state. The grace period is seven days. If a report is received within this grace period, the status changes to EPP status="ok," RGP status="N/A" (status No.2). If a report is not received within the grace period, the status changes to recoverable (status No. 9). Domain names in this status are not extracted to the zone file. No.11: EPP status=“pendingDelete” and RGP status=“pendingDelete” The recoverable state has ended, and the unrecoverable deletion process is in progress. The domain name will be available for re-registration after five days. If two name servers are not configured, the status will become inactive instead of ʺokʺ. The main state transitions are shown in the accompanying diagram.

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

The attached diagram shows the main state transitions. The RDAP status values are set as shown below, which correspond to the EPP status values shown in the diagram. EPP/RDAP: ok/active serverHold/server hold clientHold/client hold pendingTransfer/pending transfer pendingDelete/pending delete

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.

Nameserver hosts can be associated with domain names by creating them as host objects. [EPP Status Codes Available for Host Objects] - ok - linked - serverDeleteProhibited - serverUpdateProhibited - clientDeleteProhibited - clientUpdateProhibited In our implementation, RDAP does not display the status code of the host object, so there are no corresponding RDAP status codes for the above EPP status codes. [Creation, Update, and Deletion of Host Objects] - For both managed and unmanaged TLDs, any registrar can create host objects. - For host objects under unmanaged TLDs, only the registrar that created the host object can update or delete it; other registrars cannot perform these operations. - For host objects under managed TLDs, any registrar can create the host object, but only the sponsoring registrar of the corresponding domain name can update or delete the host object. - When a host object is associated with one or more domain names, the host object is set to the “linked” status. If a host object is not associated with any domain name for a certain period (e.g., 30 days), it will be automatically deleted. When a domain name is deleted, any internal host objects (host objects that are subdomains of the deleted domain) are also deleted. In this case, any domains referencing the deleted host object as a nameserver will have their nameserver information updated and the reference to the host object removed. [Restrictions on Host Objects] The following EPP status codes can be set for host objects as needed to restrict operations: - serverDeleteProhibited - serverUpdateProhibited - clientDeleteProhibited - clientUpdateProhibited [Reflection in DNS] The IP address set for a host object is reflected in the DNS only when the domain name referencing the host object is the parent domain of the host object.

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 service does not handle contact information.

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.

Deposit files are sent to the escrow agent according to the following process, which is performed for each TLD: 1. Extract IDN information from the SRS database. 2. Extract domain name information from the SRS database. 3. Extract name server host information from the SRS database. 4. Extract registrar information from the SRS database. 5. Extract nndn (reserved names) information from the SRS database. 6. Combine the information gathered in steps 1 through 5 to create an XML file in the format defined in RFC 8909. 7. Verify that the file created in step 6 is in the correct format. 8. Convert the created file to a tar file. 9. Use a symmetric key and encrypt the tar file created in step 8 using OpenPGP. The symmetric key cryptography algorithm is AES128. 10. Encrypt the symmetric key used in step 9 with the escrow agent's public key. The public key encryption algorithm is RSA. 11. Split encrypted files as needed to make the file size reasonable. 12. Use the JPRS private key to digitally sign all encrypted files that have been split. The digital signature algorithm used is DSA. All encrypted files and digital signatures are made into deposit files. 13. Use SFTP to send the deposit files to the escrow agent. 14. Submit an escrow report to ICANN. The naming conventions for the deposit files to be created are as specified in Specification 2 of the ICANN Registry Agreement (2024 version). The schedule for deposits is as follows: Full deposit: Every Sunday after 00:00:00 (UTC), as created. Incremental deposit: Every day, Monday through Saturday, after 00:00:00 (UTC), as created.

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

There has been no suspension of the RSP function or gTLD domain name services in the last six months.