I’ve spent roughly twenty years watching systems fail. Not theoretically. Actually. Networks that were “enterprise-grade.” Authentication schemes that were “industry-standard.” Custody arrangements that were “legally robust.” The pattern I keep seeing is the same: the people inside the system never ask the foundational question, because the system appears to be working fine. The question is: working fine, controlled by whom?
Naming is the place where almost nobody asks that question. You register a domain. It resolves. You move on. But the moment something goes wrong — a lapsed renewal, a government warrant, a registrar implosion, a sanctions designation that catches your TLD in its blast radius — you discover that the name you thought you owned was never really yours to begin with.
Let’s pull the thread.
The Chain You Don’t See
When you register a domain, you’re not buying a piece of property. You’re renting a database entry, sitting inside a layered hierarchy you have essentially no control over.
Registrars act as intermediaries between registrants and the registry. They receive and process domain reservation requests, while registries in turn receive and process requests from registrars and provide the interface to maintain operation of customer-registered names. Above the registry sits ICANN, which coordinates the allocation and assignment of names in the DNS root zone and develops and coordinates the implementation of policies for registering second-level domain names in generic top-level domains.
So the chain looks like this: you → registrar → registry → ICANN → the jurisdiction in which any of those entities operate. That last part is the one people consistently underestimate.
Traditional database-based domain registrars have control over domain names stored in their centralized databases — so while a user can contact a traditional registrar to reset credentials or modify DNS records, the traditional registrar has ultimate control. You are not the owner of record in any meaningful technical sense. You are a customer of a company that is itself a customer of another company, all operating under agreements and accreditations that can be revoked, modified, or overridden by forces entirely outside your control.
That’s not a conspiracy. That’s just how it was built.
The Ways a Name Dies
Here’s the taxonomy I use when thinking about DNS risk. There are five failure modes, and I’ve personally seen versions of all five.
1. Expiry
The simplest and most embarrassing. One of the first famous cases of domain non-renewal was Microsoft’s passport.com at the end of 1999 — the domain was renewed by a vigilant user, who was reimbursed shortly after by Microsoft. The same story repeated in October 2003 with hotmail.co.uk. Other major organizations, including Foursquare in 2010 and Google Argentina in April 2021, failed to manage domain renewal properly. These are companies with legal teams and IT operations and presumably calendars. Nobody is immune to administrative failure, and when the domain expires, it can be snapped up in a matter of seconds by speculators.
2. Registrar Failure
In 2007, a registrar called RegisterFly imploded. RegisterFly’s customers in many cases lost their domain names after the company took money two or three times for renewals before failing to renew their domains. This put the roughly 900,000 domain names they managed at risk. RegisterFly held customers hostage by not providing “auth codes,” by arbitrarily locking domain names, and by changing WHOIS info — and production websites went dead, redirecting to a RegisterFly parking page instead. RegisterFly’s debacle ruined businesses and lives.
The system had a theoretical safety net — ICANN could revoke accreditation. But the only thing ICANN could do to keep a registrar in line was threaten de-accreditation, a power it was reluctant to exercise until RegisterFly was already falling apart at the seams. By then, the damage was done. The domains were gone. RegisterFly was the first ICANN-accredited registrar to ever lose accreditation. It would not be the last.
3. Government Seizure
In cases where the registration of a domain name is to be transferred away from a party named in a legal or regulatory action, the legal or regulatory action transfers the domain name registration to law enforcement or an agent operating on behalf of law enforcement. This happens fast, and often without warning. Seizure warrants are routinely obtained under seal and without notice to any of the users or operators of the domains, and are not unsealed and announced until days later.
As in multiple rounds of seizures by U.S. Immigration and Customs Enforcement, these warrants were issued ex parte — without the participation of the owners of the domain names or the websites operating there. On 15 February 2012, a domain name registrar suspended name service for Jotform.com, an online forum for web forms creation and sharing. Jotform claims it did not receive notice of a court order, but was informed by the registrar that the site had been suspended as part of an ongoing investigation.
Many seized domains never return to their owners. In some cases, authorities keep them indefinitely, making legal recourse challenging.
4. Sanctions Blowback
This one is subtle and growing. It’s not just that your domain can be seized because you are sanctioned. It’s that your domain can be caught in the crossfire because of where your registrar operates, or because the registry managing your TLD has U.S. nexus, or because an OFAC filing lists an address on the same TLD you use.
Registries and registrars operating from places as distinct as the EU, Russia, Argentina, or Taiwan can be punished for transacting with individuals and entities included in OFAC lists. For this very reason, many registries and registrars preemptively block all transactions with targets of sanctions even without being officially bound to OFAC rulings.
The operational proof arrived in July 2026. OFAC’s July 13 sanctions filing against a cybercriminal VPN service listed a t.me channel URL as a contact address — prompting the .me registry to apply a serverHold that knocked every Telegram short-link offline for 19 hours. Think about that. An entire platform’s URL infrastructure went dark for nearly a day because a single SDN filing included a URL on the same registry. For any platform that routes public-web access through a single short-link domain, particularly a ccTLD or gTLD operated by a registry with U.S. nexus, the lesson is immediate and operational.
5. Policy Change
The registrar agreement you signed today is not the agreement you’ll be operating under in five years. ICANN policies evolve. Registrar terms change. TLD operators can add use-case restrictions. Hosting providers change their acceptable-use policies. None of these require notice to you in advance, and none of them require your consent. Your domain lives inside a policy stack that you did not write and cannot unilaterally amend.
Why the Fragility Is Invisible
Here is the thing I’ve noticed after two decades in security: the most dangerous failure modes are the ones that are invisible during normal operations. DNS works beautifully until it doesn’t. You type a URL, the page loads, everything is fine. Nothing in that transaction reveals how many parties, jurisdictions, and policy frameworks stand between you and that resolution.
The fact that a registrar not based in the U.S. might prohibit registrants in sanctioned countries from using its services is concerning. If non-U.S. registrars have to comply with U.S. laws because of their contractual relationship with ICANN, then ICANN’s jurisdiction could be interfering with the global interoperability and openness of the DNS.
You don’t see the jurisdiction exposure when you’re registering a .com. You don’t see that the .com TLD is controlled by Verisign in the U.S. You don’t think about what happens if your registrar’s executives start a legal war with each other and the customer support goes dark. You don’t notice that the name you’ve been building your identity around is, technically, a database entry inside a system controlled by parties you’ve never met, operating under agreements you’ve never read, subject to laws that might not be your laws.
The visibility arrives at the worst possible moment: when you need the name most and it’s gone.
What Changes Onchain
When a name is an onchain asset you hold in a wallet you control, the control structure is fundamentally different.
Under the hood, ENS relies on a smart contract registry that records who controls each name. To get a name, users register it directly. Ownership changes are recorded on-chain in the registry, while resolver contracts translate human-readable names into machine-friendly addresses. Together, the registry and resolvers enable a trust-minimized naming system without a central operator.
Each .eth name is minted as an ERC-721 NFT, ensuring verifiable, on-chain ownership. This is not a cosmetic difference. It means the ownership record is not stored in a registrar’s database that can be locked, modified, or handed to law enforcement without your knowledge. Since ENS is controlled by smart contracts, there is no need for middlemen, and the user retains ownership.
ENS domains are owned by your wallet, making them resistant to takedowns or hacks unlike centralized DNS. You own your .eth domain. It’s not rented from some Web2 registrar. You can sell it, lease it, use it, or build your online presence around it — all without asking permission.
The contrast with the traditional system is structural. In DNS, status serves as an access control over whether or not the registration of a domain name can be transferred, modified, or deleted — and a legal or regulatory order specifies the status a registrar or registry should assign to the domain names listed in the action. That lever — the ability to flip a status flag and kill your name — simply does not exist in the same form when ownership is enforced by cryptographic state on a public chain.
Websites linked to ENS domains on IPFS cannot be easily taken down, promoting freedom of expression. That’s not a feature for people doing something wrong. That’s resilience for anyone whose digital identity depends on continued availability, regardless of what third parties decide.
The Security Lens on Naming
I think about naming the way I think about any critical infrastructure: who can take it from you, how quickly, and with how much notice? That’s the OSINT threat model applied to your own identity.
In traditional DNS, the answer is sobering. A single court in the right jurisdiction can issue an ex parte warrant. A registrar’s backend can be compromised. A policy change at ICANN can affect your TLD. Registries and registrars decide to preemptively block all transactions with targets of sanctions — including registries for ccTLDs located in Honduras and the Channel Islands that explicitly state they will not provide any services to those on OFAC lists. The blast radius of sanctions, legal orders, and registrar failures is wider than almost anyone models.
Monitoring EPP status codes through WHOIS or RDAP feeds for critical domains, maintaining an alternate domain on a registry with different jurisdictional exposure, and establishing a documented escalation path with the registry operator are among the most concrete mitigations available under the current DNS framework — but none of them fully addresses the underlying structural problem, which is that enforcement format and the EPP protocol were built for entirely different purposes and have never been formally reconciled.
That’s the real answer the traditional system offers to sophisticated users who’ve mapped the risk: monitor, have a backup, know your escalation path. None of those mitigations return control to you. They just marginally improve your odds of detecting a problem and reacting before total loss. That’s a defensive posture built on borrowed time inside someone else’s system.
A State Should Not Accept This Fragility
If you’re an individual, the stakes are your brand, your communications infrastructure, your digital presence. That matters.
If you’re a State — a sovereign entity whose digital identity is itself part of what it means to exist and transact in the world — the stakes are categorically different. Your domain name is how you are found. It’s how you communicate with citizens, partners, counterparties, and institutions. It’s how you publish. It’s part of your sovereignty made legible on the internet.
And under the traditional system, a State’s domain can be seized by a foreign court, knocked offline by an SDN filing that catches the wrong registry, lost to a registrar’s internal dysfunction, or quietly made unavailable by a policy change at a California-based non-profit operating under U.S. jurisdictional pressure.
The question isn’t whether these events are likely. The question is whether a State should accept that they are possible at all — that the technical infrastructure of its digital identity is fundamentally contingent on the goodwill, operational competence, and political neutrality of third parties it has no contractual leverage over.
I wouldn’t accept that for my own infrastructure. The answer, for a State, should be the same.
The Honest Caveats
I said no selling, so let me say the thing nobody in the onchain naming space says loudly enough: self-custody is a responsibility.
When you hold a key, you hold the risk. There is no helpdesk to call when you lose your wallet. There is no registrar who can verify your identity and restore your access. Always use hardware wallets and enable 2FA is the bottom of every ENS explainer, and it’s there because the threat model has shifted — from “will the system betray you?” to “will you manage your own keys competently?”
That’s a better problem to have. It’s a problem you can solve through process, tooling, and operational discipline. You cannot solve the registrar failure problem through personal discipline. You cannot solve the ex parte seizure problem through good key hygiene. The category of threats that self-custody eliminates is larger than the category of threats it introduces — but you still have to take the introduction seriously.
At its core, onchain naming is decentralized infrastructure that turns cryptographic addresses into persistent, user-owned digital identities. Persistent and user-owned. Both words matter. Persistent means nobody else’s operational failure takes it down. User-owned means the responsibility for keeping it alive is yours.
That’s the honest trade. And for anyone who has spent time watching the ways the traditional system fails, it’s a trade worth making.
kooky has been studying how systems fail — technically, operationally, and politically — for two decades. The naming question is, in his view, one of the clearest examples of critical infrastructure risk that most people don’t think about until it’s too late.