Evaluating Registry Service Level Agreements for 2026

As the 2026 round of ICANN’s New gTLD Program prepares to open, applicants must be ready to demonstrate not only the technical robustness of their registry services, but also their ability to meet or exceed the Service Level Agreements (SLAs) defined by ICANN. These SLAs form a foundational component of the Registry Agreement and outline mandatory operational benchmarks that ensure the reliability, performance, and responsiveness of registry systems. Evaluating and preparing to comply with these SLAs is critical not only for passing ICANN’s technical evaluation, but also for ensuring long-term operational success, trust among registrars and registrants, and alignment with global DNS stability goals.

The registry SLAs are designed to safeguard the Domain Name System by requiring minimum uptime and responsiveness levels for core registry functions. These include DNS resolution, RDDS (Registration Data Directory Services), EPP (Extensible Provisioning Protocol) interfaces, and DNSSEC signing infrastructure. In the 2026 round, ICANN has introduced updated SLA thresholds and enhanced monitoring protocols, reflecting both the technological advancements and the increased expectations placed on registry operators. Applicants must be aware that these updated benchmarks are stricter than in the 2012 round, and the margin for error is narrower.

For DNS service availability, the SLA typically requires a minimum of 99.999% uptime, with a maximum tolerable downtime of approximately five minutes per year. This target is critical, as DNS availability underpins the functionality of all domain-related services and directly impacts end-user access to websites, email systems, and APIs. To meet this SLA, registry operators must implement highly redundant, geographically distributed DNS infrastructure, leveraging Anycast routing and multiple Tier 1 DNS providers. ICANN expects applicants to detail their architecture, failover procedures, and real-time monitoring systems capable of detecting and mitigating DNS outages within seconds.

The RDDS SLA focuses on the availability and response time of WHOIS and RDAP services, with minimum uptime thresholds of 98% and query response time limits typically under 1,500 milliseconds. These systems must support high-volume query loads while also meeting data protection obligations under regulations such as the GDPR. Registry operators must not only ensure the availability and performance of RDDS but also the correctness and security of the data served. With the increasing importance of access-controlled RDAP, applicants are expected to provide secure authentication methods, audit logs, and access management tools that ensure compliant and equitable data disclosure.

EPP performance is another critical area covered by SLAs. EPP is the protocol through which registrars interact with the registry to register, modify, transfer, and delete domain names. The SLA defines acceptable response times for EPP commands, typically within 500 milliseconds, and mandates availability of 98% or higher. For a registry to meet these expectations, it must deploy load-balanced, redundant EPP servers, robust session management, and alerting systems to detect command failures or latency issues. In the 2026 round, ICANN has also included enhanced guidelines for secure EPP extensions and session encryption to reduce risk from man-in-the-middle attacks or unauthorized access.

DNSSEC key signing and zone signing are subject to their own reliability and timing expectations. DNSSEC is essential for ensuring that DNS responses are not tampered with and that users reach legitimate domain destinations. The SLA requires regular signing of the zone file and timely propagation of key rollovers. Applicants must detail their DNSSEC implementation, including hardware security module (HSM) use, key management policies, rollover procedures, and compliance with RFC 6781 and other relevant standards. Inconsistent or delayed DNSSEC rollouts can undermine trust in a TLD and may result in penalties under the Registry Agreement.

To support compliance with these SLAs, ICANN uses a combination of self-reporting, third-party monitoring, and automated probes deployed from global vantage points. Registry operators must integrate their infrastructure with ICANN’s monitoring systems and may be required to deploy service beacons, provide API access to performance data, and submit regular compliance reports. Applicants in 2026 must demonstrate readiness for this level of operational transparency and must have internal staff or third-party support capable of responding to incidents, audits, or compliance inquiries within defined response time windows.

One of the major changes in 2026 is the requirement for enhanced incident response capabilities. Registry operators must document their incident detection, escalation, and mitigation workflows. This includes 24/7 NOC (Network Operations Center) availability, root cause analysis protocols, and service restoration procedures. ICANN has also mandated the inclusion of communication plans for registrar and registrant notification in the event of SLA breaches or security events. Applicants will need to provide evidence of testing these plans through tabletop exercises or simulations, and in some cases, submit postmortem reports for review following actual events.

Resilience planning has also become a key evaluation factor. ICANN now requires applicants to submit detailed business continuity and disaster recovery plans that describe how the registry will maintain SLA compliance in the event of regional outages, cyberattacks, or catastrophic failures. These plans must include alternative data centers, automated failover capabilities, periodic data integrity checks, and regular restoration testing. The frequency and scope of these tests must be documented and aligned with best practices from the NIST Cybersecurity Framework or ISO 22301.

In cases where a registry operator outsources core services to a backend provider, the applicant remains responsible for SLA compliance. This means applicants must secure binding service level agreements with their backend providers that mirror or exceed ICANN’s required SLAs. These agreements must include service credits, termination clauses, and dispute resolution mechanisms in case of non-performance. ICANN evaluators will review these contracts to verify that the applicant has sufficient leverage and operational visibility to ensure sustained compliance.

Applicants must also account for the user experience of registrars and registrants. Poor SLA compliance can lead to reputational damage, loss of registrar partnerships, and even formal complaints. In competitive or niche TLD markets, a track record of reliable registry performance can serve as a critical differentiator. Therefore, forward-looking applicants are incorporating user-centric SLAs that go beyond ICANN’s baseline, offering premium support tiers, faster response times, and proactive monitoring for high-value registrants or mission-critical domains.

The evaluation of registry SLAs in the 2026 round reflects ICANN’s broader commitment to a secure, stable, and trustworthy DNS. These agreements are not just contractual formalities—they are operational guarantees that underpin the functionality and resilience of the internet. For applicants, preparing to meet these SLAs involves rigorous technical design, disciplined operational management, and a culture of accountability. By demonstrating the ability to uphold these commitments, applicants not only improve their chances of successful delegation but also build a foundation for long-term credibility and success in the evolving gTLD marketplace.

You said:

As the 2026 round of ICANN’s New gTLD Program prepares to open, applicants must be ready to demonstrate not only the technical robustness of their registry services, but also their ability to meet or exceed the Service Level Agreements (SLAs) defined by ICANN. These SLAs form a foundational component of the Registry Agreement and outline…