So, You Want Your Own Dot? A Friendly Deep Dive into ICANN’s Next gTLD Application Round

A few years back, I was sipping a late coffee when a client pinged me with a wild idea: “What if we ran our own extension?” Not a subdomain, not a cute URL hack — a full-blown top-level domain with their brand at the very end. I laughed, then paused, then felt that little electric buzz you get when you realize you’ve stumbled into something both terrifying and incredibly exciting. We sketched on napkins, we called lawyers, we stood up test zones, we debated names. It was chaos. Fun chaos, but chaos nonetheless.

Ever had that moment where a thing you’ve only seen giant brands do suddenly feels reachable? That’s what the next gTLD application round from ICANN feels like. Not just “.com” and the usual suspects, but the chance for brands, communities, innovators, and even cities to run their own slice of the internet’s naming system. This isn’t just vanity — it’s strategy. Control. Security. And if you do it right, a long-term, defensible asset that shapes how people find and trust you online.

In this guide, I’ll walk you through what the next application round actually is, how the process tends to flow, the gotchas that trip folks up, the timeline signals to watch, and how to turn technical obligations into competitive advantages. I’ll share what I’ve seen in the trenches with teams who made the leap, and I’ll keep it conversational. Think of this as the friendly map I wish I’d had the first time I shrugged and said, “Sure, we can try to run a TLD… how hard could it be?”

What “ICANN’s Next gTLD Application Round” Really Means

Let’s set the stage without the corporate gloss. The internet’s naming layer — those strings after the dot — is managed in a carefully controlled way. ICANN coordinates this, and they periodically open an application window where organizations can apply to run new generic top-level domains (gTLDs). The last big window like this was over a decade ago, which brought us extensions like .app, .blog, .xyz, and countless others you see today. The “next round” is the new opportunity to join that club.

Here’s the thing: this isn’t like spinning up a new website. Running a TLD is more like getting a zoning permit for a tiny but critical neighborhood in the global internet. You don’t just pitch a cool name and go live. You’ll face evaluation on technical stability, business continuity, security and abuse management, rights protection mechanisms, and whether your chosen string conflicts with others or creates confusion. You’ll sign a serious contract. And you’ll live with operational obligations, 24/7.

That sounds intimidating, and yes, it should. But it’s also doable with the right partners and planning. The next round is aiming to make some parts smoother, with clearer paths for brand TLDs, geographic names with proper approvals, and even pre-evaluation of registry service providers so you don’t reinvent the wheel. Think of it as an adult project: exciting, a bit expensive, and totally worth it if aligned with your long game.

From Idea to the Root: The Journey in Plain Language

When someone tells me they want to apply, I always start with a napkin-level diagram. There are a handful of phases, and the magic is in respecting the order while quietly preparing the next step ahead of time.

First comes the strategy: why do you want your own TLD? If the answer is vanity, that’s cute, but usually not enough. Winners typically have two or three deeper reasons. Maybe it’s a trust signal to customers. Maybe it’s brand control to flatten phishing. Maybe it’s a distribution strategy to let partners launch meaningful second-level names under your umbrella. Or maybe it’s a community project that gives shared identity to a profession or region. Get that story straight early, because it will echo through everything that follows — from your application narrative to your launch plan.

Next, naming. Picking your string — the thing after the dot — is simple in theory and loaded in practice. You’ll check for similarity to existing TLDs, consider how it looks in different scripts, and avoid terms that could cause ambiguity or policy headaches. You’ll watch for homographs (lookalike characters), and if you’re dabbling in internationalized domain names (IDNs), you’ll plan for variants and right-to-left or complex script behavior. I’ve seen teams get stuck here for months, not because they lacked creativity, but because they hadn’t considered how the name would behave in a global DNS and policy context.

Then the application preparation. This is where you gather documentation on governance, technical operations, continuity planning, DNSSEC implementation, data escrow, abuse monitoring, and rights protection. You’ll choose your back-end registry service provider (RSP) or prepare to become one. Many applicants partner with established RSPs who’ve already been around the block — that’s like hiring a seasoned general contractor instead of learning to pour concrete yourself.

After the application window closes, ICANN publishes the list of applied-for strings. That’s the popcorn moment where you see who else is going for the same or similar names. Public comments open, and formal objection periods begin. Conflicts get resolved through policies and sometimes auctions. If you’re the only one going for your string, congratulations — your path just got simpler. But don’t get complacent: there are still evaluations to pass.

Pass evaluations, and you move into contracting, where you finalize the registry agreement and related commitments. From there, you face pre-delegation testing — basically proving your systems, processes, and people can operate safely and reliably. When you clear that, your TLD gets added to the root zone. That’s the moment the internet’s phone book learns your new street exists. Then the real work begins: launching responsibly.

Timelines, Fees, and the Messy Middle (What to Watch)

Everyone always asks, “When does the next round open?” Fair question. ICANN has shared signals that the program is moving through policy to implementation, and the industry chatter tends to converge around the idea that we’re getting closer — think measured steps rather than surprise sprints. The honest answer is that this is a living timeline, and you’re best served by preparing on two tracks: strategic readiness you can do now, and detail work you align once the official guidebook is published.

Fees matter, of course. Expect a significant application fee — historically in the six figures — and plan for registry operations, security, legal, and launch marketing. The sticker shock fades when you ground it in multi-year value. A brand TLD can absorb budget that would’ve gone to defensive registrations or whack-a-mole takedowns. A community TLD can sustain itself with a thoughtful model and responsible pricing. But be sober: you’ll carry obligations. This isn’t a one-off expense.

There are also policy wrinkles worth acknowledging early. “Closed generics” — where a generic term is operated by a single entity with restricted registrations — have been a hot topic. Geographic names have guardrails and may require letters of support or non-objection. Community-based applications bring their own benefits and responsibilities. String similarity can knock you out even if no one else applied for your exact term. And GAC advice (governmental advisory) can shape outcomes. None of this is meant to scare you; it’s simply the map. The trick is to design with these in mind instead of bolting fixes on later.

Two practical tips that have saved my clients a lot of heartburn. First, do a “pre-mortem.” Ask, “If this fails, why did it fail?” Then work backward to reduce those risks now — crisis communications for public comments, alternative strings if your first choice gets contested, and a refined narrative that makes your public interest case clear. Second, start talking to your potential RSP early. Many are offering pre-evaluation paths and standardized documentation that will slot directly into your application once the window opens.

If you want to track official updates and the evolving program details straight from the source, keep an eye on ICANN’s next round overview. When the Applicant Guidebook lands, read it twice: once cover-to-cover to get the shape, once with a highlighter to mark decisions you must lock before pressing the big “apply” button.

Choosing the Right Kind of TLD: Brand, Generic, Geo, or IDN?

I’ve seen four patterns succeed, and they each feel different in the hands.

Brand TLDs are the most straightforward to explain to your CFO. You own a mark, you operate a closed registry for your organization (and affiliates), and you use it to carve out a safer, more consistent namespace. Imagine support.brand, shop.brand, partners.brand — each one communicates “official” without shouting. Security teams like this because it kills off lookalike domains that weren’t yours to begin with. Marketing teams like this because URLs become clean, predictable, and on-message. And legal teams sleep better knowing rights protections are baked in. You’ll still run sunrise/claims in a way that respects trademark holders, but the heart of a .brand is private control with public clarity.

Generic TLDs are public gardens. You set the rules, pricing, and positioning, and registrars list your TLD right alongside the classics. This is where the exact string matters a lot. I’ve watched generic TLDs thrive when they connect identity and utility — not just “cool word,” but a clear community and clear use. That can be a profession, a hobby, a movement, or a technology. If you choose this path, design your abuse response plan early. You’ll be judged by how well you protect users while enabling growth.

Geographic TLDs carry pride and politics. Think city names and regional identities. Get the right letters of support and build a governance model that includes stakeholders without becoming bureaucratic. These can be fantastic rally points for local businesses when tied to digital readiness programs and city-wide promotions. I helped a city team launch domains alongside small-business digital workshops — it created stories that the press loved and, more importantly, actual usage beyond defensive registrations.

Internationalized domain names (IDNs) deserve a special nod. Serving users in their own languages and scripts is both respectful and powerful. It also introduces nuance: variant management, typography, and UX across browsers and devices. If you go here, invest in language expertise and testing in the wild. The payoff is real: I’ve seen IDN-centric launches spark genuine local excitement because people finally see themselves — their script — at the top-level.

The Technical Backbone: DNS, DNSSEC, IPv6, RSPs, and Continuity

Let’s talk plumbing. The world doesn’t see this part unless something breaks, and your whole job is to ensure it doesn’t. At the top level, that means authoritative DNS that’s anycasted across regions, with strong DDoS resilience, predictable latency, and operational maturity. You’ll implement DNSSEC end-to-end. You’ll escrow registration data. You’ll have continuity plans and access to an Emergency Back-End Registry Operator pathway if life goes sideways. This is why most applicants partner with a registry service provider — the expertise and tooling are already there.

Two technical commitments are worth planning early and rehearsing often. First, DNSSEC. Key ceremonies, KSK/ZSK rollovers, DS record handling with the root — these aren’t hard once you’ve done them, but they’re nerve-wracking the first time. I wrote a friendly walkthrough of doing a zero‑downtime DNSSEC rollover and DS updates without breaking the internet; the same calm principles apply at TLD scale, just with stricter ceremony.

Second, IPv6. Your authoritative name servers must be reachable over IPv6 as well as IPv4, and your RSP should make that automatic. That said, don’t treat IPv6 as a checkbox. Monitor it. Test it from vantage points around the world. If you’re new to the IPv6 party, my piece on accelerating IPv6 adoption without breaking anything lays out a no-drama path that applies neatly here: dual-stack cleanly, watch your logs, and iterate calmly.

Beyond that, you’ll integrate with registrars via EPP and support RDAP. You’ll build abuse detection into your daily rhythm — think signals for fast-flux, phishing, and malware distribution. And you’ll publish clear points of contact for law enforcement and the security research community. One thing I’ve learned the hard way: document your playbooks. If 3 a.m. is the first time you realize who’s on-call for a key sign, you’re playing on hard mode.

As you approach the final gating, you’ll go through pre-delegation testing — a sanity check that your systems and processes meet requirements. It’s not meant to be adversarial; it’s a safety valve for the internet. Skim the historical process and shape of it via ICANN’s pre-delegation testing overview, and use it as a rehearsal target for your runbook and monitoring stack.

The Launch: Sunrise, Claims, Premiums, Registrars, and Real Usage

Once your TLD is in the root, the temptation is to sprint. Resist that urge and follow a methodical launch arc. You’ll run a sunrise period so trademark owners can register matching names. You’ll run a claims period that alerts registrants when a label matches a mark. You’ll define reserved and premium lists, and you’ll decide whether to work with tiered pricing or keep it flat. This is where strategy meets ethics: make it accessible, but don’t leave obvious abuse bait sitting on the shelf at bargain-bin prices.

Your registrar strategy matters. Some TLDs go exclusive with a few partners who’ll give them love. Others aim wide so their TLD shows up wherever people buy domains. Neither is universally better. If you go broad, invest in enablement content — short guides and crisp value props that registrars can paste into their storefronts without editing. If you go focused, double down on joint marketing and real usage stories. I have a soft spot for launches that lean into education: workshops, office hours, and tidy docs go further than splashy ads.

One behind-the-scenes topic I don’t see discussed enough is certificate management at scale. If you’re running a .brand, you’ll likely deploy TLS certificates across hundreds of subdomains and apps. It’s easy to get tripped up by compatibility, algorithm choices, and renewal surges. If that’s your world, this explainer on serving dual ECDSA and RSA certificates can help you keep performance high while staying compatible with legacy clients. And if your security team ever finds itself wrangling mismatched ciphers and browser updates on a deadline, I’ve got a calm therapy session disguised as an article: the quiet drama of SSL and how to stay ahead.

Another operational “gotcha” is DNS behavior at the apex. Even if you’re not a DNS nerd, you’ll run into questions like, “Why can’t I put a CNAME at the root?” and “What’s the deal with ALIAS or ANAME?” Your registrants — or internal teams — will ask. Having a friendly explanation ready smooths support and keeps projects moving. If you need a primer, here’s a coffee-length read on CNAME at the apex and the ALIAS/ANAME story you can share with your devs and marketers alike.

Lastly, build a feedback loop. Watch how names get used, collect stories, and surface wins. I’ve seen .brands announce new launches inside their own namespace (“today.company”) so customers learn by example. And I’ve seen generics support early adopters with tutorials and small grants. The point isn’t to “sell domains;” it’s to cultivate meaningful usage that strengthens your TLD’s reputation over time.

Abuse, Email, and Trust: The Unsexy Work That Makes You Proud

Every registry discovers that trust is a daily practice, not a policy doc. If you run a public TLD, you’ll confront abuse. If you run a .brand, you’ll still see attackers try to weaponize lookalikes in other spaces or abuse subdomains on compromised infrastructure. What separates grown-up operators from everyone else is a blend of clear policies, responsive ops, and proactive hardening.

Email deserves its own spotlight. If you’re running a .brand and plan to use email at scale, don’t wait until launch day to align your authentication posture. Use DMARC, SPF, and DKIM with clarity, and consider advanced layers that help keep transport secure and monitor misconfigurations. I wrote a practical guide to strengthening delivery and encryption that your email team might appreciate: SMTP security with MTA‑STS, TLS‑RPT, and DANE/TLSA. The short version: specifics matter, and they’re manageable when you start early.

On the website side, moderate your message: celebrate use, but don’t accidentally invite abuse. I’ve cringed at TLD marketing that basically promised “buy short, generic names and point them anywhere” — that’s catnip for phishers. Instead, frame your TLD around authentic identities, clear rules, and a culture that values accountability. Security pros and regulators notice, and the goodwill’s worth its weight in uptime.

RSP Pre‑Evaluation, the Guidebook, and Staying Sane

One of the most helpful shifts in the upcoming round is the continued emphasis on pre-work that reduces friction later. Registry service providers can undergo a pre‑evaluation so applicants know they’ve hit key technical marks before the application crunch. That’s a gift — treat it that way. The earlier your chosen RSP can hand you documentation and compliance artifacts shaped for the application, the better you’ll sleep.

Meanwhile, the Applicant Guidebook (AGB) is your north star. In the last round, it was a hefty reference that governed everything from evaluation criteria to timelines, objections, and contracting. Expect a modernized version for the next round. If you’re new to this and want to see how the last one looked in practice, skim the prior AGB for texture: the historical Applicant Guidebook (2012 edition). It’s dated for policy details, but it’s great for understanding the shape of an end-to-end program.

As official updates roll out, keep your planning flexible. I like to draw two timelines on a whiteboard: the “policy clock” (what ICANN will finalize and when) and the “readiness clock” (your private milestones). The second is the one you control. Governance approvals, budget gating, string selection, stakeholder outreach, and RSP selection — these can progress now. When the policy clock gives you the green light, you’ll be ready to move without rushing.

A Real‑World Story: The Day the Dot Became Real

I’ll never forget the moment a client’s string finally appeared in the root. We refreshed a simple script that resolved NS queries against multiple vantage points, and there it was — their brand, live, answerable, global. The room went quiet in that soft, goosebump way. It wasn’t just a marketing win; it was infrastructure and identity fused in a way that felt permanent. Over the next few months, they rolled out internal services first, then public sites, then partner spaces. Each step felt deliberate.

They learned a few lessons the hard way. They discovered that certificate management needed a calendar, not a hero. They found that registrars wanted tighter one-pagers explaining who should buy what and why. They learned that abuse reports needed quick human eyes, not just automation. And they realized they needed friendlier docs for their own internal developers to request zones and records. Nothing glamorous — but everything essential.

What I loved most was how the .brand clarified their security posture. Phishers couldn’t convincingly impersonate them inside their own TLD. Support scripts got simpler: “If it ends in .brand, it’s us.” That’s not a silver bullet, but it’s a signal users understood. When they later performed their first DNSSEC KSK rollover, it felt like a ceremony, not a panic. The practice runs paid off. That’s the moment I knew they would thrive — not because they never had issues, but because they had rituals for handling them.

Practical Next Steps You Can Start Now

If you’ve read this far, there’s a decent chance your curiosity isn’t just academic. So here’s a calm, non‑dramatic way to get moving before the application window opens.

First, write the one‑page “why” memo. Plain language. Who you serve, what you’ll protect, and how you’ll know it’s working two years in. If you can’t explain it to a smart colleague in five minutes without slides, keep refining.

Second, pick a short list of strings and run them through the obvious filters. Any likely conflicts? Any geographic sensitivities? Any confusingly similar existing TLDs? How do the strings look in sentence case, all caps, and mobile UI? If you’re exploring IDNs, get native speakers in the room — not just for accuracy, but for vibe.

Third, begin conversations with RSPs. Ask about their pre‑evaluation status, their DNSSEC and IPv6 practices, their experience with sunrise/claims, and how they support abuse handling. Ask for templates, runbooks, and what they wish applicants knew six months earlier.

Fourth, sketch your launch arc. Will you begin with internal use (for .brands) before public faces? Will you run phased Landrush or go straight to General Availability? What stories will you tell, and who will tell them with you?

And finally, keep tabs on official program updates at ICANN’s next round hub. When the new AGB is published, align your documents, fill in the gaps, and schedule your internal approval gates backward from the application window. This is less about being fast and more about being ready.

Wrap‑Up: Owning a Slice of the Internet, Minus the Drama

If you’ve ever felt that domains are a bit like renting apartments — useful, but always on someone else’s terms — the next gTLD application round is your chance to become a thoughtful landlord. Not for the whole city, just your block. Big enough to matter, small enough to run with pride.

We covered the arc from idea to delegation: choosing the right kind of TLD, aligning strategy with policy, partnering with an RSP, building reliable DNS with DNSSEC and IPv6, and launching in a way that invites real usage while keeping abuse in check. We touched on the unglamorous practices that make it work in the long run — certificate rituals, email authentication, and crisp docs. And we grounded it all in a simple truth: this is doable when you prepare calmly and move with intention.

If you’re serious about stepping into this, start your one‑pager, pick your short list of strings, and talk to someone who’s been there. Treat the Applicant Guidebook as your rulebook and your registry service provider as a teammate, not a vendor. And when your dot goes live, take a quiet minute to appreciate the craft it took to get there. Hope this was helpful! If you want more calm, practical reads while you plan, you might enjoy my guides on zero‑downtime DNSSEC, accelerating IPv6 adoption, and staying ahead of SSL changes. See you in the next post — and maybe in the root zone.