Domain Name Security: How the Controls Work

By Bill Hartzer, domain name expert and expert witness·August 10, 2026

Security Is a Stack, and Each Layer Has a Different Owner

A domain name feels like one asset. Operationally it is four, and each layer answers to a different party through a different process.

The registry — the operator running an entire top-level domain's master database (Verisign runs .com and .net). It holds the authoritative record of who sponsors your domain and where it delegates.
The registrar — the ICANN-accredited company you buy from, which talks to the registry using EPP (the Extensible Provisioning Protocol, the machine language registrars use to command registries). Your account there is the control panel for nearly everything else.
DNS hosting — whoever answers queries for your zone and serves the records inside it. Often the registrar, but not necessarily protected the same way.
Certificate issuance — the certificate authorities (organizations browsers trust to issue TLS certificates) that will issue for your name, governed by records in your DNS rather than by your registration.

Almost every serious domain incident I have looked at is a story about someone changing something at one layer while the owner watched another. The website is monitored; the registration is not. The registrar account has two-factor authentication; the DNS provider account does not. The domain is marked “locked,” and the lock turns out to be one the registrar removes on request — including at the request of whoever is inside the account.

The Rule That Decides Who Can Change What

The permissions in this system are published in the open, as EPP status codes — flags on the domain record in the registry database that permit or forbid an operation. Reading them is the fastest way to establish what protection a domain actually has, rather than what its control panel claims.

RFC 5731, the IETF standard defining how a domain object is represented in EPP, states the governing rule in section 2.3: “Status values that can be added or removed by a client are prefixed with 'client'. Corresponding status values that can be added or removed by a server are prefixed with 'server'.” Here the registrar is the client and the registry is the server. ICANN's reference page says the same thing plainly: client codes are set by registrars, server codes by registries, and server codes take precedence.

That prefix is the entire security boundary. clientTransferProhibited is a flag your registrar owns and can clear in a second. serverTransferProhibited is a flag your registrar cannot clear at all, because no valid command available to it would do so.

The Two Locks: One Your Registrar Owns, One It Does Not

Registrar lock is the free, usually default protection: client* flags telling the registry to refuse operations. ICANN's EPP status code reference defines clientTransferProhibited as telling “your domain's registry to reject requests to transfer the domain from your current registrar to another,” with clientUpdateProhibited and clientDeleteProhibited covering updates and deletions. The registry enforces those flags faithfully, and accepts your registrar's command to remove them a second later. The registry owns enforcement; the registrar owns the switch; the switch is usually a checkbox in your account. If an attacker is inside the account, it is a control they hold too.

Registry lock is sold by the registry operator itself and sets the server-prefixed equivalents. Verisign is explicit that all three are required — the words “server” and “prohibited” must appear for update, delete and transfer for a domain to count as registry locked. Two out of three is not registry lock.

Changing anything then requires a named, pre-registered individual at your registrar to contact the registry, which calls that individual back and requires an agreed security phrase before unlocking. That out-of-band step — confirming a request over a different channel from the one it arrived on — is the entire product. It takes the attack surface off the registrar's web console and API, so a stolen password, leaked API key or socially engineered support agent is not sufficient. ICANN's Security and Stability Advisory Committee has recommended it since SAC044 in 2010, as “a complement to registrar locks for a second level of security against unauthorized transfer, deletion or change.”

Verisign offers registry lock for .com, .net, .cc and .name; Nominet runs an equivalent Domain Lock for .uk. Availability is gated by your registrar rather than by you — it must hold the contract, the authorized-contact list and the process with the registry, which is why corporate registrars market it and most retail registrars do not offer it. Adoption is correspondingly low: a January 2020 survey of Fortune 500 domains found only 22 percent registry locked.

Everything Below the Registry Collapses Into One Account

Strip out the registry layer and every remaining control lives inside the registrar account: the lock toggle, the transfer authorization code, the nameservers, the registrant contact email where every confirmation goes. An attacker holding the account does not need to defeat those controls one at a time.

Account authentication is therefore the control that matters most below the registry, and the factor type matters within it:

SMS codes — exposed to SIM swap, where an attacker takes over your phone number. The weakest option.
Authenticator app codes — no SIM-swap exposure, but a six-digit code can be relayed by an adversary-in-the-middle phishing page that forwards your password and code to the real site as you type them. Commodity kits doing this are sold as a service.
Hardware security keys (FIDO2/WebAuthn) — the credential is cryptographically bound to the real site's origin, so a lookalike domain cannot obtain a usable assertion — the only widely available factor resisting real-time relay.

Be clear about the ceiling. Two-factor authentication does nothing against social engineering of the registrar's support desk — in the publicly reported theft of e-hawk.net in December 2019 the attackers never touched the owner's login, they persuaded registrar staff over a messaging app that they had bought the domain. It does nothing about API keys, which usually bypass interactive login, so a key committed to a repository is a full-access credential. And nothing about a weaker email account that can reset the registrar password, or a reseller whose security you inherit rather than control.

The DNS Layer Protects Answers, Not Ownership

DNSSEC signs your DNS records so a resolver can prove the answer it received genuinely came from your zone. It is a real control against forged answers and it is not an anti-theft control: an attacker who takes over your registrar account removes the DS record (the hash of your zone's key that the registry publishes in the parent zone) and repoints the domain cleanly, with no signature failure at all. DNSSEC protects the answers, not the ownership.

It also fails closed. A validating resolver that cannot verify the chain returns SERVFAIL, which to a user looks like the site does not exist, while users on non-validating resolvers see nothing wrong. That split is why DNSSEC incidents are so often misdiagnosed.

CAA records name which certificate authorities may issue for your domain. They are a policy signal to compliant authorities rather than a cryptographic barrier, and they say nothing about certificates already issued. One dependency is worth knowing: under CA/Browser Forum rules a CA may treat a failed CAA lookup as permission to issue only if, among other conditions, the zone has no DNSSEC validation chain to the ICANN root. Without DNSSEC, an attacker who can suppress your CAA lookup gets the certificate anyway.

Redaction Removed the Public Proof of Ownership

Since 2018, registration data has been redacted by default. ICANN's Registration Data Policy, effective 21 August 2025, carries that forward: registrant name, street, postal code and phone are redacted, and registry operators redact registrant and tech email. What stays public: the domain name, registrar and IANA ID, creation and expiry dates, domain status, and the registrar's abuse contact.

The trade-off cuts both ways. Publishing a registrant's home address and phone number invites harassment and targeted social engineering against the registrar account, the most common hijacking vector. But the same redaction that hides you from an attacker also hides you from a registrar reviewing your recovery claim. Public registration history used to supply, in one screenshot, a continuous chain showing who held the name. Now it reads “REDACTED FOR PRIVACY” before and after a theft alike, which distinguishes the rightful holder from the thief not at all.

Proxy services compound that: under a privacy service you remain the registrant, but under a proxy service the provider is the registrant of record and licenses the name to you. If you use either — and there are good reasons to — the price of admission is a private, dated ownership file: account records, renewal invoices, payment records, the original purchase or escrow record.

One mechanical note for tooling: since 28 January 2025, RDAP (the structured JSON successor to WHOIS) is the definitive source for gTLD registration data, and WHOIS is no longer required except for .com, .name and .post.

Detection Is a Control, Not a Report

Prevention buys a higher wall. Detection buys the one thing that reliably determines whether a stolen domain comes back: time. The window between an unauthorized change and someone noticing it is the variable recovery outcomes turn on.

The highest-value signals are registration-layer ones. pendingTransfer appearing when you did not initiate a transfer is the loudest alarm in the system. A *TransferProhibited or *UpdateProhibited code silently disappearing is better still, because lock removal is the precursor rather than the event. Nameserver changes, a change of registrar of record, and an approaching expiry date round out the list.

Two mistakes recur. The first is monitoring the website instead of the registration — by the time the site goes down, the transfer has usually completed. The second is treating the registrar's dashboard as the monitor, when a compromised account is the very scenario being monitored for; the attacker sees that dashboard and can change where its alerts go. Route notifications to a monitored, role-based mailbox on a domain other than the one protected. SAC044 said so in 2010, and it remains the most-ignored advice in the field.

A Defensible Baseline

In rough order of value:

Inventory every domain, its account, registrar of record, DNS host and responsible person — built from registration data rather than memory.
Put phishing-resistant multi-factor authentication on the registrar account, the DNS account, and the email account that can reset either.
Host the registrant contact email outside the protected domain and outside the registration account.
Set clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited wherever the registrar allows, then verify them in RDAP rather than trusting the control-panel label.
Add registry lock to every name whose loss would be material, locking nameserver host objects as well as the domain.
Treat API keys as passwords with authentication switched off: scope, rotate, and keep them out of repositories.
Monitor registration data, DNS and Certificate Transparency logs continuously, alerting on lock removal specifically.
Keep a dated ownership evidence file offline, current, and independent of anything the registrar holds.

Where a domain has already been moved, or a dispute is live, this stops being an operational question and becomes a legal one. Get counsel who has handled domain matters, before the trail cools.

Frequently Asked Questions

What is the difference between a client and a server EPP status code?

Client codes are set and removed by your registrar; server codes are set and removed by the registry operator, and they take precedence. RFC 5731 section 2.3 defines the convention: values a client can add or remove are prefixed “client”, and values a server can add or remove are prefixed “server”. Practically, a code beginning with “client” is a control your registrar holds and can clear at will, including on the instruction of anyone inside your registrar account. A code beginning with “server” is one your registrar cannot clear at all.

Does registry lock stop my domain from expiring?

No, and this catches people. Registry lock freezes the registration record against update, transfer and deletion. It does not renew the domain. A locked domain still expires, still enters the auto-renew and redemption grace periods, and can still be purged. ICANN describes the redemption period as holding a deleted domain for 30 days, after which it moves toward deletion. Expiry is the most common way domains are lost, it is entirely preventable, and no lock at any layer protects against it.

Is two-factor authentication on my registrar account enough?

It is necessary and it is not sufficient. Two-factor authentication defends the login. It does not defend against social engineering of the registrar's support desk, which is how e-hawk.net was taken in December 2019 without the owner's credentials ever being touched. It does not cover API keys, which usually bypass interactive login entirely. It does not cover a weaker email account that can reset the registrar password, and it does not cover a reseller's account security. For names whose loss would be material, add registry lock on top.

Does DNSSEC protect against domain hijacking?

Not against hijacking of the registration. DNSSEC signs the answers your zone gives, so a resolver can detect a forged or tampered response. An attacker who controls your registrar account simply removes the DS record at the registry and repoints the domain with new nameservers and new keys, and validation succeeds against the new configuration. DNSSEC is a strong control against on-path forgery and cache poisoning. It is not an ownership control, and it should not be counted as one in a security review.

Should I use WHOIS privacy on domains I might need to prove I own?

It is a real trade-off rather than an obvious yes. Privacy reduces harvesting, spam and targeted social engineering against your registrar account. It also removes the public record that used to demonstrate continuity of ownership, and after 2018 that record is largely redacted regardless of what you choose. My view is that privacy is usually correct and the cost has to be paid separately: maintain a private, dated ownership file of account records, invoices, payment records and periodic registration-data snapshots.

How do I check what protection a domain actually has?

Query the registration data directly through RDAP, which since 28 January 2025 is the definitive source for gTLD registration data, and read the status codes yourself. For registrar lock, look for the client-prefixed prohibitions. For registry lock, all three of serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited must be present. Do not rely on a padlock icon or a “Locked” label in a control panel; those almost always indicate registrar lock, and sometimes only the transfer flag of it.

Domain Name Security