The domain name system has a chain of authority: registries operate top-level domains, registrars sell names to the public, and the registrar's records determine which name servers answer for your domain. Control any link in that chain and you control where the world finds you. Hijackers rarely attack the DNS protocol itself. They attack the accounts and support desks that administer it.
The attacks that actually happen
Registrar account takeover
The most common path is the least exotic: credential stuffing or phishing against the domain owner's registrar login. Once inside, the attacker changes the name servers, and within the TTL window the world's resolvers are sending your visitors, and your inbound email, wherever the attacker likes. In January 2021 this happened to perl.com, a 27-year-old domain in continuous use by the Perl community. It was transferred away without the owner's knowledge and pointed at a parking host; recovering it took weeks of escalation.
Social-engineering the registrar itself
Sometimes the account holder does everything right and the registrar's support desk is the weak point. In 2020, attackers repeatedly manipulated GoDaddy employees: in March a support agent was tricked into handing over control of escrow.com, and in November several cryptocurrency services had their DNS redirected after employees were phished. Your domain is only as secure as the process your registrar's most junior support agent follows on a busy day.
State-level campaigns against the DNS supply chain
In 2019 Cisco Talos documented a campaign it named Sea Turtle: a state-sponsored group that compromised registrars, registries, and DNS service providers to hijack the domains of ministries, militaries, and energy companies, primarily in the Middle East and North Africa. With DNS control, the attackers pointed mail and VPN hostnames at their own servers, obtained legitimate TLS certificates for the hijacked names, harvested credentials, and passed traffic through to the real services so nothing looked broken. The victims' own infrastructure was never breached. It did not need to be.
Certificate authorities validate domain control, not corporate identity, for the certificates almost everyone uses. An attacker who controls your DNS can pass that validation and be issued a genuine certificate for your name in minutes. The padlock will be real. Only Certificate Transparency monitoring gives the true owner a chance to notice.
Why email makes it worse
DNS control includes MX records, so a hijacker receives your inbound mail. That converts one compromise into many: password reset emails for every service tied to an address at the domain now arrive at the attacker's server. For an organization, that is the finance system, the code host, and the cloud console. For an individual with a personal domain, it is every account registered under it. The hijacker does not need your passwords when they can reset them.
Encrypted email narrows this specific hole. Password reset flows still fail open, but the historical mail sitting in an end-to-end encrypted mailbox stays unreadable to whoever controls the MX record, and new mail from other encrypted-mail users remains ciphertext at the rogue server. Transport encryption alone does not help here, since the attacker's server is a fully legitimate TLS endpoint for the stolen name.
The locks, from weakest to strongest
| Control | What it stops | Who sets it |
|---|---|---|
| Registrar lock (clientTransferProhibited) | Casual and automated transfer attempts; usually on by default | You, in the registrar dashboard |
| Strong 2FA on the registrar account | Credential stuffing and most phishing; prefer hardware keys over SMS | You |
| Registry lock (serverTransferProhibited, serverUpdateProhibited) | Changes made through a compromised registrar account or agent; unlocking requires an out-of-band verification ritual with the registry | Requested through the registrar; not all offer it |
| DNSSEC | Forged DNS answers in transit; does not stop an attacker who controls the registrar records | You, at the DNS host and registrar |
| CAA records + CT monitoring | Limits which CAs may issue for your name; alerts you when any certificate appears for it | You |
Registry lock is the control most owners of important domains have never heard of. It moves the final authority for changes out of the online dashboard entirely: even a fully compromised registrar account cannot move the domain, because the registry will not act without a manual, pre-arranged verification procedure. Major registries offer it, typically through business-tier registrars, for a fee that is trivial next to what the domain protects.
What individuals should take from this
You do not need to run a company for this to matter. If you own a personal domain and use it for email, that domain is your root credential, and the account protecting it deserves the same care as your password manager: a unique password, hardware-key 2FA where the registrar supports it, and the transfer lock on. Check the WHOIS contact address too, since an expired or hijackable contact mailbox is itself a takeover path.
It also matters when you are only a user. The hijacks above all end the same way: a legitimate-looking site at the right address with a valid certificate, run by someone else. The address bar cannot save you from that, which is one more reason to prefer systems where identity is proven by keys rather than by names alone. Key pinning, trust-on-first-use verification, and end-to-end encryption all keep working when the DNS lies, because they authenticate the party, not the label. DNS is the oldest trust layer on the internet and still one of the softest; the systems that survive its failure are the ones that never fully trusted it.