The .self TLD Launch: Why I'm Moving My Entire Stack to Self-Hosted Domains
The 379 HN upvotes on the .self TLD launch weren't just validation—they were a signal that the rental economy for digital identity might finally be ending. I've been paying domain registrars for namespace access for 15 years, renewing annually like some kind of digital tenant. Today I started the migration to own it.
The Philosophical Breaking Point
The .self announcement hit different than other TLD launches. Not because of the technology—though the peer-to-peer DNS resolution is clever—but because it crystallized something I'd been feeling for months. I was renting my digital identity from companies that could disappear, change terms, or simply decide my domain didn't comply with new policies.
The moment came when I was reviewing my annual domain renewal notices. Fifteen domains across three registrars, each with slightly different terms of service I'd never read. The math was straightforward: I was paying roughly $300 annually for the privilege of pointing DNS records at servers I already owned. What exactly was I buying?
There's a distinction I hadn't considered between "self-hosting" and "self-owning." I've been self-hosting services for years—my email server, API endpoints, even this blog runs on hardware I control. But the namespace itself? That's always been rented. The .self TLD offers actual ownership of the namespace, not just the servers underneath it.
My Migration Stack Breakdown
My current dependencies span six production domains across three registrars: Namecheap for the main blog and API domains, Google Domains for email infrastructure, and a smaller registrar for development environments. Each renewal cycle brings slight anxiety about policy changes or price increases.
The target architecture centers on .self domains with local DNS authority. Instead of delegating DNS to registrar nameservers, I'm running authoritative DNS locally. The technical shift is significant—I'm not just changing TLDs, I'm taking control of the entire resolution stack.
I started the migration with development environments because the stakes are lower. If my dev.self domain has propagation issues, I can fall back to localhost. The production email migration comes last—deliverability is too critical to experiment with.
What I didn't anticipate: the infrastructure requirements beyond DNS. Running authoritative nameservers means redundancy planning, monitoring, and backup strategies I hadn't considered. This isn't just changing a domain extension; it's becoming my own registrar.
Implementation Reality Check
The cost comparison surprised me. Annual registrar fees total around $300, but the .self infrastructure requires dedicated servers for DNS authority, monitoring systems, and redundant network connections. The break-even point isn't immediate—first-year costs will likely exceed traditional registration.
DNS propagation complexity hit harder than expected. Traditional domains propagate through established registrar networks with predictable timing. With .self domains, I'm building that propagation network from scratch. Initial resolution tests showed extended delays in some regions.
Browser compatibility emerged as a hidden consideration. Chrome and Firefox handle .self domains without issue, but older browsers and some enterprise environments flag them as invalid. The UX impact isn't theoretical—early testers reported confusion about "broken" links.
Traditional hosting still makes sense for certain services. CDN integration works seamlessly with established TLDs but requires custom configuration with .self domains. Email deliverability depends heavily on domain reputation, which new TLDs can't inherit.
The Ownership vs. Rental Mindset Shift
Thinking "I own this namespace" changes infrastructure decisions in subtle ways. With rented domains, I optimized for registrar compatibility and standard configurations. With owned namespace, I'm optimizing for long-term control and independence from third-party services.
The psychological difference between domain renewal anxiety and infrastructure maintenance is striking. Renewal anxiety comes from external dependency—someone else controls my namespace continuity. Infrastructure maintenance anxiety comes from technical complexity, which feels more manageable because it's within my control.
Digital independence in practice means accepting responsibility for components I previously outsourced. DNS resolution, namespace continuity, and certificate authority relationships all become my problem. The trade-off is eliminating external dependencies that could disappear or change terms.
Early Complications
Email deliverability with new TLDs presents immediate challenges. Major email providers treat unknown TLDs with suspicion, often routing messages to spam folders regardless of SPF/DKIM configuration. Building domain reputation takes time I can't accelerate.
SSL certificate automation required custom tooling. Let's Encrypt and other certificate authorities don't automatically recognize .self domains, breaking the automated renewal workflows I've relied on for years. Manual certificate management isn't sustainable at scale.
The chicken-and-egg problem of DNS authority during transition proved more complex than anticipated. I need working DNS resolution to validate the migration, but achieving working resolution requires completing the migration. The solution involves parallel systems during transition, doubling infrastructure overhead temporarily.
The .self TLD forces a fundamental question I've been avoiding: am I building on rented digital land because it's actually better, or just because it's easier? Six months from now, when this migration is complete or has failed spectacularly, I'll have an answer. Right now, I'm genuinely uncertain which way it'll go.