Understanding IPv6 TLD Requirements from ICANN Contracts

As the internet continues its transition toward IPv6, the foundational infrastructure that supports domain name resolution must evolve to ensure universal reachability and long-term sustainability. At the center of this infrastructure are top-level domains (TLDs), which include generic TLDs like .com and .net as well as country-code TLDs such as .de or .jp. The Internet Corporation for Assigned Names and Numbers (ICANN), which oversees the global domain name system, has built IPv6 considerations into its contracts with TLD operators to promote consistent, forward-compatible deployment practices. Understanding these IPv6-related requirements is critical for registry operators, prospective new gTLD applicants, and technical stakeholders managing DNS infrastructure at the root and TLD levels.

The contractual framework governing TLD operations under ICANN’s remit is primarily the Registry Agreement, which lays out technical and operational obligations for each registry. One of the core components of this agreement is Specification 6, which details the technical requirements for DNS operations, including the mandated support for IPv6. This specification requires that all registry operators must ensure that at least two of their authoritative name servers are reachable over IPv6. This rule not only enforces basic IPv6 capability but also aligns with operational best practices regarding name server diversity and resilience. The IPv6-capable name servers must be listed with valid AAAA records and must be accessible on port 53 over IPv6 transport.

These requirements were not always present in ICANN’s contracting landscape. Earlier registry agreements did not specify IPv6 obligations, which led to a patchwork of support across legacy TLDs. With the introduction of the New gTLD Program and the 2013 Registry Agreement, ICANN standardized expectations for IPv6 readiness. New applicants and existing registries operating under the 2013 contract or its successors are explicitly required to comply with these IPv6 mandates. As a result, every new gTLD since 2013 has been obligated to operate at least part of its DNS infrastructure over IPv6, a policy that has contributed to increasing IPv6 visibility and adoption across the global DNS ecosystem.

Beyond the Registry Agreement itself, compliance with IPv6 requirements is verified through ICANN’s Registry System Testing (RST) process. This testing is mandatory for new gTLDs before they are delegated into the root zone. RST includes a detailed check of DNS service availability, ensuring that at least two name servers respond correctly to queries over IPv6. The testing process simulates resolver behavior, verifies DNSSEC operation (if enabled), and confirms that authoritative responses are consistently reachable and correctly signed over both IPv4 and IPv6. If a registry fails the IPv6 portions of this test, it must remediate the deficiencies before progressing to delegation. This upfront enforcement mechanism ensures that IPv6 support is not merely declarative but operational and measurable.

In addition to the RST, ICANN requires ongoing compliance through the Service Level Agreement (SLA) metrics also described in Specification 10 of the Registry Agreement. These metrics include availability and response time thresholds for DNS services, which apply equally to IPv4 and IPv6 interfaces. For instance, TLD operators must maintain DNS service availability of 98% measured over a trailing 90-day period. Failures on the IPv6 path are counted just as seriously as those over IPv4, which places an operational imperative on registries to monitor and maintain parity across both address families. This ensures that users on IPv6-only or dual-stack networks do not experience degraded service due to poorly maintained DNS infrastructure.

One often overlooked but crucial component of ICANN’s IPv6 policy ecosystem is the role of glue records and delegation data in the root zone. To meet IPv6 requirements, registries must ensure that the root zone contains valid AAAA glue records for their IPv6-enabled name servers. This means that any in-zone name server—for example, ns1.tldname—must have its corresponding AAAA record listed in the root zone alongside its A record. This glue information is essential for enabling resolvers to reach the authoritative servers without additional lookups. Registries must coordinate with IANA during the root zone management process to add or update these IPv6 glue records, and any errors or omissions can lead to service outages or degraded performance for IPv6 users.

Additionally, ICANN’s contracting framework requires registries to publish zone data in a manner that is accessible over IPv6 transport. While zone file access is traditionally offered via FTP or HTTPS, modern practices include publishing data over IPv6-enabled HTTPS endpoints, and in some cases using authenticated RDAP (Registration Data Access Protocol) interfaces. Registry operators must ensure that these services are reachable and perform well over IPv6 to comply not just with the letter of the agreement but also the broader spirit of supporting global IPv6 adoption. Failure to provide consistent IPv6 access to these services can result in compliance issues or hinder third-party data collection efforts, such as zone scans or research by security professionals.

From a policy perspective, ICANN continues to advocate for greater IPv6 integration at the registry and registrar levels through advisory bodies and technical working groups. The Security and Stability Advisory Committee (SSAC) and the Root Server System Advisory Committee (RSSAC) have issued recommendations promoting IPv6 adoption among DNS operators, often citing the need for consistent, high-quality IPv6 service as critical to the long-term health of the DNS. ICANN’s own initiatives, including the ICANN Managed Root Server (IMRS), maintain full IPv6 support and serve as reference implementations for other operators. Additionally, the Technical Study Group on DNS Security, Stability, and Resiliency (DSRS) explores the broader implications of IPv6 deployment across the DNS landscape, including operational dependencies and potential risks.

In conclusion, understanding ICANN’s IPv6 requirements for TLDs is not only about contractual compliance but also about participating in the long-term evolution of internet infrastructure. The inclusion of IPv6 in registry agreements, mandatory testing and SLA enforcement, glue record integrity, and service availability metrics all work together to ensure that TLDs are accessible and resilient in an IPv6-dominant future. For registry operators, this means building dual-stack infrastructure that performs equally well across both protocols, monitoring service health over IPv6, and coordinating precisely with IANA and ICANN during onboarding and operational phases. As IPv6 becomes the norm rather than the exception, these requirements form a cornerstone of modern DNS best practices and a critical benchmark for internet reliability and inclusiveness.

As the internet continues its transition toward IPv6, the foundational infrastructure that supports domain name resolution must evolve to ensure universal reachability and long-term sustainability. At the center of this infrastructure are top-level domains (TLDs), which include generic TLDs like .com and .net as well as country-code TLDs such as .de or .jp. The Internet…