ICANN Next Round is the next planned application round for new generic top-level domains. It is the policy and application process through which eligible parties can seek delegation of new gTLDs, including dotBrand strings, under the current new gTLD programme rules.
What this round is for
ICANN Next Round is the policy window for introducing new generic top-level domains, so the core issue is not technical DNS operation but the rules, eligibility, and evaluation process that determine who can apply and what kinds of strings may proceed. It matters because the round shapes market entry, namespace expansion, and the governance conditions under which new gTLDs are delegated.
How the application process works
The round functions as a controlled application programme rather than an open registration event. Applicants generally need to demonstrate that the proposed string is permissible, the proposed use is supportable, and the application can survive the evaluation, objection, and contention steps that protect the stability and integrity of the DNS.
In practice, this means the round is designed to filter out strings that would create confusion, conflict with existing rights, or introduce unnecessary operational risk. The process is policy-heavy because delegation at the top level can affect users, registries, registrars, trademark interests, and the broader DNS ecosystem.
Why new gTLD rounds are closely governed
New gTLD expansion changes the namespace in a way that can have long-lived operational and policy effects. ICANN therefore uses a round-based model to coordinate applications, evaluate competing interests, and manage delegation in a way that is predictable for both applicants and the Internet community.
This governance approach also reflects the fact that top-level labels are scarce, highly visible, and commercially valuable. A round process helps create procedural fairness, gives stakeholders a defined opportunity to participate, and reduces the chance that namespace changes are driven by ad hoc decisions.
What applicants and observers should pay attention to
For applicants, the important point is that the round is policy-driven, not simply a request to “buy” a domain extension. Success depends on string choice, application quality, policy compliance, and the ability to respond to objections or competing applications. For observers, the round is one of the main ways ICANN balances expansion with stability.
Because the next round operates under current programme rules, the practical question is usually whether a proposed string fits the eligibility and evaluation framework rather than whether the idea is technically possible. That distinction is what makes the round a governance mechanism as much as a naming mechanism.
Why the round matters for DNS stability and trust
ICANN uses the round structure to limit uncontrolled expansion and to keep delegation decisions tied to documented procedures. That helps preserve trust in the naming system by making expansion reviewable, contestable, and tied to established criteria rather than informal discretion.
The result is a controlled path for namespace growth: one that can support innovation, including dotBrand ambitions, while still giving ICANN a way to assess operational readiness, policy compliance, and community impact before delegation occurs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | ICANN round governance depends on policy context and stakeholder-defined namespace objectives. |
| GV.RM-01 — Risk Management Strategy | The round balances expansion goals against DNS stability and conflict risk. | |
| GV.PO-01 — Policy for Managing Cybersecurity Risk | The next round is controlled by formal programme rules and evaluation policy. | |
| Recommendation — Document the namespace governance context before launching a new gTLD application. Assess round participation against explicit risk appetite and delegation criteria. Apply written policy controls to manage delegation and evaluation decisions consistently. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Applicants must satisfy policy and contractual requirements that shape the application process. |
| A.5.8 — Information security in project management | A gTLD application is a governed programme with coordinated legal, technical and operational work. | |
| Recommendation — Map application obligations to the governing policy and contract requirements. Build security and compliance checks into the application programme from the start. | ||
Practitioner Guidance
Governance implication: Treat the next round as a policy programme with deadlines, evaluation criteria, and dispute steps, not as a simple domain purchase workflow. Applicants should align legal, registry, technical, and branding work early because failure often comes from incomplete policy preparation rather than from technical incapability.
What to watch for: The most important signals are string eligibility, contention risk, objection exposure, and whether the intended use can be supported consistently across the application lifecycle. Those factors usually determine whether a proposal advances cleanly or becomes costly to defend.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org