How to give away a custom domain ending for $10, not $227,000

There are three real ways to get something that behaves like a custom domain ending, and they're not interchangeable. The first is to buy a normal domain and stop there. yourname.com is already "your own ending" in every practical sense; nobody else can register under it, and you decide what goes at every subdomain. Most people asking for a custom TLD would be happy with this alone.

The second is to run an opt-in alternative DNS root, the kind of project that mints endings like .crypto or .zil outside ICANN's system. These resolve for whoever installs the matching resolver or browser extension, and for nobody else. They look like a new TLD in a screenshot and behave like nothing on the actual internet unless the visitor already opted in.

The third is the real thing: apply to ICANN and get an entry in the root zone that every standard resolver on earth already understands. That's the only option that produces an ending like .com or .dev everyone's browser resolves by default with no extra software. It's also the expensive one.

ICANN opened a new round of generic top-level domain applications, accepted from April 30 to August 12, 2026. The evaluation fee was USD 227,000 per application, non-refundable in whole once evaluation begins, and that number covers evaluation only. Get approved and you're also on the hook for registry operation. That means the technical infrastructure to actually run it, staying in compliance, and fees that don't stop once the TLD is live.

For almost everyone who says "I want my own TLD," that fee is the whole conversation. It's not a startup cost you grow into. It's a gate that assumes you're a registry operator, a large brand protecting a trademark string, or a country administering a ccTLD, not someone who just wants a clean namespace for a community, a hobby project, or a product.

Register one ordinary domain whose name reads like an ending, then give away subdomains under it. That's it. is-a.dev did this for developer portfolios. js.org did it for JavaScript projects. eu.org has been doing it since long before either. None of these are TLDs. Each is one domain, with a very long list of people who each control one subdomain of it.

The trick is where the list of subdomains lives. Instead of a DNS panel only the domain owner can touch, the list lives as a public GitHub repository. Claiming a name becomes a pull request: add a file, get it merged, and your subdomain exists. Nobody needs registrar access, and the whole history of who claimed what sits in a public git log.

This only works because of one DNS record: a wildcard, written as *.example.com, pointed at a single application. Without it, every new subdomain needs its own DNS entry added by hand, which is exactly the bottleneck a registrar runs into. With it, anything.example.com, whatever anything is, resolves to the same app, which then reads the incoming hostname and decides what to serve.

TLS follows the same trick. A wildcard certificate for *.example.com covers every subdomain automatically, present or not yet claimed, so a brand-new name gets valid HTTPS the moment DNS propagates, with no per-subdomain certificate request. Put those two together and claiming a name stops being a DNS operation at all. It becomes a database write: add a row (or in this design, merge a file), and the wildcard record and wildcard certificate already in place do the rest.

The .dev TLD is on the HSTS preload list, the list browsers ship with that forces HTTPS before the first request ever goes out, with no trust-on-first-use plaintext connection possible. Because the preload entry covers the whole TLD, every subdomain under it inherits the same guarantee automatically. A visitor can't accidentally load name.example.dev over plain HTTP, even on the very first visit, even if a link or a typo pointed them at http://.

For a registry handing subdomains to people you haven't vetted, that's a security property, not a branding choice. It closes off an entire class of downgrade and interception attacks on every name in the registry, without asking each subdomain owner to configure anything.

Running the technical side is the easy part. What actually takes ongoing attention comes from being the registrant of record for every name someone else claims:

runs-on.dev is our version of this pattern at Advance Labs, live today. Anyone can claim a name.runs-on.dev subdomain with a GitHub account in seconds and get a profile card out of it. Pointing the name at their own hosting is a pull request against a public registry repository. The whole cost of standing it up was about $10, one domain, one year, against the $227,000 ICANN charges just to evaluate a real TLD application.

It's not a TLD, and we don't claim it is. It's one .dev domain with a wildcard record and a public git-based registry sitting behind it, the same shape as is-a.dev, js.org, and eu.org before it. See it at

Is runs-on.dev a top-level domain?

No. runs-on.dev is one registered domain (a .dev subdomain registry) that gives away subdomains under itself. It is not a new gTLD, was never submitted to ICANN, and does not appear in the DNS root zone as its own ending. Claiming a name gets you name.runs-on.dev, a subdomain, not a standalone TLD.

How much does ICANN charge for a new top-level domain?

In the 2026 new-gTLD application round, which ran April 30 to August 12, 2026, ICANN's evaluation fee was USD 227,000 per application. That covers evaluation only; a successful applicant also takes on ongoing registry operation obligations and fees.

How does a subdomain registry give out HTTPS for names that don't exist yet?

A wildcard TLS certificate for *.example.com covers every possible subdomain in advance, so a name gets valid HTTPS the moment it's claimed and DNS propagates. No per-subdomain certificate request is needed.

Why use a .dev domain for a registry like this instead of .com?

.dev is on the browser HSTS preload list, so every subdomain under it is forced to HTTPS from the first request, even before any certificate has been seen by that browser. For a registry serving pages for people you haven't vetted, that closes off a class of downgrade attacks by default.

What's the actual mechanism that makes claiming a name fast?

One wildcard DNS record (*.example.com) pointed at one application, combined with a wildcard TLS certificate. Both are set up once. After that, claiming a subdomain is a database write, in runs-on.dev's case a merged pull request against a public GitHub repository, not a DNS change.