The .self TLD: Self-Hosting

A self-hosting domain was all Marcus wanted. Not much, right? He ran a tidy homelab — Proxmox cluster, a dozen LXC containers, Nextcloud for the family, Jellyfin for movie nights. He'd even set up WireGuard so his parents could access shared photos without touching iCloud. Smart guy. Patient guy. But getting a clean, memorable domain that actually resolved on his local network and from his phone on LTE without split-brain DNS hacks, a reverse proxy, Cloudflare Tunnels, and a Let's Encrypt dance? That took him three weekends and two heated Reddit threads.

When someone in the homelab community floated the idea of a .self TLD — a top-level domain reserved globally for self-hosted infrastructure, resolvable by any compliant resolver, no registrar required — Marcus was practically evangelical about it. Finally, something that addressed the actual problem. He posted about it. His thread got traction. The idea spread.

I watched that conversation unfold, and I understood the excitement completely. I also knew, with the quiet certainty of someone who's spent years navigating ICANN policy cycles, enterprise DNS architecture, and ISP infrastructure realities, that it was almost certainly going nowhere. And the reasons why it won't work tell us something important about where self-hosting sovereignty actually comes from.

The Proposal and Why It's Technically Seductive

The .self TLD concept — circulating with renewed energy in homelab and self-hosting communities right now — proposes a special-use TLD that operating systems, routers, and resolvers would recognize natively, similar to how .local works for mDNS via Bonjour/Avahi. The pitch is elegant: type nextcloud.self in any browser, and your device knows to look on your local network or your personal infrastructure, no public DNS required, no registrar fees, no certificate authority gymnastics.

The technical romanticism here is real. .local already does something adjacent to this via Multicast DNS (mDNS), and IANA maintains a Special-Use Domain Names registry that includes .localhost, .local, .example, and a handful of others. So the precedent exists. The machinery exists. Why not .self?

Because the gap between "technically precedented" and "actually deployed at global scale" is where good ideas go to die slowly.

The Infrastructure Reality That Kills This in Committee

Let's start with ICANN, because any new TLD — special-use or otherwise — has to survive that process. The last ICANN new gTLD program opened in 2012, produced 1,930 new TLDs, took years of public comment periods, legal challenges, and cost applicants $185,000 just to apply. The next round has been in planning for the better part of a decade. Special-use reservations through the IETF are faster but not fast — .onion took years to get RFC 7686 status, and Tor had a massive, well-organized advocacy infrastructure behind it.

.self has a Reddit thread and some enthusiastic homelab operators. I'm not being dismissive — I'm being precise about the political weight required to move these institutions.

But the ICANN problem is almost secondary to the ISP problem, and this is where the proposal truly breaks down.

For .self to work seamlessly — the way the proposal envisions it — every recursive resolver in the chain needs to understand that .self queries should never leave the local network or should resolve to personal infrastructure. That means ISP-operated resolvers, the ones your router uses by default in most homes, need to implement this behavior. Comcast, AT&T, Verizon, Charter. These are companies that have historically intercepted NXDOMAIN responses to serve ads. The idea that they'll faithfully implement special-use resolution semantics that actively route traffic away from their infrastructure and toward user-controlled systems requires a level of good faith that the historical record simply doesn't support.

And even if the major ISPs cooperated, you'd have a patchwork. Mobile carriers run their own resolvers. Corporate VPNs override DNS entirely. Public Wi-Fi networks do whatever they want. The .self experience on your home fiber connection might be perfect. The same .self address on your phone's LTE might NXDOMAIN. On your work laptop through the VPN? Who knows. This isn't a solvable edge case — it's the fundamental nature of how DNS resolution actually works in a world of layered, competing infrastructure operators.

The DNS Fragmentation Problem Is Already Here

Here's what the .self advocates are reacting to, and they're right to react: DNS fragmentation is already a serious and worsening problem for self-hosters. The recent US Supreme Court decision that's effectively blown up EU-US data transfer frameworks is accelerating exactly the kind of data sovereignty concerns that make self-hosting attractive in the first place. People want control. They want their data on their hardware, in their jurisdiction, under their management. That's a legitimate and increasingly urgent need.

But DNS fragmentation doesn't get solved by adding another special-use TLD into an already-chaotic namespace. It gets worse. We've already got .local for mDNS, .localhost for loopback, .internal used informally by millions of organizations (without any formal reservation — a ticking time bomb if ICANN ever sells it), .corp, .home, .lan all in informal widespread use. The ICANN New gTLD Program has already created collision risks with internally-used names. Adding .self to this ecosystem doesn't simplify anything — it adds one more thing that works in some contexts, breaks in others, and creates security surface area in the gap.

The security angle deserves its own moment of attention. If .self becomes a recognized special-use name but implementation is inconsistent across resolvers, you create a phishing vector. A malicious public DNS resolver could intercept .self queries that leak outside the local network and serve attacker-controlled responses. Users who've been trained to trust nextcloud.self as "their server" are now primed to trust a spoofed response. This is not hypothetical — it's the same class of attack that affects .local when mDNS is misconfigured.

What the DevOps and Cloud Communities Are Actually Doing

While the .self discussion is happening in homelab forums, the working solutions are coming from the infrastructure and DevOps communities, and they look nothing like a new TLD.

Tailscale and the MagicDNS model is the most important development in personal DNS infrastructure in the last five years. Tailscale's MagicDNS assigns stable, human-readable names to every node in your tailnet — nextcloud.your-tailnet.ts.net or just nextcloud within the network — and it works, on every device, on every network, without any ISP cooperation, without any ICANN approval process. It works because it's implemented at the WireGuard layer, not the DNS layer. The naming is a consequence of authenticated, encrypted network membership, not a prayer that every resolver in the chain behaves correctly.

Cloudflare Tunnel with Zero Trust is the enterprise-grade version of this for public-facing self-hosted services. You get real TLS, real domain names, no port forwarding, no exposed home IP. It's not pure self-hosting — there's a Cloudflare dependency — but it solves the actual problem Marcus had: consistent, secure access from anywhere.

Split-horizon DNS with proper automation — using something like Pi-hole + Unbound + Nginx Proxy Manager — is still the right answer for advanced homelab operators who want full control. Yes, it's three weekends of setup. That complexity is inherent to the problem, not a failure of tooling.

The pattern across all three approaches: they solve the self-hosting domain problem by controlling the network layer, not by lobbying the naming layer. This is the architectural insight that the .self proposal misses entirely.

The AI Angle Nobody's Talking About

There's a dimension to this debate that's just starting to surface, and it matters more than most people realize. AI assistants are increasingly acting as navigation layers — users ask their AI to "open my Nextcloud" and the AI needs to resolve what that means and how to get there. As local reasoning systems become more sophisticated, the question of how AI agents discover and authenticate access to personal infrastructure becomes critical.

A .self TLD doesn't help here at all, because AI agents operating across different network contexts face the same fragmentation problem as human users — worse, actually, because they can't intuitively notice that something resolved wrong. What does help is cryptographically authenticated network membership (Tailscale's model) combined with well-structured service discovery APIs. The future of AI-assisted access to self-hosted infrastructure is built on identity and authentication, not on DNS naming conventions.

This is where I'd push homelab operators to focus their energy: not on advocating for a new TLD, but on building infrastructure that's identity-first. If your services are behind proper authentication, properly networked, and properly discoverable through authenticated channels, the naming problem becomes almost trivial.

My Take: Stop Waiting for ICANN to Save You

I want to be direct about where I land on this, because the .self discussion deserves a straight answer rather than endless hedging.

The proposal is technically romantic and practically naive. It requires coordination from institutions — ICANN, ISPs, OS vendors, browser makers — that have competing incentives, slow processes, and long histories of not prioritizing homelab operators. Even in the optimistic scenario where .self gets formal special-use status in five years, you'd still have a decade of inconsistent implementation before it's reliable enough to actually build on. And secrets management for self-hosted services — which is already done lazily by most operators — would get more complicated, not less, as people start treating .self as a trusted namespace without the underlying security infrastructure to back it up.

The real path to self-hosting sovereignty is:

Own your network layer. Tailscale, WireGuard, or a properly configured VPN gives you consistent name resolution without any external dependencies. This works today, on every device, in every network context.

Own your certificates. A wildcard certificate on a real domain you control, automated with Let's Encrypt and a DNS challenge, costs you $10-15/year for the domain and zero for the cert. This is a solved problem.

Own your authentication. Authelia, Authentik, or Keycloak in front of your services means that even if naming is messy, access is secure. Identity-first infrastructure is more resilient than naming-first infrastructure.

Accept the complexity tax. Self-hosting is not supposed to be as easy as using Google Drive. That ease is what you're trading away for control. The complexity is the cost of sovereignty, and no TLD is going to eliminate it.

Marcus eventually got his homelab working cleanly. He's running Tailscale now, with MagicDNS, and his parents access the shared photo server without ever knowing what DNS is. He told me he spent a weekend getting it dialed in. That's a weekend well spent — on something that actually works, today, without waiting for ICANN to hold a public comment period.

The .self TLD is a proposal that correctly identifies a real pain point and then proposes solving it at the wrong layer of the stack. The infrastructure community deserves better than a moonshot that requires global institutional cooperation to deliver what a WireGuard mesh network can give you this afternoon.