ICANN Launches New gTLD Application Round: What It Means and How to Prepare

ICANN has confirmed that a new round for applying for custom generic top-level domains (gTLDs) is coming, and this time the process will be more structured, more policy-heavy, and more competitive than ever. If you have ever thought “it would be powerful to own .brand, .city or .community for our ecosystem”, this is the moment to start preparing. A new gTLD is not just a marketing asset; it is a piece of internet infrastructure that will sit alongside .com and .org and will require serious technical, financial, and governance planning. In this article, we walk through what the new ICANN gTLD application round actually is, who should realistically consider applying, how the policy and technical requirements have changed since the last round, and what kind of hosting, DNS, and server architecture you will need. As the dchost.com team, we will also share the kind of infrastructure patterns we use for high-availability DNS, registry-connected systems, and secure backend services so you can turn a big strategic idea into a stable, predictable TLD operation.

What the New ICANN gTLD Application Round Actually Is

ICANN (the Internet Corporation for Assigned Names and Numbers) coordinates the global Domain Name System. Every few years, it opens an application window where organizations can apply to run their own gTLDs – new extensions like .brand, .city, .shop, or specialized community strings.

The last major new gTLD round was launched in 2012 and resulted in more than a thousand new extensions entering the root zone. Since then, ICANN has spent years refining policies, evaluating what worked and what did not, and negotiating the balance between innovation, security, competition, and end-user protection. The newly announced round is the first large-scale opportunity since that era to apply for your own extension.

When ICANN says “new gTLD application round”, it does not mean simply registering a new domain name. You are applying to become a registry operator – the entity responsible for running an entire namespace, setting policy for who can register names under it, and maintaining the technical services (DNS, registry database, WHOIS/RDAP, and more) that keep it functioning 24/7.

If this sounds like running a small slice of the internet, that is exactly what it is. The reward can be strategic control over your brand or community identity at the DNS root level – but it also comes with obligations and operational complexity that you must be ready for.

Who Should Seriously Consider Applying for a New gTLD?

A new gTLD is not a fit for everyone. In our work with customers on domains, hosting, and infrastructure planning, we usually see a realistic case for a new gTLD in a few specific scenarios:

1. Large or Ambitious Brands (.brand)

Global or fast-scaling brands may want a closed or restricted .brand namespace such as .yourbrand. This can be used to:

• Unify all digital properties under a controlled, trusted extension
• Run short, clean URLs for campaigns (promo.yourbrand, pay.yourbrand)
• Strengthen anti-phishing efforts by clearly separating official domains from lookalikes

Brand TLDs tie directly into long-term domain strategy and defensive registrations. If you are not yet confident in your brand’s domain posture, it is worth reviewing a defensive registration approach first. Our article on defensive domain registration strategy for typosquats, IDNs, and brand TLDs is a good baseline before you start dreaming about your own dot.

2. Sector or Community Registries

Some organizations want to operate a TLD for an entire vertical or community, such as a professional association, an open-source ecosystem, or an industry initiative. These often run under a shared set of rules and eligibility criteria (for example, only members or certified professionals can register).

Here, the registry is a neutral infrastructure provider for many independent registrants. This requires:

• Clear, enforceable registration policies
• An abuse management framework (phishing, malware, spam)
• Technical capacity to run reliable DNS and registry systems for many tenants

3. Cities and Geographic Regions

City and regional TLDs (.city, .region) can concentrate tourism, local businesses, cultural institutions, and citizens into a unified namespace. Municipalities or regional authorities can use them to:

• Standardize official digital addresses for public services and agencies
• Create a recognizable badge of local trust for businesses
• Offer local-language or local-script domains for inclusivity

Geo-TLDs add another layer: cooperation with local stakeholders and sometimes legal requirements around who can apply and how data is processed.

4. Platforms and Ecosystems

Large platforms – think marketplaces, SaaS ecosystems, or app platforms – sometimes want their own TLD to structure third-party participants. Sub-brands, merchants or partners get names under the platform’s TLD and must follow predefined policies.

We often see this idea emerge during architecture or capacity planning sessions for multi-tenant SaaS. If you are already thinking about multi-tenant architectures for SaaS apps and the hosting infrastructure behind them, a dedicated TLD becomes an interesting long-term control point.

5. Who Probably Should Not Apply (Yet)

If you are an individual site owner, a small business with limited IT capacity, or a brand that is still stabilizing its marketing and naming strategy, a gTLD is usually overkill. The costs (both application and ongoing operations) are substantial, and you will need to maintain compliance and technical resilience for years.

In those cases, choosing the right combination of classic domains (.com, ccTLDs, relevant existing new gTLDs) is usually a better fit. Our guide on building a calm domain strategy with ccTLD vs gTLD and international SEO is a solid place to start.

Policy and Governance Changes You Must Understand

The upcoming ICANN round is not a copy–paste of 2012. Policy work over the past decade has led to new obligations, clearer guardrails, and some new opportunities.

Refined Registry Obligations

Registry operators sign a detailed Registry Agreement with ICANN. Compared with the previous round, you should expect:

• Clearer abuse mitigation duties — expectations for handling phishing, malware, and DNS abuse have tightened.
• Stronger data protection expectations — especially where domain registration data intersects with privacy regulations.
• Formal service-level commitments — uptime and performance targets for DNS and registry services.

We have already covered many of these policy themes in our article ICANN New gTLD Policies and what they mean for your domains. If you are starting a gTLD project, that deeper policy dive is worth reading alongside this more infrastructure-focused overview.

Public Interest, Safeguards and Closed Generics

ICANN has spent years discussing “public interest” safeguards – especially for domain spaces related to regulated sectors (health, finance, law, etc.) and for so-called “closed generic” TLDs where a single entity wants exclusive control over a generic term.

You should expect more scrutiny on:

• How you prevent consumer confusion and harmful uses
• Whether a closed or restricted namespace makes sense for the broader internet community
• How you will resolve conflicts and complaints over eligibility

String Contention and Objections

Two or more applicants may apply for the same or confusingly similar string. ICANN has well-defined processes for:

• String similarity evaluations
• Objection procedures (e.g. from rights holders, communities, or existing operators)
• Contention resolution — in some cases, auctions

Monitoring these policies early helps you choose a string that is realistic, defendable, and strategically aligned with your brand and legal position.

To keep up with the broader domain policy trends beyond gTLDs, our article ICANN domain policy changes and what they mean for your domains in 2025 gives a wider context of how the domain space is tightening overall.

Architecture Behind a gTLD: Registry, DNS and Hosting Layers

Running a gTLD is not just a legal and branding project; it is fundamentally a hosting and infrastructure project. At dchost.com we live in this layer every day, so let’s break down what actually runs under a TLD.

1. The Registry Backend (SRS, EPP, and Databases)

The registry backend is your “source of truth” for all domain records in your TLD. Key components include:

• Shared Registration System (SRS) — the core application that manages domain objects, contacts, and name servers.
• EPP (Extensible Provisioning Protocol) servers — the interface that ICANN-accredited registrars use to create, renew, transfer, and delete domains.
• Relational databases — typically highly-available MySQL/MariaDB or PostgreSQL clusters with replication, point-in-time recovery, and strict backup procedures.

You will need to design the registry backend like a mission-critical SaaS: redundant VPS or dedicated servers, separate database nodes, and clearly documented disaster recovery. Our general guidance on designing backup strategies with proper RPO/RTO applies directly here — except the stakes are higher because it is not just one site, but an entire TLD.

2. Authoritative DNS Infrastructure

Every domain under your TLD ultimately resolves through the authoritative DNS servers you operate or contract. ICANN expects redundancy and robustness. In practice this means:

• Multiple geographically distributed DNS nodes — often with anycast routing for low latency and resilience.
• DNSSEC support — your TLD must be signed, and you must handle key rollovers safely.
• Strict uptime — downtime at the TLD DNS layer impacts every domain below it.

We have an in-depth guide on what DNSSEC is and how to set it up safely, including key rollover without breaking resolution. If you are planning to be a TLD operator, DNSSEC goes from “nice-to-have” to “non-negotiable core duty”.

3. WHOIS/RDAP and Public Data Services

Registry operators must publish domain registration data through WHOIS and/or RDAP services. Technically, this involves:

• One or more API/web services backed by your registry database
• Rate limiting and abuse control to avoid scraping and DDoS
• Careful handling of personal data to stay compatible with privacy regulations

From a hosting perspective, these are HTTP services behind load balancers, with WAF rules, rate limiting, and log retention policies similar to any high-traffic API you might run.

4. Security, Logging and Monitoring

A TLD is a high-value target. As a registry, you must assume you will face:

• DDoS attacks against DNS servers or public APIs
• Credential stuffing and phishing attempts targeting your control panels
• Attempts to abuse your TLD for spam, malware, or brand impersonation

This is where classic hosting practices meet registry-specific concerns. You will need:

• Hardened VPS or dedicated servers with properly configured firewalls and access controls
• Centralized logging across DNS, application servers, and databases
• Metrics and alerts to detect anomalies quickly

Our articles on securing a VPS for real-world threats and setting up monitoring and alerts with Prometheus and Grafana illustrate the same patterns you will apply at TLD scale – just with more redundancy and stronger SLAs.

5. Where dchost.com Fits Into This Picture

At dchost.com we operate the layers you need to build a registry stack: reliable VPS for application tiers, dedicated servers and colocation options for high-availability database clusters, and resilient domain and DNS services for your broader portfolio. Whether you choose to work with a specialized registry software provider or build more in-house, you still need solid, well-monitored infrastructure to host it on — that is exactly the kind of environment we design and maintain daily.

Application Process, Costs and Timeline

ICANN’s formal Applicant Guidebook for this round will define precise dates and procedures, but the high-level lifecycle will likely resemble the previous round, with more clarity and automation.

1. Pre-Application Planning

Before the window even opens, successful applicants usually spend months on:

• String selection — choosing the TLD string itself, including variants in non-Latin scripts if relevant.
• Policy design — deciding who can register, under what conditions, and with what verification (if any).
• Business modeling — projecting demand, pricing (if open), and long-term sustainability.
• Technical architecture — whether you will use an outsourced registry backend provider or build your own stack on top of robust hosting, VPS, and dedicated server infrastructure.

2. Application Submission

During the official application window, you will submit a detailed application covering:

• Applicant identity and financial stability
• Technical capability and infrastructure plans
• Operational and abuse mitigation policies
• Rights protection mechanisms (for trademarks and brand owners)

Expect significant documentation, supporting evidence, and clear written descriptions of your technical design, including DNSSEC deployment, uptime targets, and backup/restore procedures for registry data.

3. Evaluation, Objection, and Contention Phases

After submission, your application will go through:

• Initial evaluation — ICANN reviews your technical, financial, and operational plans.
• Public comment and objection periods — others can raise concerns (e.g., trademark holders, communities).
• String contention resolution — if multiple parties apply for the same or confusingly similar string.

During these phases you may need to clarify or adjust aspects of your plan. This is where having a concrete, already-tested infrastructure design (not just theory) helps convince evaluators you can run the TLD reliably.

4. Contracting, Pre-Delegation Testing and Delegation

If your application is approved, you will sign a Registry Agreement with ICANN, then complete pre-delegation testing. This is where you must demonstrate that your DNS, registry backend, and related services work according to ICANN’s requirements.

From an infrastructure perspective, you need your production environment ready — not just diagrams. This often involves:

• Production-ready VPS and dedicated servers in multiple data centers
• Live DNS clusters with DNSSEC enabled
• Monitoring, logging, and backup routines running and documented

Once you pass pre-delegation tests, your TLD is added to the root zone, and you can start operating it under your agreed policy.

5. Cost Considerations

A gTLD application is not cheap. While exact fees for this round will be finalized by ICANN, you should anticipate:

• An application fee in the tens of thousands of USD
• Ongoing ICANN fees per year and per-domain (if open)
• Legal and consulting costs for policy and contract work
• Infrastructure and operations costs (servers, DNS, support, monitoring)

The infrastructure part is one area where careful design can make a big difference. For example, using well-sized VPS clusters for stateless services, reserving dedicated servers for databases and storage-heavy functions, and leveraging colocation for specialized hardware can keep recurring costs predictable without sacrificing reliability.

Risk Management: Security, Abuse and Brand Protection

Owning a TLD does not automatically make your namespace safe. You must actively manage risk on several fronts.

1. Abuse Mitigation and Reputation

ICANN and the broader internet community expect registries to react quickly to abuse: phishing, malware hosting, botnet control domains, and large-scale spam. If your TLD becomes associated with abuse, browsers, email providers, and security vendors may treat it with distrust.

Practical steps include:

• Clear AUP and enforcement mechanisms in your registration policy
• Abuse reporting channels and SLAs for investigation
• Automation to detect patterns in DNS and registration data

Many of the techniques we use to protect hosting environments from abuse and compromise (centralized logging, anomaly detection, WAF rules, and rate limiting) apply equally well here.

2. Domain Security and Locking

Your own core domains under the new TLD – registry portals, support sites, APIs – must be especially well-protected. Techniques like registry lock, transfer lock, strong authentication and DNSSEC all matter.

We have a dedicated domain security guide, Domain security best practices: registrar lock, DNSSEC, WHOIS privacy and 2FA, which outlines the same practices you will want to enforce for your own high-value domains and encourage (or require) for critical registrants.

3. Brand Protection and Conflicts

Even as a registry, you remain a brand owner operating in a global domain marketplace. You may still need:

• Defensive registrations in other TLDs to avoid confusion
• Monitoring for typosquats and lookalikes
• UDRP/URS strategies for disputes that spill beyond your own TLD

If your TLD is part of a broader migration or rebrand, our guide on changing your domain without losing SEO can help you plan redirects, SSL, and DNS changes so that moving key web properties under your new TLD does not damage search visibility.

How We Suggest Planning Your Next Steps

For organizations eyeing the new ICANN gTLD round, we usually recommend a staged approach that combines policy, technical, and business work rather than treating them as separate tracks.

1. Clarify the Strategic Why

Start with a short but honest internal document answering:

• What problem does this TLD solve for us or our community?
• How will success be measured in 5–10 years?
• Is this primarily about brand control, security, community building, or revenue?

This helps cut through “it would be cool” thinking and forces a realistic conversation about resourcing and long-term commitment.

2. Map Requirements to Infrastructure

Translate your policy and business goals into concrete infrastructure requirements. For example:

• If you want a closed .brand with a few thousand internal domains, you might favor a compact registry backend, a small but very robust DNS footprint, and strong integration with your internal identity systems.
• If you aim for an open, high-volume TLD, you will need horizontally scalable application servers, database replicas, and careful capacity planning for DNS and WHOIS/RDAP traffic.

This is where your choice between VPS clusters, dedicated servers, and colocation becomes real: each layer should be sized to your realistic year‑1, year‑3, and year‑5 traffic and growth expectations.

3. Prototype Early, Even Before Applying

We strongly recommend building a working prototype of your registry backend and DNS layout on a test subdomain or private namespace long before pre-delegation testing. On our side, we typically help customers spin up:

• A small registry-like application stack on VPS instances
• A replicated database cluster on dedicated servers
• Authoritative DNS nodes, signed with DNSSEC, in multiple locations

Even if you change vendors or software later, the experience of operating a small, always-on, DNS-and-database-heavy service prepares your team for the reality of a TLD.

4. Align with Your Existing Domain Portfolio

A new gTLD does not replace your existing domains overnight. You will still manage .com, ccTLDs, and other gTLDs for years. Think through:

• Which properties migrate to the new TLD and on what timeline
• What will remain on legacy domains for SEO, email stability, or regional reasons
• How redirects, certificates, and DNS records will be managed across all of them

Our guide on domain portfolio management for renewals, billing and brand protection is a useful counterpart here; a TLD just adds one more (very special) asset into that portfolio.

5. Build a Cross-Functional Team

Successful TLD projects are not purely IT or purely marketing. You will need at least:

• Technical leads for DNS, servers, security and monitoring
• Legal and policy expertise for ICANN processes, contracts and rights protection
• Operational staff for customer support and abuse handling (if open)
• Brand/communications roles to explain the TLD to users and partners

From our side at dchost.com, we typically collaborate with your technical and operations teams on the hosting, DNS, and security design, while your legal and marketing teams focus on policies, brand positioning and user communication.

Closing Thoughts: Turning a Big Idea into a Stable TLD

The newly launched ICANN gTLD application round is a rare chance to move from being a domain customer to being an internet infrastructure operator. It is easy to get excited about owning .yourbrand or .yourcity; the real work lies in designing and running the registry, DNS, and security layers so that every domain under your TLD feels as boringly reliable as .com.

If you are seriously considering an application, the best time to start is before the formal window opens: clarify your strategy, sketch policies, and begin prototyping the hosting and DNS architecture you will rely on later. Treat it like any other critical production system: capacity planning, redundancy, backups, monitoring, and clear runbooks for incidents and changes.

As the dchost.com team, we spend our days building and maintaining exactly these types of architectures for domains, hosting, VPS, dedicated servers and colocation setups. If you want to explore what your future registry stack could look like — from DNSSEC-signed authoritative servers to resilient registry databases and secure management access — we are ready to help you turn a big idea into a concrete, testable infrastructure plan. The next gTLD round will reward those who combine vision with solid engineering; now is the time to align both.