Domain Security: How Domains Are Stolen, and What Stops It

What you are actually defending

ICANN's Security and Stability Advisory Committee put the problem in one sentence: all an attacker needs to gain control of an organisation's entire domain name portfolio is a user account and password. A domain is defended as three things at once, being a registrar account, the mailbox that can reset that account, and the delegation record held at the registry. An attacker needs to win only one of them.

Every control below appears in a WHOIS or RDAP lookup as an EPP status code, and the prefix is the whole game. Codes beginning with client are set by your registrar and can be removed by your registrar, which in practice means by anyone holding your credentials. Codes beginning with server are set by the registry, take precedence, and cannot be lifted by the registrar alone.

Registrar lock: free, sensible, and limited

Registrar lock is the status clientTransferProhibited: a flag your registrar sets instructing the registry to refuse inter-registrar transfer requests. It costs nothing, is on by default at most registrars, and you can remove it yourself when you genuinely want to transfer. The SSAC's 2005 hijacking report identified the absence of registrar lock as one of two available safeguards that went unused in the panix.com case.

Its limit is precise. Because you can lift it in two clicks, so can whoever has your password. It stops a transfer initiated by someone holding an auth code, the per-domain key that authorises a transfer between registrars, but not your account. It does not stop anything done from inside your account, does not stop deletion or nameserver changes, and does not stop a support agent acting on a caller's say-so.

Two companion codes matter more than most registrants realise. clientDeleteProhibited blocks deletion. clientUpdateProhibited freezes contacts and nameservers, and is arguably the most significant of the three for a live business, because DNS redirection rather than transfer is the fast path in most modern hijackings. It is also the one most registrars leave off by default, since it makes every legitimate DNS change require an extra step.

Registry lock: the only control credential theft cannot defeat

Registry lock is a paid, manual, high-assurance service in which the registry applies all three server-side prohibitions, being serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited, and lifts them only after out-of-band human verification with a named, pre-authorised individual. No API call, no control-panel toggle and no stolen password can change the domain while it is in force.

Verisign's service covers .com, .net, .cc and .name. An authorised registrar representative submits an unlock request, Verisign telephones that individual, and they must supply an individual security phrase before the domain is unlocked; all three server statuses must appear in the lookup for the domain to be fully locked. Nominet's Domain Lock for .uk works on the same principle: once a domain is locked, no changes can be made to it or its DNS configuration until the lock is removed, and unlocking uses repeated two-factor validation by a pre-authorised representative across separate devices.

Nominet positions it for high-profile brands and financial services. Availability varies by registry, and the service is usable only if your registrar participates, since it must be set up to submit and authenticate unlock requests. Ask which extensions yours can lock rather than assuming. The trade-off is friction: an emergency change needs a phone call and a human in business hours, which is exactly what makes it secure and exactly what makes it unsuitable for a domain whose DNS changes hourly. Examining the hijacking of google.com.vn, SAC074 observed simply that the domain was not protected with a registry lock.

Two-factor authentication, and the mailbox behind it

SAC074 defines multi-factor authentication as combining at least two methods of proving identity from three categories: something you know, something you have, and something you are, and recommends that accreditation deliberations encourage stronger authentication practices. This is the highest-leverage control most readers can turn on today, and it is free. One-time codes delivered by SMS fall inside that definition but are the weakest form, given SIM-swap and interception risk; an authenticator app or hardware key is materially stronger, though that ranking is general security practice rather than a stated ICANN position.

The registrant and account email address is the recovery channel for the registrar account, which is the control channel for the domain. Whoever holds that mailbox can reset the password and take the domain, without defrauding anyone and using flows working exactly as designed. Registrar 2FA in front of a mailbox with no 2FA of its own is decorative. SAC074 identifies two non-obvious failures: self-referential recovery, since it is not safe to send credential recovery instructions for a domain to an address within that domain when an attacker who has redirected your MX records receives your own reset messages; and the abandoned mailbox, which lapses through disuse or because the domain it sits on expired, letting an adversary who acquires it use the forgot-password process. SAC007 documents attackers registering expired domains belonging to administrative contacts precisely to intercept reset email, and found that registrants who let registration records go stale are more vulnerable generally.

What follows is concrete. Put the account email on a different domain from the one it protects, at an independent provider. Make it a monitored role address that more than one person can reach, so the domain does not become unrecoverable when an employee leaves. Give it its own 2FA. Redaction under ICANN's Registration Data Policy keeps the address out of public lookups but does nothing for the security of the mailbox, and registrants must still answer registrar enquiries about that data within fifteen days.

DNSSEC: what it signs, and how it takes sites offline

DNSSEC adds data origin authentication and data integrity to DNS using digital signatures. A resolver holding a zone's verified public key can confirm an answer came from that zone unaltered, and it provides authenticated denial of existence, so an attacker cannot silently strip records out of a response. Four record types do the work: RRSIG for signatures, DNSKEY for public keys, NSEC for authenticated non-existence, and DS, the delegation signer record published in the parent zone that links the chain of trust. DS is the piece registrants actually touch, entered through the registrar and published by the registry, which is why DNSSEC breaks when someone changes DNS host without coordinating it. What it defeats is cache poisoning and forged responses, including the attack in which a false address record sends your traffic to a server the attacker controls; responding in 2019 to a documented pattern of unauthorised changes to the delegation structure of domain names, ICANN described DNSSEC as technology developed to protect against exactly those changes.

What it does not do matters as much. It is not encryption and provides no confidentiality, by deliberate design, so queries remain visible to anyone on the path. It does not protect content: a signed domain can still host malware, and a validly signed answer can still point at a compromised server. It gives no protection against denial of service, and adds new denial-of-service vectors through cryptographic cost. It does not secure zone transfers, which need TSIG or IPsec.

The counterweight is that DNSSEC is fail-closed by design. A validating resolver that cannot verify a signature returns SERVFAIL, and to the user the domain simply does not exist. On 18 January 2012 the signatures on nasa.gov were no longer valid, validating resolvers correctly refused to answer, and the site was unreachable for approximately 17.8 million customers of one large ISP. In March 2015 hbonow.com had a DS record at the .com registry with no matching key in the zone, and validating networks refused to resolve it until the domain was returned to unsigned. The root cause was identified as the manual, error-prone process for updating DS records between DNS operators and registries, and the pattern is always the same: DS record and key out of step during a rollover or a change of provider. Remove the DS record and wait out its TTL before migrating, prefer providers that automate DS management, and monitor validation from outside your own network.

CAA: constraining who may issue a certificate

A CAA record declares which certificate authorities may issue TLS certificates for your domain. Checking it has been mandatory for publicly trusted CAs since 8 September 2017, when the CA/Browser Forum passed Ballot 187, so a record naming only the CAs you use causes a mis-validated request to any other publicly trusted CA to be refused at source.

Its limits should be stated plainly. It does not prevent mis-issuance by a CA you have authorised. It is not consulted by browsers at connection time, because enforcement happens before issuance rather than during a visit. And without DNSSEC, an attacker able to spoof the DNS responses the CA sees can suppress it. The practical failure is self-inflicted: publish a record that omits the automated CA inside your CDN or hosting platform, and you find out when a renewal fails.

Two routes in through people

Social engineering the registrar's support desk. The attacker impersonates the registrant, persuades an agent to change the administrative contact email or reset the password, then changes nameservers. On 24 April 2005 this was done to hushmail.com: support staff were convinced to change the administrative contact address, the password was reset, DNS was modified and the site was defaced. Recovery took 16 hours, and was only possible because the billing contact had not been changed. In June 2008 a sophisticated combined social and technical attack altered DNS for multiple ICANN domains, routing traffic to defacement sites for 24 to 48 hours. Registry lock is the only control that reliably stops this, since out-of-band verification against a pre-registered individual and security phrase is not something a support agent can bypass. Secondary measures: multi-factor authentication for contact changes, and change notifications delivered over more than one channel.

Compromise of the registrant email account. Phishing, credential stuffing, a reused password, a SIM swap, or registering the lapsed domain the contact address sits on, followed by the registrar's ordinary forgot-password flow. No registrar is defrauded and everything looks legitimate. The controls are 2FA on the mailbox itself, a recovery address on an independent domain and provider, a monitored role mailbox, and registry lock as the backstop, since it blocks changes even from a fully authenticated session.

Both routes now usually end in the same place. ICANN's alert of 15 February 2019 described a global campaign of DNS record manipulation across multiple sectors and extensions, naming credential compromise, registrar and registry account takeover, and direct record modification as the vectors. Its checklist covered password policy, verification of DNS record integrity and change history, DNSSEC, multi-factor authentication for administrator access, and email authentication. Often the domain is not stolen at all, only redirected briefly, which is long enough to obtain a certificate.

Two routes in through process

Unauthorised transfer. On 14 January 2005 panix.com was transferred between registrars without its owner's consent, after a reseller submitted an unauthenticated transfer request. The gaining registrar changed the nameservers, disrupting service for thousands of customers. The owner discovered the changes at 1:00 a.m. on 17 January, and recovery took over 40 hours, hampered by time zones and the absence of emergency contact procedures. The SSAC identified two failures: the losing registrar never notified the registrant of the pending transfer, and the domain was not protected with registrar lock. Registrar lock blocks this outright, and registry lock adds the server-side prohibition on top. Responding to transfer confirmations matters, because a non-response defaults to approval after five calendar days, and the auth code should be treated as a credential.

Lapsed renewal caught on the drop. Renewal notices go to a mailbox nobody reads, or a stored card expires. The domain expires, is eventually deleted, and specialist drop-catch services compete to register valuable names at the instant of release. ICANN's Expired Registration Recovery Policy requires at least two reminders before expiry, roughly a month and roughly a week beforehand, plus a further notice within five days after expiry, and obliges the registrar to interrupt DNS resolution at expiry. After deletion, gTLD registries other than sponsored ones must offer a 30-day Redemption Grace Period in which the registrant at expiration can restore the name, with DNS disabled and transfers prohibited throughout.

The prevention is unglamorous: auto-renew on a monitored payment method not tied to one individual, multi-year registration, renewal notices going to a role address on an independent domain, and calendar reminders that do not depend on registrar email reaching you. Note that clientDeleteProhibited prevents deletion but not expiry. And once a name has legitimately dropped and been re-registered by someone else, this is not a hijacking in any actionable sense: no registrar dispute is available, and your only routes are commercial negotiation or, where you hold trademark rights, a UDRP complaint.

What to do first, in order

Ranked by risk removed against effort spent, with the free measures first:

• Turn on 2FA at the registrar and on the mailbox behind it. Free, immediate, and it closes the two commonest routes in. Prefer an authenticator app or a security key to SMS.
• Move the account and registrant email to an independent, monitored role address on a domain other than the one it protects, then confirm that renewal notices arrive there.
• Set auto-renew on a monitored payment method, and add your own calendar reminder that does not depend on registrar email. Expiry costs more organisations their domains than attackers do.
• Enable the client locks: clientTransferProhibited, clientDeleteProhibited and, where you can tolerate the extra step before every DNS change, clientUpdateProhibited.
• Buy registry lock for the names the business cannot survive losing. It is the only control that survives a compromised account or a deceived support agent.
• Publish a CAA record naming every CA you use, including the automated one inside your platform or CDN.
• Monitor. Alert on changes to your delegation, your records and your status codes; every incident above was survivable in proportion to how quickly it was noticed.
• Deploy DNSSEC once you can manage DS records through key rollovers and provider changes, and not before, because the failure mode is a total outage rather than a degraded one.

The uncomfortable summary is that the single control covering the widest range of attacks is also the only one that costs money and slows you down. Everything above it on that list is free, and most organisations have not finished doing it.