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.

Non-Emergency (Planned) Rollover: During onboarding, we instruct the DNSSEC RSP with our DNSSEC policy. The DNSSEC RSP will perform the KSK rollover according to our policy. The tasks by the DNSSEC RSP includes key generation, key management, signing and updates to the trust anchor in the root zone management (RZM). The updates to the RZM will be done either directly by the DNSSEC RSP or buy us. In either case, the update requires approval after verification of the requested changes. The DNSSEC RSP is tested by ICANN and is trusted to perform key rollovers in the proper way. Additionally, the DNSSEC RSP will rollover the keys on our request for whatever reason. Emergency Rollover: Triggered by a known or suspected key compromise, this process follows the same fundamental steps as a planned rollover but on a highly compressed timeline. We activate 24/7 emergency communication channels with our DNSSEC RSP and IANA and request priority handling for root zone updates. Practice and Readiness: To ensure success, we maintain operational playbooks for both scenarios and ensure our staff is fully prepared for both planned and emergency events.

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

RFC 8334 - https://tools.ietf.org/html/rfc8334 : Launch Extension RFC 8495 - https://tools.ietf.org/html/rfc8495 : Allocation Token Extension RFC 8748 - https://tools.ietf.org/html/rfc8748 : Fee Extension RFC 8807 - https://tools.ietf.org/html/rfc8807 : Login Security Extension RFC 9154 - https://tools.ietf.org/html/rfc9154 : Secure Authorization Information for Transfer RFC 3915 - https://tools.ietf.org/html/rfc3915 : Domain Registry Grace Period Mapping RFC 5910 - https://tools.ietf.org/html/rfc5910 : Domain Name System (DNS) Security Extensions Mapping

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.

Here is the list of RDAP extensions implemented by us: icann_rdap_response_profile_1 - https://www.icann.org/en/system/files/files/rdap-response-profile-21feb24-en.pdf icann_rdap_technical_implementation_guide_1 - https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-21feb24-en.pdf rdap_objectTag - https://www.iana.org/go/rfc8521 redacted - https://www.iana.org/go/rfc9537

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.

Domains that the registry operator identifies as abusive are assigned a serverHold status (“server hold” in RDAP). In contrast, domains that are not deemed abusive receive an ok status. If a domain has any client or server status, the EPP and RDAP systems will display that status rather than the ok status. Additionally, other server statuses, such as serverUpdateProhibited, in conjunction with serverHold, may indicate a suspension for reasons that are not related to abuse.

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

Upon receiving a valid URS suspension order for a domain name, we will initiate an EPP update to apply specific server-side statuses to the affected domain object. The primary EPP statuses to be employed include: - serverTransferProhibited (RDAP status: server transfer prohibited) - This ensures that the domain remains under the control of the relevant parties during the URS process - serverUpdateProhibited (RDAP status: server update prohibited) - This status prevents any modification of the domain's registration data, including nameserver changes, which could further facilitate abuse or complicate resolution efforts. If a URS decision favors the complainant, the domain remains locked. DNS resolution will point to a page the URS provider designates for the rest of the registration period. At the end of this period, the domain will enter a pendingDelete (RDAP status: pending delete) status before final removal from the registry database. These EPP statuses ensure a domain subject to URS cannot be used, transferred, or modified, aligning with the intent of rapid suspension. If the URS decision is to unlock the domain, the two server statuses will be removed. This will reflect in both EPP and RDAP. Our RDAP service will accurately reflect the EPP statuses applied due to URS actions, ensuring transparency and adherence to the ICANN gTLD RDAP Technical Implementation Guide and RDAP Response Profile.

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.

We only support gTLDs, and their lifecycle is regulated by ICANN. Domains can be registered for a period ranging from 1 to 10 years. Upon registration, a 5-day Add Grace Period (AGP) begins. A domain can never have more than 10 years of registration remaining at any given time. Upon successful renewal, the domain enters a 5-day Renewal Grace Period. When a domain expires, it is automatically renewed, triggering a 45-day Auto-Renew Grace Period. If a domain is deleted by the registrar, two scenarios apply: If the domain is still within the Add Grace Period, it becomes immediately available for registration after deletion. If the domain is outside the Add Grace Period, it enters a 30-day Redemption Grace Period during which it no longer resolves but can be restored by the registrar. If not restored within these 30 days, it moves to a 5-day Pending Delete status, after which it becomes available for registration. Domains that are not in the Redemption Grace Period and are not locked with serverTransferProhibited or clientTransferProhibited statuses can be transferred. A valid transfer request with proper auth info sets the domain to pendingTransfer status. The transfer will be auto-approved within 5 days unless canceled by the gaining registrar or rejected by the losing registrar. If the transfer is completed—either auto-approved or explicitly approved by the losing registrar-the domain is renewed for one year (provided this does not exceed the 10-year maximum) and enters a 5-day Transfer Grace Period. Deletion of a domain during the Add Grace Period, Renewal Grace Period, Auto-Renew Grace Period, or Transfer Grace Period will result in the registrar not being charged for the corresponding transaction. Updated registration lifecycle diagram attached.

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

When a valid domain:create command is received, the domain is registered. The EPP status show "ok" while RDAP shows “active”. The registrar can add any client status at this time. Adding a status will display it instead of "ok." The RGP status will be addPeriod (RDAP: add period) for 5 days, then removed. Deleting the domain during the addPeriod means the registrar is not charged for registration, and the domain becomes instantly available. When a valid domain:renew command is received, the domain renews, and the RGP status changes to renewPeriod(RDAP: 'renew period') for 5 days. Deleting the domain within the renewPeriod means the renewal is not charged to the registrar. When a domain expires, it auto-renews, and the RGP status changes to autoRenewPeriod (RDAP: 'auto renew period'). If a domain is deleted within this period, the registrar will not be charged for the auto-renewal. When a domain:delete command is received outside addPeriod, the RGP status changes to redemptionPeriod (RDAP: 'redemption period') for 30 days and epp status pendingDelete(RDAP: 'pending delete') is added. When a valid domain:update command with an RGP restore request is received, the redemptionPeriod RGP status is removed and epp status pendingDeleteis also removed, and the domain auto-renews if it is past its expiration date. At the end of redemptionPeriod, if no valid restore request is received, the RGP status changes to pendingDelete (RDAP: 'pending delete') for 5 days, after which it becomes available for registration. When a valid domain:transfer request is received, the RGP status changes to pendingTransfer(RDAP: 'pending transfer'). This status remains for 5 days until the transfer completes automatically or a valid domain:transfer approval or rejection is received. If the transfer completes, the new RGP status will be transferPeriod (RDAP: 'transfer period') for 5 days.

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.

We are using host objects. Registrars need to register the host objects prior to using them. After registration, the EPP status will be “ok” (RDAP: “active”) When a host object is associated to a domain via a domain:update, it’s status in EPP will change to ‘linked’ and to ‘associated’ in RDAP. When a domain is placed on EPP status serverHold (RDAP: ‘server hold’) or clientHold (RDAP: ‘client hold’), all it’s child host objects are removed from the zone file as well. Hosts that are not linked and have no updates for more than 60 days are auto-deleted. In order to delete a domain, all it’s child host objects need to be deleted first. If a host object is linked, it cannot be deleted but the registrar can rename it so it wouldn’t be a child of the domain they want to delete.

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.

We implemented our system to support Minimum Data Set. We can configure, per zone, if registrant contact is required or not. The domain admin, tech and billing contacts are not supported all. Collected contact information is: name org email voice addr (supports both internationalized and localized addresses: type='loc' or type='int') street (1 - 3) city sp pc cc When a contact is created it’s EPP status is “ok”. When a contact is linked as registrant to a domain (via domain:create or domain:update), it’s EPP status changes to “linked”. A linked contact cannot be deleted. A contact that is not linked to any domain and has no updates for more than 60 days, will be auto-deleted. If a contact is linked as registrant to a domain, the domain RDAP query discloses just the registrant organization, city and country. Everything else, including status, are redacted. The EPP statuses supported for contact objects are: clientDeleteProhibited, clientUpdateProhibited, serverDeleteProhibited, serverUpdateProhibited. The contact object status is not shown in RDAP

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 will fully comply with all data escrow standards established in Specification 2 of the ICANN Registry Agreement (version 2024). Our process is designed for maximum security, reliability, and business continuity. Data Escrow Agent: We will contract with a reputable, ICANN-approved Data Escrow Agent. To align with GDPR and regional data standards, we will utilize a provider with secure data centers located within the European Union. Scope and Format of Data: Escrow deposits will contain all required Registry Data. Standard Data: All domain, contact, host, and registrar data will be provided in the standard, RFC-compliant format specified by ICANN. Additional Registry Services (ARS) Data: As of now, we do not have any additional registry services but, we will work directly with ICANN to define the necessary "extension schemas" for any additional registry services we might be offering in the future, ensuring all relevant data would be included in our escrow deposits Deposit Schedule and Security: The deposit schedule will be strictly followed, consisting of weekly full deposits and daily incremental deposits. All data files will be PGP-encrypted before being transmitted to the agent via a secure SFTP connection. Verification: We will actively monitor validation reports from the Data Escrow Agent after each deposit to confirm its successful receipt, integrity, and format compliance. Other Data Processes: In addition to the formal ICANN escrow, we maintain a separate, robust disaster recovery plan. This involves performing regular, encrypted backups of all registry data. This process is distinct from escrow and is designed for our own rapid operational recovery in the event of a technical failure.

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

This is a new RSP and we do not provide any services to for any gTLD yet