DNS Hijacking: How It Works and How to Respond

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

What a hijack actually changes

DNS hijacking is the alteration of the Domain Name System records for a domain — or of the nameservers the domain is delegated to — so that traffic meant for your website, your email or your VPN is answered by a server the attacker controls. The registration itself is often untouched. Whois still names you. Nothing has been transferred. The domain has been redirected, and that is a different problem with a different clock on it.

The records in question are ordinary ones. An A record maps a hostname to an IPv4 address, so editing it moves your website. An MX record tells other mail servers where to deliver your email, so editing it moves your inbound mail. An NS record — the delegation — names the authoritative servers for the domain, so editing it moves everything at once. CISA's Emergency Directive 19-01 names exactly these three record types as the ones tampered with in the campaign that prompted it, after which valid encryption certificates were obtained for the affected domains, allowing the redirected traffic to be decrypted and exposing user-submitted data (CISA ED 19-01).

Because the registration is intact, the correction is usually quick once you have account access back. That is the good news, and it is also the trap. The speed of the fix tempts people to treat the incident as closed at the moment the records look right again.

Three levels of hijack, in ascending order of blast radius

Not all hijacks are the same size, and the response differs at each level.

Record-level. The attacker edits a single A or MX record inside an otherwise intact zone. Surgical, quiet, and easy to miss in a zone with hundreds of entries.
Nameserver-level. The attacker changes the domain's delegation at the registrar so the entire zone is served by infrastructure they run. Nothing in your old zone matters any more, because nobody is asking it. ED 19-01 makes nameserver and critical-service records the audit priority for precisely this reason.
Account-level. The attacker takes the registrar or DNS-provider account itself, which enables both of the above plus an attempted transfer out. Cisco Talos documented a state-sponsored campaign, published in April 2019, that operated at this level — compromising ccTLD registrars, telecommunications providers and a registry organization rather than the eventual victims, and modifying nameserver records from there.

A glue record — the IP address stored at the registry for a nameserver that lives inside the domain it serves — deserves a separate look at every level, because it is held at the registry rather than in your zone and is therefore invisible to a zone export.

The certificate is the part that outlives the cleanup

A domain-validated certificate is a TLS certificate issued purely on proof of DNS or web control, with no check of who the organization behind it is. Whoever controls your DNS during the hijack window can therefore obtain a genuine, publicly trusted certificate for your domain, and that certificate keeps working after you have corrected every record — until somebody revokes it.

This is why ED 19-01 treats monitoring Certificate Transparency logs — public, append-only logs of every publicly trusted certificate, searchable for names you did not request — as a separate mandated action rather than a footnote to the DNS cleanup. Talos observed the same pattern: a nameserver change followed by a CA-signed certificate for the same domain obtained from a different provider. Reversed records plus a live attacker certificate is still an interception capability, and it is the single most commonly skipped step in the incident work I see. A related pattern uses rogue subdomains created under a legitimate, still-correctly-registered name, which is why shadowed records so often survive an audit that only checks the apex.

What a complete response contains

ED 19-01 binds only US federal civilian executive branch agencies, and CISA has since marked it closed. It is not a rule for private registrants. It remains the clearest published statement of what a response has to include, and its four required actions — each due within ten business days of 22 January 2019 — map cleanly onto a private incident (CISA ED 19-01):

Audit the records. Verify that every DNS record for every domain you manage resolves where it is supposed to, prioritizing nameserver and critical-service records.
Change the credentials. Rotate passwords across DNS servers, DNS management systems, third-party DNS operators and registrars — not just the one console you logged into.
Add multi-factor authentication. On every account able to modify DNS records. The directive discourages SMS-based factors, consistent with NIST guidance, and required a written explanation where a system could not support MFA at all.
Monitor Certificate Transparency logs. Flag certificates nobody authorized and report them to the issuing certificate authority.

Note the ordering. Auditing before rotating credentials tells you what was done; rotating before auditing tells the attacker you noticed.

Where cleanups go wrong

Fixing the A record and stopping — without checking the NS delegation, the MX records, TXT and SPF entries, and glue.
Checking only for records that were changed, when records were added. An addition breaks nothing and so raises no complaint.
Rotating the CMS password while leaving the registrar password, the DNS provider's API key and the email address on the registrar account exactly as the attacker left them.
Skipping the Certificate Transparency search, for the reason set out above.
Ignoring TTL — the number of seconds resolvers may cache an answer before asking again. A long TTL on a hijacked record means resolvers keep serving the attacker's answer for hours after you have corrected it, and users report the site as still broken when the zone is already clean.
Leaving the account without MFA after cleanup, which reopens the same door.

The business implication of the TTL point is worth stating plainly: your recovery is not complete when you press save, it is complete when the last cached answer expires. Plan communications around the second time, not the first.

When a hijack turns into a transfer attempt

Account-level compromise puts the registration itself in play, and the relevant instrument changes from a security directive to a contract. Under the ICANN Transfer Policy, the registrar of record may deny a transfer where there is evidence of fraud, a pending UDRP or URS proceeding, a court order, or express objection from the authorized Transfer Contact (ICANN Transfer Policy).

Two practical consequences follow. First, an express objection from the authorized contact is a lever you hold directly and can exercise immediately, which is why establishing that you are the authorized contact matters before you need it. Second, the fraud ground requires evidence, so the forensic record of the hijack — zone exports, registrar audit logs, timestamps, Certificate Transparency entries — is not merely for your own understanding. Where a transfer has already completed or litigation is in prospect, this is the point at which counsel is required; the policy sets out what a registrar may do, not what you are entitled to demand.

What prevention actually looks like

Prevention here is unglamorous and mostly consists of removing single points of failure.

Multi-factor authentication on every account that can change DNS or registration data — registrar, DNS host, and any reseller sitting between them. Resellers are the step most often forgotten.
Registry lock on the domains that matter. The registry-set EPP statuses serverUpdateProhibited and serverTransferProhibited block changes until an out-of-band verification is completed, so compromise of the registrar account alone is no longer enough to move the domain. The registrar-set equivalents, clientUpdateProhibited and clientTransferProhibited, are useful but sit inside the account an attacker has already taken.
Continuous Certificate Transparency monitoring, so a fraudulent certificate surfaces in hours rather than at the next audit.
DNSSEC signing, which places cryptographic signatures on DNS answers so a resolver can detect forgery (RFC 4033). No ICANN consensus policy requires registrants to sign their zones, and DNSSEC does not help against an attacker who is making authorized changes with stolen credentials — it defends a different part of the path.
A written, version-controlled record of intended zone contents, so that “does this resolve correctly” is a comparison rather than a judgment call at three in the morning.

Registry lock is the item that gets deferred because it makes routine changes slower. That is the point of it. If your DNS changes several times a week and cannot tolerate an out-of-band verification step, that is a statement about your change process, not an argument against the lock.

Frequently Asked Questions

Is DNS hijacking the same thing as domain theft?

No, and the difference determines the remedy. In a domain theft the registration moves — the registrant details or the sponsoring registrar change, and recovery runs through registrar and registry processes and sometimes through a dispute or a court. In a DNS hijack the registration usually stays in your name and only the records, or the nameserver delegation, are altered. That means you can generally correct it yourself once you regain account access. The two overlap when the attacker holds the registrar account, because from there they can both redirect the domain and attempt to transfer it away.

How quickly do I need to act on a suspected DNS hijack?

Immediately, because the loss compounds by the hour rather than at a policy deadline. While the records point at the attacker, inbound email, session cookies and password-reset links are delivered to them, and each one is a separate credential exposure elsewhere in your organization. There is a second clock too: any TLS certificate the attacker obtains during the window remains valid until it is revoked, so the interception capability can outlast the hijack itself. Correct the records first, then rotate credentials, then search Certificate Transparency logs before declaring the incident closed.

Why did my site stay broken after I fixed the DNS records?

Almost always TTL — time to live, the number of seconds a resolver is permitted to cache an answer before asking again. If the hijacked record carried a long TTL, resolvers around the world will keep serving the attacker's answer until that cache entry expires, regardless of what your zone now says. Lowering the TTL after the fact does not retroactively shorten cached answers. The other common cause is an incomplete fix: the A record was corrected but the nameserver delegation still points at attacker infrastructure, so the zone being consulted is not the zone you edited.

Does DNSSEC prevent DNS hijacking?

Only one form of it. DNSSEC places cryptographic signatures on DNS answers so a resolver can detect a forged response in transit, which defends against cache poisoning and on-path tampering. It does not defend against an attacker who has your registrar or DNS-provider credentials, because their changes are made inside the zone and are signed like any other legitimate record. Signing your zone is worth doing. It is not a substitute for multi-factor authentication on the accounts that can edit the zone, and treating it as one is a common and expensive misreading.

How do I find out whether a certificate was issued for my domain during the hijack?

Search the Certificate Transparency logs, which are public append-only records of every publicly trusted certificate issued, queryable by domain name. Look for any certificate covering your domain or its subdomains with a validity period overlapping the hijack window that you cannot match to a request of your own, and check the issuing certificate authority against the ones you actually use. Anything unaccounted for should be reported to the issuing authority for revocation. CISA's Emergency Directive 19-01 makes this a distinct required action rather than part of DNS cleanup, which reflects how often it is skipped.

What is registry lock and will it stop a DNS hijack?

Registry lock is a set of statuses applied at the registry — typically serverUpdateProhibited and serverTransferProhibited — that blocks changes to the domain until an out-of-band verification step is completed with the registrar, usually involving a person and a pre-agreed procedure. It stops the highest-blast-radius version of the attack, in which a compromised registrar account is used to change the nameserver delegation or transfer the domain away. It does not stop record-level tampering inside a zone hosted elsewhere, because those records never touch the registry. The two controls address different levels and are worth having together.

Which records should I check first after regaining access?

Start with the nameserver delegation, because if it is wrong nothing else in your zone is being consulted. Then check glue records held at the registry for any nameserver inside your own domain. Then work through A records for public services, MX records for mail, and TXT records carrying SPF, DKIM and DMARC policy, since mail authentication changes let an attacker send convincing mail as you long after the redirect is fixed. Throughout, look for records that were added as well as records that were changed — additions break nothing and therefore generate no complaint.

DNS Hijacking