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.

KSK rollover is carried out every year, as described in section 6.5 of CIRA's DNSSEC Practice Statement for gTLDs. In order to make update to the HSM, We need a HSM ceremony with System Administrator, Security Officer, and Witness present to make the changes. During the HSM ceremony, we have ten years' worth of KSK pre-generated and store and sync with the HSM. Normal KSK rolling process: 1. Backup the OpenDNSSec infrastructure 2. List the existing KSK for the applicable zones 3. Start the KSK roll with OpenDNSSec 4. Wait for the first zone publish to be completed with the new KSK published 5. Submit RZM request on IANA portal to add new KSK 6. Wait for the RZM change to be completed 7. Wait for the new KSK to be ready and using for double signing in OpenDNSSec 8. Submit RZM request on IANA portal to remove old KSK 9. Wait for the RZM change to be completed 10. Backup the OpenDNSSec infrastructure again 11. Complete Switch to new KSK on OpenDNSSec Emergency KSK rolling process: 1. Backup the OpenDNSSec infrastructure 2. List the existing KSK for the applicable zones 3. Reduce the new KSK pre-publish time from 7 days to 24 hours 4. Start the KSK roll with OpenDNSSec 5. Wait for the first zone publish to be completed with the new KSK published 6. Submit RZM request on IANA portal to add new KSK 7. Wait for the RZM change completed 8. Wait for the new KSK to be ready and using for double signing in OpenDNSSec 9. Submit RZM request on IANA portal to remove old KSK 10. Wait for the RZM change to be completed 11. Backup OpenDNSSec infrastructure again 12. Complete switch to new KSK on OpenDNSSec In the event of a compromised KSK, CIRA, acting as the main RSP, will immediately notify IANA to ensure they are aware of the situation and aligned with the emergency KSK rollover process. The DNSSEC RSP will initiate the KSK rollover. If CIRA is the DNSSEC RSP, the emergency rollover steps outlined earlier in this document will be followed. If the DNSSEC RSP is an external party, CIRA will promptly inform the relavent stake holders and collaborate with the DNSSEC RSP to validate the new DS record. CIRA will also work with the registry owner to ensure the updated DS record is correctly published in the Root Zone Management (RZM) system. During an emergency KSK rollover, CIRA has multiple channels available to contact ICANN. To expedite the process, CIRA will first open a support ticket and then follow up with a direct phone call to ensure prompt attention and resolution. Once the new KSK is actively used for signing, and the TTL of all RRSIGs generated with the compromised KSK has expired, CIRA will coordinate with the registry owner to remove the compromised DS record from the root zone. Steps in Scheduled KSK Rollover: Active Phase (365 days) The current KSK is used to sign the zone for one year. This is the normal operational period before rollover begins. Pre-publish Phase (30 days) A new KSK is generated and published in the zone alongside the old key. During this time, the old key still signs the zone, but the new key is visible to resolvers so they can trust it before it starts signing. Purpose: Prevent validation failures by giving resolvers time to update trust anchors. Rollover (Switch) After the pre-publish period, the new KSK starts signing the zone. The old KSK stops signing but remains published for a short time. Post-publish Phase (30 days) The old KSK remains in the zone (not signing) for 30 days. This ensures resolvers that haven’t updated yet can still validate signatures during the transition.

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

CIRA confirms that all EPP extensions used for Registry System Testing (RST) and in support of gTLDs will be registered in the IANA EPP Extension Registry, in accordance with RFC 7451. The following extensions are currently registered and will be used: urn:ietf:params:xml:ns:rgp-1.0 – RFC 3915 urn:ietf:params:xml:ns:secDNS-1.1 – RFC 5910 urn:ietf:params:xml:ns:launch-1.0 – regext-launchphase urn:ietf:params:xml:ns:epp:fee-1.0 – RFC 8748 urn:ietf:params:xml:ns:idn-1.0 – This refers to the “Internationalized Domain Name Mapping for the Extensible Provisioning Protocol (EPP)” extension, which is registered and documented here. CIRA has also submitted registration requests to IANA for the following extensions: urn:ietf:params:xml:ns:fury-2.1 – CIRA Fury 2.1 Extension urn:ietf:params:xml:ns:fury-rgp-1.0 – CIRA Fury RGP Extension These submissions follow the process outlined in RFC 7451 and are currently under review. CIRA will ensure that these extensions are listed in the IANA registry prior to their use in any gTLD operations. We confirm that all EPP extensions used by CIRA for RST and gTLD support will be listed in the IANA EPP Extension Registry.

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.

CIRA uses the following: icann_rdap_response_profile_1 icann_rdap_technical_implementation_guide_1 redacted (only when a response contains redacted information)

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.

Abusive registrations may be policed by the registrar and registry operator by usage of statuses clientHold, serverHold. This will ensure the domain will not be published in the zone. Responses for EPP and RDAP will look something like what is provided in the attached PDF.

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

Answer is more than 4000 characters, uploading a document with all the information.

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 RGP statuses/stages of life (SOL) supported in the system: addPeriod autoRenewPeriod renewPeriod transferPeriod redemptionPeriod pendingRestore pendingDelete registered See Diagram 10.1 for a detailed diagram showing the domain name life cycle.

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

Please see attached tables and images for the CIRA Domain Lifecycle.

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.

Answer is longer than 4000 characters, please see attached document and table for answer

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.

Answer is longer than 4000 characters, please see attached document and table.

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.

We are compliant with Specification 2 of the ICANN Registry Agreement (v2024) concerning the escrow process. See attached table. We are fully compliant with Legal requirements as outlined in PART B.

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

No, We have experienced no service disruptions as defined by Specification 10 of the ICANN Registry Agreement.