The 86th Public Meeting of the Internet Corporation for Assigned Names and Numbers opened Monday at the FIBES Conference and Exhibition Centre in Seville, Spain, kicking off four days of policy sessions that carry two hard deadlines every DNS operator and domain applicant needs on their calendar: August 12, when the first new generic top-level domain application window in 14 years closes, and October 11, when ICANN will rotate the DNSSEC root Key Signing Key in the most consequential cryptographic update the global domain name system security chain has seen since the last rollover. Fail to meet either deadline and the cost is concrete \u2014 a missed application window means waiting for the next round, while an unprepared recursive resolver will begin returning SERVFAIL errors for every DNSSEC-validated domain it serves.<\/p>\n
The forum, which runs through June 11 in a hybrid format, was opened<\/a> by ICANN President and CEO Kurtis Lindqvist, who described the event as arriving “at a time of growing attention to how the Internet is coordinated and how key technical systems operate across borders.” Spain’s Secretary of State for Digitalization and Artificial Intelligence, Mar\u00eda Gonz\u00e1lez Veracruz, welcomed the gathering as ICANN’s second Public Meeting in Spain \u2014 the first was ICANN63 in Barcelona in 2018.<\/p>\n New gTLD 2026 Application Window Closes August 12<\/p>\n The gTLD application window for the 2026 Round opened April 30 and will close at 23:59 UTC on August 12, 2026<\/a> \u2014 leaving organizations approximately ten weeks as of today. The 2026 Round is the first expansion of the domain namespace since the 2012 program, which ultimately produced more than 1,200 new delegated strings including .app, .shop, .bank, and hundreds of others.<\/p>\n The structural mechanics of applying have changed significantly since 2012. Every applicant must now designate at least one pre-evaluated Registry Service Provider \u2014 an RSP, in ICANN’s terminology \u2014 that will supply the critical backend infrastructure for any TLD they successfully operate. That infrastructure layer covers DNS zone operations, DNSSEC implementation, SLA-compliant uptime guarantees, domain registration data delivered via the Registration Data Access Protocol (RDAP), and security and abuse-response obligations. The RSP Evaluation Program<\/a> separates technical infrastructure assessment from individual domain-label applications, meaning a qualified RSP is evaluated once and can then support multiple gTLD bids across applicants. ICANN published its initial list of cleared RSPs on January 30, 2026 and a second evaluation period running concurrently with the application window opened April 30.<\/p>\n The Governmental Advisory Committee placed the new gTLD program among its primary discussion items for the week. The GAC is expected to weigh in on public interest protections, objection mechanisms, and whether proposed new strings adequately safeguard community interests \u2014 positions that ICANN’s board is formally obligated to consider before evaluating applications. The GAC’s communiqu\u00e9, expected June 11 at the forum’s close, will represent governments’ collective stance entering the final stretch of the application window.<\/p>\n One significant policy change since 2012 bears noting: the ICANN Board decided in January 2024 that “closed generic” TLD applications \u2014 single-registrant domains for generic terms like .search or .music \u2014 will not be permitted in the 2026 round unless an approved framework is first developed to assess their compatibility with the public interest. That decision emerged from a multi-year facilitated dialogue involving the GAC, GNSO, and At-Large Advisory Committee.<\/p>\n How Does the DNSSEC Root Key Rollover Work, and Why Does It Matter?<\/p>\n Every time a user visits a website, their device asks a recursive resolver \u2014 a DNS lookup service operated by their internet service provider, employer, or cloud platform \u2014 to translate a domain name into an IP address. If that resolver performs DNSSEC validation, it also verifies that every DNS response it receives hasn’t been forged or tampered with by an attacker. That verification traces a cryptographic chain of trust that starts at the root of the DNS hierarchy.<\/p>\n The chain works through two interlocking key types at each zone level. The Zone Signing Key (ZSK) signs the actual DNS resource records within a zone \u2014 the A records, MX records, and CNAME records that direct traffic. The Key Signing Key (KSK) signs only the DNSKEY record set, which publishes both public keys for that zone, and its cryptographic fingerprint \u2014 called a Delegation Signer (DS) record \u2014 is stored in the parent zone above it. Validating resolvers hold the root zone’s KSK public key as a hardcoded trust anchor. When a resolver receives a DNS response, it traces signatures upward: the ZSK verifies zone records, the KSK verifies the ZSK’s identity, and the parent zone’s DS record verifies the child KSK’s legitimacy \u2014 all the way up to the root.<\/p>\n The root KSK currently in use \u2014 KSK-2017 \u2014 is being replaced by KSK-2024, a new key pair that ICANN generated in April 2024 and formally published in the root zone on January 11, 2025, according to a Verisign analysis<\/a> by Duane Wessels, a Verisign fellow specializing in DNS security. On October 11, 2026, KSK-2024 will begin signing the root zone. The old key will remain valid during a parallel operation window until January 2027, giving resolver operators time to complete updates before the retirement date.<\/p>\n Operators have two primary paths to compliance. Resolvers running software that supports RFC 5011<\/a> \u2014 the IETF-standardized automated trust anchor update mechanism \u2014 will update their trust anchor stores automatically once the new key has been present in the DNSKEY RRset for at least 30 days. Modern versions of BIND (9.9 and later), Knot Resolver, and Unbound 1.6.2+ all support RFC 5011. Operators running older software, or those who manually configured their trust anchors rather than relying on automated updates, must act directly. According to ICANN’s official announcement<\/a>, failure to update will produce DNS resolution failures after the rollover \u2014 specifically, DNSSEC-validated domains will return SERVFAIL errors for end users served by unready resolvers.<\/p>\n Kim Davies, ICANN’s Vice President for Internet Assigned Numbers Authority Services and President of Public Technical Identifiers, said operators should act now: “While most internet users will not notice any change, operators of DNS software should confirm that their systems are properly configured to trust the new key ahead of the rollover.”<\/p>\n The Verisign analysis found that trust anchor adoption of KSK-2024 had reached near-100% among monitored resolvers, but noted that a small population of manually configured resolvers remains a risk category, since the RFC 5011 automatic update process requires the new key to have been continuously observed for at least 30 days. ICANN’s DNSSEC Security Workshop, one of the week’s highlighted technical sessions at ICANN86, is expected to address rollover readiness, validator adoption rates, and what the community can do to reduce the chance of resolution failures when October arrives.<\/p>\n DNS Abuse, RDAP Access, and Universal Acceptance<\/p>\n Three secondary policy tracks will run through the working sessions in Seville all week.<\/p>\n On DNS abuse, ICANN’s enforcement data illustrates both the progress and the remaining gap. Between April 2024 and August 2025, ICANN Contractual Compliance initiated 400 investigations under the DNS abuse mitigation requirements that took effect in April 2024, resulting in the suspension of 2,528 domain names and the disabling of 328 phishing websites. The GNSO’s newly launched Policy Development Process on DNS Abuse Mitigation is active and meets in Seville \u2014 it is examining whether registrars should face requirements to conduct associated domain checks when one domain in a related cluster is confirmed abusive. A new dimension the forum must also address: AI tools that generate convincing phishing sites at scale, automate registrations across thousands of accounts, and outpace human review cycles. ICANN’s existing framework was designed for abuse operating at human scale, and the gap between that assumption and current reality is on the plenary agenda.<\/p>\n