On October 31, 2026, a Name.com account compromise gave attackers control over the DNS records for twelve DeFi applications. They didn’t need to break anything. They just changed where the domains pointed. By the time the account owners noticed, the attackers had redirected traffic to fake login screens, stolen funds, and moved on. Polymarket lost enough to require returning $3.9 million to affected traders. Others saw $138,000 in direct theft.
The registrar is your authentication perimeter
Your DNS registrar sits between you and the internet’s ability to find you. When you own a domain, your registrar controls what IP address that domain points to. If I control your registrar account, I control what your domain resolves to. If your domain resolves to my server instead of yours, then your users connect to me. I can present a login screen that looks identical to yours. I collect their credentials. I own your application. This is what happened with Name.com
The problem isn’t that Name.com‘s security is bad. The problem is that most teams don’t design as if the registrar is a security boundary. They treat it as a utility. Something external. Out of scope for their threat model.
It should never be out of scope. The registrar is the foundation of your entire authentication chain. If the registrar falls, everything built on top of it falls.
Why this is harder than it sounds
When you ask a team about their security perimeter, they usually point to their application servers, their database, maybe their CI/CD pipeline. They draw a boundary and say, “That’s what we protect.”
The registrar is on the other side of the line they drew. It’s somebody else’s responsibility. Or so the thinking goes.
But the registrar isn’t “someone else’s problem.” The registrar is where your identity lives. Your domain is how the world knows it’s actually you. If the registrar gets compromised, the attacker doesn’t need to compromise your servers. They don’t need your database. They just need your domain to point somewhere else.
Then your entire application is their application.
This creates a logical dependency that most architecture never names. Your threat model implicitly assumes: “An attacker cannot compromise our registrar account.” But registrar accounts are regular user accounts. They get phished. They get password-sprayed. They get compromised by employees with access. In the October incident, we don’t know exactly how the account was taken. At this point, it doesn’t matter.
What most teams are actually protecting
Most organizations have built a security perimeter around their application servers. They have firewalls, intrusion detection, WAF rules, rate limiting. They audit who can deploy code. They lock down database access. They’ve done the work.
Then someone compromises a registrar account, and none of that matters.
Here’s what the October incident actually exposed: Polymarket, and the eleven other compromised DeFi apps, had no account recovery mechanism that would stop a DNS hijack. When the attacker changed the DNS records, those applications became unreachable. The legitimate owners couldn’t easily reclaim them. No “pull the domain back” button that bypasses the registrar. No secondary authentication that would survive a DNS transition. No out-of-band verification.
They had to escalate to Name.com support, wait for the incident response process, and hope it moved fast. It doesn’t always. Users lost money in the gap.
The single points of failure you inherit
When you register a domain, you depend on several trust relationships all stacked on top of each other.
First, you trust the registrar account security. If the registrar account falls, the game is over.
Second, you trust the email address you used to register the account. If that email account gets compromised, the attacker can reset the registrar password using account recovery. The original account owner loses control.
Third, you trust any secondary authentication you’ve set up. Most registrars allow MFA. Many allow API keys with restricted permissions. But here’s the catch: you only protect what you remember to protect. If you have an API key sitting in an old CI/CD system, or a recovery code written down somewhere, or a second admin account that nobody remembered to lock, then the attacker finds the weak link.
Fourth, you trust the registrar’s API to be the true source of DNS authority. If an attacker gets API access, they own DNS. There’s no appeal to a higher authority. The registrar’s records are reality.
Most teams have built no defense-in-depth at this layer. They have one registrar account, one email backup, maybe MFA on the registrar itself. If any single component falls, the whole chain fails.
Why the architecture matters more than the incident
The Name.com compromise was an incident. Someone got into the registrar, made changes, and stole funds. Name.com responded, locked down the accounts, and helped mitigate the damage.
But the reason the incident was catastrophic wasn’t Name.com‘s security. It was that twelve separate applications had no architectural protection against registrar compromise. They’d assumed: “This is not something we need to defend against.”
A proper threat model for DNS-based identity should include: “What if the registrar account is compromised?” Once you include that threat, the architecture has to change. You need secondary verification that doesn’t depend on DNS. You need out-of-band ways to reclaim control. You need a control plane that survives the registrar being in an attacker’s hands.
Most applications don’t have that. They shouldn’t have been registering domains at a single registrar with a single account without multiple layers of access control.
The distributed trust problem
You can’t actually solve this problem by being more careful at the registrar. The issue is structural.
DNS is a critical infrastructure layer. It sits between your users and your application. The registrar is the single point of control. You don’t get to move that authority anywhere else. If your domain is myapp.com, then whoever controls the DNS records for myapp.com controls whether myapp.com resolves to your servers or to an attacker’s.
You can add MFA to your registrar account. You can rotate API keys. You can restrict who has access. All of that helps. But none of it changes the fact that a compromised registrar account equals a compromised application.
Other security layers are negotiable. You can move away from a compromised database. You can rebuild a server. You can rotate credentials and revoke access. DNS is different. Once the registrar falls, there’s no stepping back to a known-good state without the registrar’s help.
The real protection has to come from architecture. You need redundancy at the DNS layer. You need mechanisms to reclaim control that don’t depend on the registrar’s support process. You need to assume that, at some point, the registrar will be compromised.
What’s actually hard
Most people looking at the October incident draw the wrong lesson. They think: “We need better registrar security” or “We need to use a more reputable registrar.” These help but they don’t address the root issue.
The actually hard part is acknowledging that your registrar account is a critical-path security dependency, then building as if it might fail. That means rethinking how your application architecture depends on DNS. It means adding redundancy. It means out-of-band verification. It means accepting that DNS is not a utility layer. It’s an authentication layer, and it should be treated that way.
Your security plan should take that into account.