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 rollovers (coordination) Answer: As MAIN RSP, our core role for the typical customer engagement consists in coordinating DS record changes between the DNSSEC RSP and IANA following RFC 6781 (DNSSEC Operational Practices, Version 2). For routine rollovers: DNSSEC RSP notifies us of planned rollover, we validate and log the request, communicate the rollover window to stakeholders, submit the new DS to IANA using established processes, monitor for DS publication, coordinate removal of old DS after TTL expiration, and confirm completion. For emergency rollovers (key compromise or operational failure): each DNSSEC RSP has pre-arranged secure communication mechanisms with us for transferring authenticated public DS records; the DNSSEC RSP activates their emergency KSK and securely transmits the new DS material to us—we require no private key material, only authenticated public records to submit to IANA; we invoke expedited IANA coordination, submit the emergency DS, confirm publication, notify registry operators, and coordinate follow-up planned rollover to restore standard cadence. All coordination uses authenticated communication channels with cryptographic audit trails. TRS will also work with clients to address additional specific requirements they might have.

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

TRS SRS supports the following IANA-registered EPP extensions: urn:ietf:params:xml:ns:secDNS-1.1 (RFC 5910), urn:ietf:params:xml:ns:idn-1.0, urn:ietf:params:xml:ns:rgp-1.0 (RFC 3915), urn:ietf:params:xml:ns:launch-1.0 (RFC 8334), and urn:ietf:params:xml:ns:fee-1.0 (RFC 8748). All extensions deployed are verified against the IANA EPP Extension Registry at https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml prior to production use. TRS configures EPP extensions per registry policy and only activates extensions that meet both IANA registration requirements and client operational needs.

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.

TRS SRS implements RDAP extensions in compliance with the February 2024 gTLD RDAP Profile specification. We support the following extensions: icann_rdap_technical_implementation_guide_1 (ICANN gTLD RDAP Technical Implementation Guide version 1 per the February 2024 profile), icann_rdap_response_profile_1 (February 2024 gTLD RDAP Response Profile version 1), and redacted (RFC 9537 for contact information redaction as required by the profile). TRS maintains active monitoring of ICANN specification updates and implements changes to remain compliant with current requirements. Our RDAP implementation is updated in coordination with registry change management procedures to ensure continuity of service during transitions to new profile versions.

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.

TRS implements comprehensive EPP and RDAP status mappings per RFC 8056, with specific application to abuse mitigation workflows. All EPP statuses have corresponding RDAP equivalents. Abusive Registrations: Domains identified as abusive typically receive restrictive statuses to prevent further harm while investigations proceed or enforcement actions are taken. Common abuse mitigation statuses include: EPP serverHold/clientHold (RDAP server hold/client hold) preventing DNS resolution entirely; EPP serverUpdateProhibited (RDAP server update prohibited) preventing modifications to registration data; EPP serverTransferProhibited (RDAP server transfer prohibited) preventing transfers away from current registrar; EPP serverDeleteProhibited (RDAP server delete prohibited) preventing deletion during investigations. Multiple statuses may be applied simultaneously to comprehensively restrict abusive domains. Registry operators or registrars apply these statuses upon receiving abuse reports, court orders, or pursuant to registry policies. Non-Abusive Registrations: Normal legitimate registrations remain in EPP ok (RDAP active) state, indicating full operational status with no restrictions. Domains may temporarily enter restrictive states for legitimate business purposes (client-initiated locks, registrar security holds for account verification) but return to ok/active upon resolution. The distinction lies in intent and context: abuse mitigation statuses are applied involuntarily due to policy violations, while legitimate registrations use statuses voluntarily for security or administrative purposes. All status values conform to IANA registries and RFC 8056 specifications. Status changes are logged with timestamps, actor identification, and rationale for audit trails supporting abuse mitigation accountability.

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

TRS implements URS through internal workflow states (ok, locked, suspended) that map to standard EPP statuses for protocol visibility. URS Lock applies serverUpdateProhibited, serverTransferProhibited, and serverDeleteProhibited (mapped to RDAP as server update prohibited, server transfer prohibited, server delete prohibited per RFC 8056), preventing registry changes while maintaining DNS resolution. URS Suspension removes DS records and updates name server delegations to URS provider-specified servers per the specification, preventing all domain changes. Status "ok" (RDAP active) represents normal state or return-to-normal after proceedings favor the registrant. We do not use generic hold statuses for URS actions. All status transitions follow URS procedural timelines and are reversible upon URS determination completion.

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.

TRS SRS natively implements the full Registry Grace Period (RGP) lifecycle as defined in RFC 3915, while remaining flexible to support any additional or alternative lifecycle models that a registry may require. The attached "DomainNameLifecycle" file is a diagram that we use to capture parameters and design the domain lifecycle that will be applied to a specific registry instance. 1. Standard EPP Lifecycle • Create – New domain registration is provisioned. • Renew – Registration period is extended. • Transfer – Registration is moved between registrars following EPP transfer flow. • Delete – Domain is removed from the active zone upon expiration or explicit delete command. The attached RFC-3915 state diagram file is an excerpt that illustrates how TRS SRS manages its statuses to implement the baseline RGP domain lifecycle. 2. Registry Grace Period (RGP) Phases (RFC 3915) • Add Grace Period – Immediately after Create, allowing free cancellations. • Renew Grace Period – Immediately after Renew, allowing free renewal reversals. • Transfer Grace Period – Immediately after Transfer, allowing transfer rejections. • Redemption Grace Period – Follows Delete, during which a domain may be restored (“Pending Restore”). • Pending Delete – After Redemption expires, domain enters a brief non-recoverable purge window before final removal. 3. Autorenew and AutoDelete • Auto-Renew – At expiration, domains may be automatically renewed and billed per policy. • Auto-Delete – Domains that reach end of Pending Delete are purged without manual intervention. 4. URS and Other Suspension Flows • Uniform Rapid Suspension (URS) – Special suspension lifecycle for clear-cut abusive registrations, marking domains as Held and prohibited per policy. • Optional Suspension or Quarantine – Registries may define custom suspension lifecycles for compliance or dispute resolution. 5. Custom or Registry-Specific Lifecycles TRS SRS can be configured to support additional grace periods, client-types of suspensions, phased launches (e.g., Sunrise and Landrush), or other bespoke lifecycles required by national or brand-TLD policies. All such variants plug into the same underlying EPP-state machine and database schema. By building on the standardized RGP model from RFC 3915 and offering a modular grace-period engine alongside fully configurable lifecycle hooks, TRS SRS ensures that every registry’s required domain-name lifecycles can be accurately enforced and transparently audited.

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

Domain registrations progress through well-defined lifecycle states, each reflected in both EPP status values and corresponding RDAP status labels per RFC 8056: Initial Registration: EPP pendingCreate during processing, then ok; RDAP pending create, then active. Normal Operation: EPP ok; RDAP active. Updates: EPP clientUpdateProhibited or serverUpdateProhibited when locked, reverting to ok when released; RDAP client update prohibited or server update prohibited, then active. Transfer: EPP pendingTransfer while in progress, then clientTransferProhibited/serverTransferProhibited if locked, finally ok; RDAP pending transfer, client transfer prohibited/server transfer prohibited, then active. Grace Periods/Redemption (RGP): EPP pendingRenew (renew grace), pendingDelete (after deletion), pendingRestore (redemption), with required prohibitions until restore completes; RDAP pending renew, pending delete, pending restore with corresponding prohibited flags. Expiration/Deletion: EPP pendingDelete during purge, then serverDeleteProhibited until removal; RDAP pending delete, server delete prohibited. Suspension (Abuse/URS): EPP clientHold/serverHold combined with update/transfer/delete prohibitions; RDAP client hold/server hold plus corresponding prohibited flags. Final Removal: Object removed from registry (no EPP status); RDAP returns HTTP 404 not found. All EPP statuses enforce permitted/prohibited operations; RDAP mirrors these in its status array per RFC 8056 ensuring clients see identical lifecycle state via either protocol.

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.

Host (nameserver) objects follow a simplified lifecycle with EPP status values and corresponding RDAP status labels per RFC 8056: Creation and Active Use: EPP ok when created; RDAP active. Updates: EPP clientUpdateProhibited or serverUpdateProhibited when locked, preventing changes until released; RDAP client update prohibited or server update prohibited. Updates propagate to DNS zones on next publish. Deletion: Hosts can only be deleted when not referenced by any active domain. EPP clientDeleteProhibited or serverDeleteProhibited can prevent deletion; RDAP client delete prohibited or server delete prohibited. Transfer Restriction: Host objects are not transferable independently per RFC 5732; they may only transfer as part of their superordinate domain transfer. Throughout all stages, EPP statuses enforce permitted/prohibited operations and RDAP mirrors these in its status array per RFC 8056, ensuring consistent visibility across protocols. Regarding parent domain deletion and orphan hosts: TRS default configuration prevents deletion of domains with subordinate host objects. When a registrar attempts to delete a domain with subordinate hosts, the operation fails with EPP result code 2305 ("Object association prohibits operation") per RFC 5731 § 3.2.2. TRS works with registrars to orderly eliminate any conflicting objects to allow domain deletion. This includes identifying domains using the subordinate hosts as nameservers and facilitating migration to alternative nameservers before host deletion can proceed. This approach prevents orphaned host scenarios and maintains DNS resolution stability for all affected domains. TRS is actively working on safe automated approaches to address this use case supported by a wide risk-based approach. This includes following https://datatracker.ietf.org/doc/rfc9874/

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 objects follow a reference-driven lifecycle with EPP status values and corresponding RDAP status labels per RFC 8056: Creation and Active Use: EPP ok when created and referenced by domains or other objects; RDAP active. Updates and Locks: EPP clientUpdateProhibited or serverUpdateProhibited applied during disputes or investigations, preventing changes until resolved; RDAP client update prohibited or server update prohibited. Transfers Between Registrars: EPP pendingTransfer during transfer process, then ok upon completion; RDAP pending transfer, then active. Additional Protections: EPP clientUpdateProhibited/serverUpdateProhibited, clientDeleteProhibited/serverDeleteProhibited, or clientTransferProhibited/serverTransferProhibited can be applied to prevent specific operations; RDAP client update prohibited/server update prohibited, client delete prohibited/server delete prohibited, or client transfer prohibited/server transfer prohibited. Orphaned Contacts: When a contact is no longer referenced by any domain, host, or other registry object, it enters an orphaned state. Orphaned contacts remain accessible to the sponsoring registrar for potential reuse, facilitating operational efficiency. After a configurable retention period defined by registry policy—with TRS recommending a 30-day baseline—unreferenced contacts are automatically purged from the SRS (Shared Registry System). This approach balances registrar operational needs with database hygiene and privacy considerations per GDPR Article 5(1)(e) and similar data minimization principles. Throughout all stages, EPP statuses enforce permitted and prohibited operations while RDAP mirrors these in its status array per RFC 8056, ensuring consistent visibility across protocols. The RDAP redacted extension (RFC 9537) applies when contact data is suppressed under policy.

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.

To satisfy Specification 2’s escrow requirements, TRS will partner with any ICANN-accredited Data Escrow Agent that supports the Registry Data Escrow (RyDE) format. At the prescribed cadence (at minimum daily), TRS SRS will generate RyDE‐compliant deposit files containing the full registry data set—domains, hosts, contacts, history objects, and billing records—and deliver them via secure channels (SFTP or HTTPS) to the agent. Each deposit includes a manifest and cryptographic checksum to guarantee completeness and integrity. TRS SRS only generates full deposits as we believe this is the most robust option for recovering a failed registry. In addition to the standard RyDE deposits, TRS maintains its own redundant, off-site archives of every escrow file. These archives are stored fully encrypted under FIPS-approved algorithms in geographically separated data centers. Should the primary escrow agent or any archive location become unavailable, we can immediately recover any deposit from our secondary vaults. TRS SRS also supports uploading deposits to multiple DEAs, or multiple stakeholders, to align with environments with more strict risk avoidance criteria. All escrow processes are fully audited and monitored. Automated alerts notify operations and compliance teams if any deposit fails or manifests a checksum mismatch. Periodic restore drills validate that both RyDE deposits and our internal archives can be reconstituted into a working SRS environment within the recovery-time and recovery-point objectives mandated by Specification 2. Continuous review of RyDE standards ensures that TRS remains compatible with any future escrow format enhancements.

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

We provide registry services including RDAP/RDDS, EPP, DNS, DNSSEC, RyDE, BRDA, reporting, and all ancillary services to the following gTLDs. There have been no outages on services under our responsibility during the requested period. TRS does not track failure statistics prior to the engagement of our services so we cannot make representations on recently onboarded registries. * bar * blockbuster * click * cloud * coop * country * creditunion * data * dish * diy * dot * dtv * dvr * feedback * food * forum * gift * hiphop * hiv * juegos * latino * lifestyle * link * living * locker * love * mobile * music * observer * ollo * ott * phone * pid * property * realty * rest * sexy * sling * trust * vana