Support Library
Domain Hijacking and Registry Lock
Domain hijacking is when an attacker gains control of a domain registration and changes its name servers or owner. Registry lock is a registry-level freeze that makes those changes require out-of-band human verification.
The short answer
Your domain registration is the root of everything else you run on the name. Whoever controls it decides which name servers are authoritative, and whoever controls the name servers decides where web traffic, email and certificate validation go. Domain hijacking is the act of taking over that control, usually by breaking into the registrar account or talking a support agent into making a change. The attacker then points the domain at their own name servers, and from that moment every resolver on the Internet follows the new delegation.
Registrars offer a basic transfer lock, but it lives inside the same account an attacker would compromise. Registry lock moves the protection one level up, to the registry that runs the top-level domain, and requires a human verification step outside the normal control panel before anything important can change.
Client locks stop accidents and casual attacks. Server locks, applied through registry lock, stop an attacker who already has your registrar password, because the registrar cannot lift them without an out-of-band check.
How domain hijacking happens
Very few hijacks involve breaking cryptography. Most exploit the people and accounts around a registration. The registrar is the company you pay to manage the name, and it talks to the registry on your behalf over the Extensible Provisioning Protocol, or EPP. If you are unsure how those roles fit together, start with What Is a Domain Registrar?
| Attack path | What the attacker does | Typical result |
|---|---|---|
| Registrar account takeover | Phishes or reuses a password, or bypasses weak multi-factor authentication | Changes name servers or starts a transfer out |
| Password reset through email | Takes over the contact mailbox, sometimes by registering an expired domain used for that mailbox | Resets the registrar password and logs in legitimately |
| Social engineering | Convinces registrar support to change contact details or name servers | Change made by a real employee, so it looks routine in logs |
| Unauthorized transfer | Obtains the transfer authorization code and moves the domain to another registrar | Owner loses access to the registration entirely |
| DNS hosting account takeover | Logs in to the DNS provider rather than the registrar | Records changed inside the zone while delegation stays the same |
| Expiry and re-registration | Waits for the domain to lapse and registers it after deletion | A new, legitimate owner who is not you |
The last two rows are not strictly registration hijacks, but they produce the same outcome for users and need different defenses. A name server change is the most powerful move because it replaces the whole zone in one step. Attackers commonly follow it by requesting a TLS certificate for the domain, since domain validation now succeeds for them, and by redirecting MX records to read incoming mail.
EPP status codes: client locks vs server locks
Every domain in a gTLD registry carries status values defined in RFC 5731, the EPP domain name mapping. ICANN publishes a plain-language explanation of each one on its EPP status codes page. The statuses come in two families. Statuses starting with client are set and removed by the registrar, usually when you click a lock toggle. Statuses starting with server are set and removed by the registry.
- clientTransferProhibited and serverTransferProhibited block transfers to another registrar.
- clientUpdateProhibited and serverUpdateProhibited block changes to the registration, including name servers, contacts and DS records.
- clientDeleteProhibited and serverDeleteProhibited block deletion.
- clientHold and serverHold remove the domain from the TLD zone, so it stops resolving. These are not protections, and seeing one unexpectedly is a warning sign.
You can read the statuses with WHOIS or with RDAP, the structured successor described in WHOIS vs RDAP. RDAP uses spaced, lower-case names for the same statuses, mapped in RFC 8056. The output below is illustrative of a domain with both client and server locks set.
$ whois example.com | grep -i "domain status"
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited
$ curl -s https://rdap.example.net/domain/example.com | jq '.status'
[
"client delete prohibited",
"client transfer prohibited",
"client update prohibited",
"server delete prohibited",
"server transfer prohibited",
"server update prohibited"
]The RDAP server address above is a placeholder. In practice you look up the right RDAP service for the TLD in the IANA bootstrap registry, which most RDAP clients do for you.
What registry lock actually does
Registry lock is a service, not a protocol feature. The registry sets the three server*Prohibited statuses on your domain at the registrar's request, and agrees with the registrar on a separate procedure for lifting them. That procedure typically involves named, pre-registered contacts at your organization, a passphrase or call-back, and a manual action by registry staff. The details differ by registry and registrar, not every TLD offers it, and it usually costs extra.
a name server change
an authorized contact
server locks out of band
locks set again
The value comes from that out-of-band step. An attacker who steals your registrar password can remove client locks in seconds, but cannot phone the registry as your named contact. The cost is speed: every legitimate change to name servers or DS records now takes a planned window instead of a click.
What locks do not protect
Registry lock protects data held by the registry. It does nothing for data held elsewhere, and that boundary catches people out.
- Records inside your zone. If your zone is hosted by a DNS provider, an attacker in that account can change A, MX or TXT records without touching the delegation. Protect the DNS hosting account with the same care as the registrar account.
- Expiry. A locked domain still expires if nobody pays for it. Use auto-renew, multi-year terms and a payment method that will not silently lapse.
- Planned changes. Because serverUpdateProhibited also blocks DS updates, a locked domain needs the unlock procedure for KSK rollovers and DNS provider moves. Build that into runbooks such as DNSSEC Key Rollovers (ZSK and KSK) and Moving DNS Providers Without Downtime.
- Subdomains you forgot. A locked parent domain can still have a dangling CNAME that someone else claims, as covered in Subdomain Takeover Attacks: What They Are and How to Stop Them.
Decide which domains are critical, such as the one that carries your login pages, mail and API endpoints. Put registry lock on those, and accept slower changes as the price of a much smaller attack surface.
A hardening checklist
- Turn on phishing-resistant multi-factor authentication, such as hardware security keys, for every registrar and DNS hosting account.
- Give each person their own login with the least privilege the registrar allows, and remove leavers promptly.
- Make sure the contact email lives on a domain you control and keep renewed, not on the domain it protects.
- Enable client locks everywhere and registry lock on critical domains.
- Keep transfer authorization codes out of tickets and chat, and regenerate one if it has been shared.
- Monitor name servers, DS records and RDAP status values, and alert on any change you did not schedule.
- Watch Certificate Transparency logs for certificates you did not request, as described in Certificate Transparency for DNS Discovery.
A simple scheduled check catches a lot. Compare the delegation the TLD publishes against the list you expect:
$ dig +norecurse +noall +authority @a.gtld-servers.net example.com NS
example.com. 172800 IN NS ns1.dns-provider.example.net.
example.com. 172800 IN NS ns2.dns-provider.example.net.
$ dig +norecurse +short @a.gtld-servers.net example.com DS
12345 13 2 3B1F5E0C4A9D7E2B8C6F1A0D9E8B7C6A5F4E3D2C1B0A9F8E7D6C5B4A3F2E1D0C| Part of the command | Why it is there |
|---|---|
| @a.gtld-servers.net | Asks a .com registry server directly. Use one of your own TLD's servers, which dig NS com lists. |
| +norecurse | Asks for the server's own data only, as a resolver would |
| +noall +authority | Prints the authority section. The TLD does not answer NS questions for your domain; it returns a referral, and the delegation is in that section. +short only prints answers, so it would show nothing. |
| DS with +short | DS records belong to the parent zone, so the TLD returns them as an ordinary answer |
Asking the TLD server directly avoids resolver caches, so you see the delegation as it is now rather than as it was when the TTL started.
How DNS Panopticon helps
Website Recon looks the domain up in RDAP for its registrar and registration dates, and flags risk signals such as a hold status or a very recently registered domain. That makes it a quick way to confirm which registrar holds a name before you contact them, and to spot a hold you did not expect. It also shows the name servers that public resolvers return, so an unexpected provider in the results is worth investigating. Recon reads RDAP and public DNS; it cannot see your registrar account, so it does not show who changed something or when the lock was last used.
Domain Visualizer scans public DNS through public resolvers and reports delegation and DNSSEC findings alongside other categories. Results are cached for a period set by the site (24 hours by default), so check the scan time on the result when you compare before and after a change. Run it before and after any planned registry-lock change window to confirm that the delegation and DS records match what you intended. If you keep a zone export as your source of truth, Zone Analyzer lets you review it locally, and Domain Visualizer shows what resolvers actually see.
FAQ
Is the default registrar transfer lock the same as registry lock?
No. The default lock sets client statuses such as clientTransferProhibited, which anyone who logs in to the registrar account can remove. Registry lock sets server statuses at the registry, and removing them needs an out-of-band verification step between the registrar and the registry.
Does registry lock stop an attacker from changing my A records?
Not if your records are hosted at a DNS provider. Registry lock protects the registration data held by the registry, such as name servers, DS records, contacts and transfers. Records inside your zone are protected by the security of your DNS hosting account.
How do I check whether a domain has registry lock?
Look up the domain with RDAP or WHOIS and read the status values. A domain under registry lock usually shows serverUpdateProhibited, serverTransferProhibited and serverDeleteProhibited, often alongside the matching client statuses.
Sources and further reading
- ICANN: EPP Status Codes, What Do They Mean, and Why Should I Know?: the server*Prohibited statuses behind registry lock
- ICANN SSAC: SAC040, Measures to Protect Domain Registration Services Against Exploitation or Misuse
- ICANN SSAC: SAC044, A Registrant's Guide to Protecting Domain Name Registration Accounts
- CISA: Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering
- ISC: dig manual page: query options such as +norecurse and +noall