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 Processes and Procedures I. General Principles of KSK Rollover The primary objectives of a KSK rollover are: * Preventing key compromise; * Adhering to rotation policies (typically every 1–2 years); * Ensuring DNSSEC continuity without validation disruptions. The Double-DS method is utilized to achieve a seamless rollover: * Publishing two DS records (old and new) in the parent zone; * Gradually transitioning to the new KSK while maintaining the trust chain. II. Planned (Non-Emergency) KSK Rollover Procedure Stage 1: Preparation 1. Date Planning: * Select a low-traffic DNS period; * Notify DNSSEC RSP and IANA 4–6 weeks in advance. 2. Generating a New KSK: * Create a key pair (public/private) with a minimum length of 2048 bits (RSA) or 256 bits (ECDSA); * Store the private key in a secure HSM. 3. Updating DNS Server Configuration: * Add the new KSK to the zone; * Ensure both KSKs (old and new) are signed by the ZSK. Stage 2: DS Record Publication (Double-DS) 1. Extracting DS Records: * Generate DS records for the new KSK (using https://st.yandex-team.ru/SHA-1 /SHA-256 algorithms); * Validate correctness via DNSSEC test validators. 2. Submitting DS Records to the Parent Zone: * Send the new DS record as a supplement to the old one to DNSSEC RSP/IANA (via web interface or API); * Specify the validity period for the new DS record. 3. Waiting for Propagation: * Confirm publication from RSP/IANA; * Verify both DS records using `dig +dnssec <domain> DS`. Stage 3: Transition to the New KSK 1. Removing the Old DS Record: * After the TTL of the old DS expires, request removal of the old DS record from RSP/IANA. 2. Validation Testing: * Test DNSSEC validation using `dig +dnssec <domain> A`; * Use online services (DNSViz, Verisign DNSSEC Analyzer); * Ensure validation passes only with the new KSK. 3. Removing the Old KSK from the Zone: * After confirming DS publication, remove the old KSK from zone files; * Update the SOA record (increase the serial number). Stage 4: Documentation * Record rollover dates, keys, and DS records; * Update internal policies and checklists. III. Emergency KSK Rollover (Key Compromise) Stage 1: Immediate Actions 1. Isolating the Compromised Key: * Disable access to the private key; * Block the old KSK on DNS servers. 2. Notification: * Immediately contact DNSSEC RSP and IANA; * Provide evidence of compromise. Stage 2: Accelerated Rollover 1. Generating an Emergency KSK: * Create a new key with enhanced parameters (e.g., 4096-bit RSA); * Sign the zone immediately. 2. Double DS Publication (Accelerated): * Submit the new DS record to RSP/IANA with an «emergency» tag; * Request priority processing. 3. Transition: * Remove the old KSK from the zone immediately after the new DS is published; * Perform real-time validation. Stage 3: Post-Incident Procedures * Conduct a security audit; * Analyze the root causes of the compromise; * Update incident response procedures. This structured approach ensures both planned and emergency KSK rollovers are executed smoothly, maintaining DNSSEC integrity and compliance with industry standards.

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

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

According to https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml we using next EPP extensions: EPP Secure Authorization Information for Transfer RFC9154 urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 DNS Security Extensions Mapping for the EPP RFC5910 urn:ietf:params:xml:ns:secDNS-1.1 Launch Phase Mapping for the EPP RFC8334 urn:ietf:params:xml:ns:launch-1.0 Domain Registry Grace Period Mapping for the EPP RFC3915 urn:ietf:params:xml:ns:rgp-1.0

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 does not implement RFC 8521 in our RDAP server.

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 - Our infrastructure is designed to be adaptable to future standards. We do not currently implement RFC 8521 but will fully support it for any gTLD we operate, should it be required by our clients or market needs.

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.

The following RDAP extensions will be used in compliance with the February 2024 RDAP gTLD Profile: 1. redacted (as required by RFC 9537 for redaction of contact information in RDAP responses) 2. icann_rdap_technical_implementation_guide_1 3. icann_rdap_response_profile_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.

EPP and RDAP Status Values for Domain Name Registrations 1. Status Values Applied to Domains Considered Abusive Registrations (e.g., cybersquatting, phishing, spam) * clientHold (EPP) / "client hold" (RDAP): Applied to domains engaged in malicious activity, resulting in suspension of DNS resolution. * serverHold (EPP) / "server hold" (RDAP): Applied to domains engaged in malicious activity, resulting in suspension of DNS resolution. * clientTransferProhibited (EPP) / "client transfer prohibited" (RDAP): Used to prohibit transfers of domains suspected of abuse, maintaining them under our control until circumstances are clarified. * serverTransferProhibited (EPP) / "server transfer prohibited" (RDAP): Used to prohibit transfers of domains suspected of abuse, maintaining them under our control until circumstances are clarified. * clientUpdateProhibited (EPP) / "client update prohibited" (RDAP): Restricts updates for domains involved in legal disputes or abuse cases, preventing further misuse. * serverUpdateProhibited (EPP) / "server update prohibited" (RDAP): Restricts updates for domains involved in legal disputes or abuse cases, preventing further misuse. 2. Status Values Applied to Domains Not Considered Abusive Registrations * ok (EPP) / active (RDAP): Domain functions without restrictions. * pendingTransfer (EPP) / "pending transfer" (RDAP): Indicates an ongoing transfer process between registrars. * clientHold (EPP) / "client hold" (RDAP): *Client-initiated* suspension of domain service without deleting registration data. * clientTransferProhibited (EPP) / "client transfer prohibited" (RDAP): *Client-initiated* prohibition on domain transfers. * clientUpdateProhibited (EPP) / "client update prohibited" (RDAP): *Client-initiated* restriction on updating domain data. * clientDeleteProhibited (EPP) / "client delete prohibited" (RDAP): *Client-initiated* prohibition on domain deletion. * clientRenewProhibited (EPP) / "client renew prohibited" (RDAP): *Client-initiated* prohibition on domain renewal. * redemptionPeriod (EPP) / "redemption period" (RDAP): Represents a grace period after domain expiration, allowing the owner to recover the domain. * addPeriod (EPP) / "add period" (RDAP): Represents a grace period after the initial registration of the object, allowing to get the cost of registration if the object will be deleted in this period. * autoRenewPeriod (EPP) / "auto renew period" (RDAP): Represents a grace period after an object registration period is expired and is renewed automatically by the server. * renewPeriod (EPP) / "renew period" (RDAP): Represents a grace period after an object registration period is explicitly extended (renewed) by the client. * transferPeriod (EPP) / "transfer period" (RDAP): Represents a grace period after the successful transfer of object registration sponsorship from one client to another client. Key Distinction The same status (e.g., "clientHold"/"client hold") may appear in both sections but with different context and initiation: * For abusive domains : Statuses are enforcement actions taken by the registrar/registry. * For non-abusive domains : Statuses reflect either operational states (`active`, `pendingTransfer`, `redemptionPeriod`) or voluntary client restrictions (all `clientXXXProhibited` status)

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

EPP and RDAP Status Values for Uniform Rapid Suspension (URS) {#epp-and-rdap-status-values-for-uniform-rapid-suspension-urs} EPP Statuses {#epp-statuses} 1. serverHold : Suspends DNS resolution immediately upon URS ruling 2. serverUpdateProhibited : Prevents WHOIS/nameserver modifications during proceedings 3. serverDeleteProhibited : Blocks domain deletion during suspension period 4. serverTransferProhibited : Locks transfers between registrars RDAP Statuses {#rdap-statuses} 1. suspended : Publicly indicates DNS suspension (mirrors serverHold) 2. server transfer prohibited : Reflects transfer lock (mirrors serverTransferProhibited) 3. server update prohibited : Shows update restrictions (mirrors serverUpdateProhibited) 4. pending delete : Signals post-suspension deletion if required #### URS Workflow {#urs-workflow} * Enforcement : Apply EPP serverHold \+ prohibitive statuses upon ruling; set corresponding RDAP statuses * Compliance : Maintain statuses for mandatory suspension period (typically 30 days) * Resolution : Delete domain (via pending delete) for non-compliance Compliant with RFC 3915 (EPP) and RFC 9082 (RDAP). URS statuses override standard lifecycle to enforce ICANN trademark protections.

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.

Domain Registration Lifecycle Our system supports the following domain name lifecycle stages and transitions, fully compliant with ICANN requirements and engineered for EPP/DNS/RDAP interoperability: Core Lifecycle Statuses: 1. Available * Initial unregistered state in the registry's available domain pool * No DNS zone association or records exist 2. Creating * Activated upon new domain request via internal ticketing system * Technical and legal framework negotiation phase 3. Created * Domain provisioned through EPP protocol * Synchronized to RDAP and DNS infrastructure * Visible in DNS with full functionality: • Subdomain configuration • MX/record management • Immediate operational readiness 4. Want delete? (Deletion Confirmation) * Requires administrator decision upon deletion initiation * Branching paths: • Confirmation → Proceeds to Deleting • Cancellation → Returns to Created status 5. Deleting * Executes post-confirmation cleanup: • DNS record purge • Removal from zone file • Registration data revocation 6. Deleted * Terminal state: • Excluded from zone file • All resources released * Eligible for recycling per registry policy 7. Release * Automated return to Available pool after deletion Primary Lifecycle Flows: * Standard Reuse Cycle: Available → Creating → Created → Want delete? → Deleting → Deleted → Release → Available * Deletion Abort: Available → Creating → Created → Want delete? → Created (domain remains operational) Auxiliary Scenarios: a) Domain Transfer: 1. Auth Code generation by current registrar 2. Transfer initiation by gaining registrar 3. Owner confirmation 4. EPP-compliant transfer execution (expiration date preserved) b) Domain Lock/Hold States: * clientHold: Owner-initiated lock (modifications/transfers prohibited) * serverHold: Registrar/ICANN-mandated lock (e.g., UDRP disputes; all operations suspended) c) Pending States: * pendingTransfer: Transfer completion pending * pendingDelete: Post-grace period deletion queue * pendingRestore: Restoration process active Technical Compliance: • EPP transitions: RFC 5730-5734 compliant • RDAP synchronization: RFC 7480-7484 implemented • DNS propagation: Zone updates within 5 minutes via Anycast • This structured lifecycle ensures policy adherence while maintaining operational flexibility for registrants and administrators.

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

Domain Registration Lifecycle: EPP and RDAP Status Values The domain registration lifecycle in our system aligns with ICANN standards and integrates EPP/RDAP status values as follows: 1. Registration (Domain Creation) - Actions : * User submits registration request via internal ticketing system * Registry operators initialize creation via EPP protocol * System verifies availability and creates domain - EPP Statuses : * `pendingCreate`: Domain synchronization across systems (RDAP/DNS) in progress * `ok`: Domain successfully registered and active - RDAP Statuses : * `pending create`: Registration processing * `active`: Domain operational and available 2. Active Operation (Domain Usage) - Actions : * Domain used for intended purposes * Owner manages contact info, NS records, subdomains * Domain renewal initiated when required - EPP Statuses : * `ok`: Standard active status * `clientUpdateProhibited`: Updates blocked by owner (security) * `clientTransferProhibited`: Transfers blocked by owner - RDAP Statuses : * `active`: Functional status * `update prohibited`: Modifications restricted * `transfer prohibited`: Transfers restricted 3. Suspension (Hold States) - Actions : * DNS resolution suspended * Domain operations restricted (initiated by owner or registry) - EPP Statuses : * `clientHold`: Owner-initiated suspension (e.g., legal disputes) * `serverHold`: Registry-initiated suspension (policy violations) * `clientRenewProhibited`: Renewal blocked - RDAP Statuses : * `client hold`: Owner-requested hold * `server hold`: Registry-enforced hold * `renew prohibited`: Renewal restricted 4. Renewal - Actions : * Owner extends registration period pre-expiration via EPP - EPP Statuses : * `pendingRenew`: Renewal processing * `ok`: Successful renewal - RDAP Statuses : * `pending renew`: Renewal in progress * `active`: Post-renewal operational status 5. Expiration (Not Currently Applied) - Actions : * Registration period ends → Enters grace period - EPP Statuses : * `expired`: Registration lapsed * `redemptionPeriod`: Recovery window active - RDAP Statuses : * `expired`: Domain expired * `redemption period`: Restorable status #### 6. Deletion - Actions : * Registrar initiates deletion via EPP - EPP Statuses : * `pendingDelete`: Deletion queued (reversible state) * `deleted`: Removed from registry - RDAP Statuses : * `pendingDelete`: Deletion processing * `deleted`: Removal confirmed 7. Release & Reuse - Actions : * Deleted domain returns to available pool - RDAP Status : * `available`: Ready for new registration 8. Transfer - Actions : * Auth code generation → Transfer initiation → Owner confirmation * EPP-compliant migration between registrars - EPP Statuses : * `pendingTransfer`: Transfer processing * `transferred`: Migration complete - RDAP Statuses : * `pending transfer`: Transfer pending * `transferred`: Successfully migrated

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 Host Lifecycle: EPP and RDAP Status Values in Relation to Domain Names The lifecycle of a nameserver is integral to domain name management and involves several key stages, each with corresponding EPP and RDAP status values. Here’s a detailed description: #### **I. Registration** * **Actions:** * Nameservers are added to the DNS zone. * Uniqueness and validity of names are verified (RFC 5730 and RFC 5732 compliance). * Corresponding DNS records (A, AAAA, NS) are created. * **EPP/RDAP Status:** * `ok`: If nameservers are not associated with a domain, they are marked as operational but unlinked. #### **II. Activation** * **Actions:** * Nameserver names become visible in DNS and start processing queries. * Domains pointing to these nameservers begin resolving correctly. * **EPP/RDAP Status:** * `ok, linked`: Indicates that nameservers are active and associated with at least one domain. #### **III. Maintenance and Updates** * **Actions:** * Regular checks for server functionality. * IP address updates when infrastructure changes occur. * Status adjustments via EPP (e.g., setting update restrictions). * **EPP Statuses for Restrictions:** * `clientUpdateProhibited`, `serverUpdateProhibited`: Limit changes to nameserver details. * `clientDeleteProhibited`, `serverDeleteProhibited`: Prevent nameserver deletion. #### **IV. Deactivation/Deletion** * **Actions:** * EPP status is updated (e.g., `clientHold`, `serverHold` to temporarily restrict operations). * NS records are removed from the DNS zone. * Nameservers are disabled. * Domains using these nameservers become unresolvable until NS records are updated. * **RDAP Status:** * `deleted`: Indicates removal of nameserver records. ### **Relation to Domain Name Lifecycle** The nameserver lifecycle is tightly coupled with domain registration stages: * **Domain Creation:** Nameservers are specified during domain creation. The domain remains non-functional until valid NS records are configured. * **Infrastructure Changes:** NS records are updated to reflect new nameservers. * **Domain Suspension:** Nameservers remain active, but the domain’s EPP status changes (e.g., `clientHold`), preventing resolution. * **Domain Deletion:** The domain’s NS records are removed, but nameservers persist if used by other domains. ### **EPP and RDAP Status Significance for Nameservers** **EPP Statuses:** * `ok`: Nameservers are active and processing DNS queries. * `linked`: At least one domain is using the nameserver. * `clientDeleteProhibited`/`serverDeleteProhibited`: Deletion restrictions imposed by the client or registry. * `clientUpdateProhibited`/`serverUpdateProhibited`: Update restrictions on nameserver details. **RDAP Statuses:** * `active`: Nameservers are operational, and domains resolve correctly. * `pending delete`: Domain deletion is pending, but nameservers remain active. * `client delete prohibited`: Client-imposed deletion block (prevents NS record changes). * `client update prohibited`: Client-imposed modification block (prevents updates). This structured approach ensures consistent DNS management, aligning nameserver operations with domain lifecycle events while maintaining compliance with ICANN standards and technical protocols.

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.

Contact Lifecycle and Status Values The contact lifecycle is closely integrated with domain and nameserver management, ensuring compliance with EPP and RDAP standards. Below is a detailed description of the contact lifecycle, including status values and orphaned contact management. 1. Contact Lifecycle Stages Stage 1: Creation - Initiation: contact is created during domain registration or via the EPP `<contact:create>` command. - Validation: mandatory fields (email, phone, address) are checked for validity. - Identification: a unique contact ID is assigned. - Statuses: *EPP: `ok` *RDAP: `active` Stage 2: Active Usage - Association: the contact is linked to domains. - Multi-Domain Linking: a single contact can be associated with multiple domains. - Update Capability: modifications can be made via EPP `<contact:update>`. - Statuses: *EPP: `ok, linked` *RDAP: `active` Stage 3: Update - Modification: contact data can be changed via EPP commands. - Change History: all updates are logged. - Statuses remain: *EPP: `ok, linked` *RDAP: `active` Stage 4: Deletion - Triggers for Deletion: - User request to delete the contact. - Contact becomes orphaned (not linked to any active domains). - Expiration based on registry retention policies. - Statuses during deletion: *EPP: `pendingDelete` *RDAP: `pendingDelete` 2. Relationship with Domain Lifecycle - Mandatory Linkage: each domain must have at least one registrant contact. - Domain Contact Updates: changes are managed via EPP `<domain:update>`. - Deletion Scenarios for Contact Linked to a Domain: *Deletion may be prohibited if the contact is critical. *Replacement with a default/backup contact. *Domain suspension initiation. 3. Orphaned Contact (Orphaned Contacts) Deletion Process An orphaned contact is defined as: - Not linked to any active domains. - Not updated for an extended period. Deletion Procedure: 1. Detection: - Regular database scans identify contacts without domain links and with last update dates exceeding the threshold. 2. Notification: - The contact owner receives a 30-day warning email. - Reason: «The contact is not associated with any active domains». - Instructions for reactivation (e.g., linking to a domain) are provided. 3. Grace Period: - 30-day window for user response. - Deletion is canceled if the contact is reactivated (updated or linked to a domain). 4. Marking for Deletion: - Contact status is set to `pendingDelete` (EPP/RDAP). - The contact becomes ineligible for new domain linkages. 5. Final Deletion: - Contact is removed from the database. - Associated records (history, logs) are archived per registry policy. The contact ID becomes available for reuse. 4. EPP and RDAP Status Reflection EPP Statuses: - `ok`: contact is active and in use. - `pendingDelete`: marked for deletion (including orphaned contacts). - `pendingTransfer`: in transfer state. - `deleted`: permanently removed (recorded in logs). - `clientDeleteProhibited`/`serverDeleteProhibited`: deletion restrictions imposed by the client or registry. - `clientUpdateProhibited`/`serverUpdateProhibited`: update restrictions imposed by the client or registry. RDAP Statuses: - `active`: contact is operational. - `pending delete`: deletion is pending. - `pending transfer`: in transfer state. - `client/server delete prohibited`: deletion is restricted. - `client/server update prohibited`: updates are restricted.

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.

Data Escrow Processes to Meet ICANN Registry Agreement (Version 2024) Standards The RSP will ensure compliance with Specification 2 of the ICANN Registry Agreement through a robust data escrow framework designed to protect registry data integrity and availability. The following describes the escrow processes, including extensions for additional registry services. 1. Core Data Escrow Processes A. Key Principles * Objective: to guarantee registry recovery in case of RSP bankruptcy, security breach, or operational cessation. * Escrow Agent: an independent, accredited third-party provider. * Deposition Frequency: weekly (daily for critical data). B. Data Included in Escrow Core Registry Data: * Domain records (names, statuses, dates). * Contacts (registrant, admin, tech, billing). * NS servers and DNSSEC ZSK/KSK keys. * Transaction history for the period. Additional Services Data: * WHOIS/RDAP data. * Audit logs. * DNS zone configurations. C. Escrow Process Steps 1. Data Collection: automated export from databases and DNS servers. 2. Encryption: data is encrypted with the escrow agent’s keys before transmission. 3. Transfer: secure channels are used (SFTP, TLS-protected API). 4. Confirmation: the escrow agent issues a receipt certificate upon data acceptance. 5. Storage: encrypted data is stored in geographically distributed repositories. 2. Escrow Extensions for Additional Registry Services For services beyond basic domain registration, the RSP implements enhanced escrow processes: A. RDAP Services Data Deposited: * Full RDAP responses (with personal data masking). * Historical record versions. B. DNS Services Data Deposited: * Zone configurations (including DNSSEC settings). This comprehensive approach ensures that all critical registry data and service-related information is securely stored and recoverable, meeting ICANN’s stringent requirements for data protection and availability. The use of an independent escrow agent, combined with frequent data updates and secure transmission methods, provides a reliable safeguard against potential disruptions or failures.

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

Not applicable, this is our first TLD certification. We currently do not provide services to any TLD.