DNSSEC and Registry Lock Keep Hijackers Off Your Domain

Posted: March 10, 2026 to Insights.

Tags: Support, Domains, Email, Calendar, Links

Stop Domain Hijacks with DNSSEC and Registry Lock

Domain hijacking knocks companies offline, steals customer trust, and quietly reroutes payments or credentials to attackers. It often starts with a small gap in DNS security that gets exploited at the worst possible time. Two controls stop the most damaging classes of attacks: DNSSEC, which prevents tampering with DNS answers, and Registry Lock, which prevents unauthorized changes to the domain at the registry. Combined with sane registrar practices, they turn a soft target into a hard one.

This guide explains how hijacks happen, what DNSSEC and Registry Lock actually do, how to deploy them safely, and how to operate them day to day. Real incidents are translated into practical lessons so teams can ship the defenses quickly without breaking production.

What a Domain Hijack Looks Like

Attackers aim for the control plane of your domain. Once they win there, the traffic is theirs. Common patterns include:

Registrar account compromise, then nameserver changes or record edits that point your hostname to attacker infrastructure.
Registry-level changes after social engineering a registrar support agent, which jump straight past your account controls.
On-path DNS tampering or cache poisoning, which feeds resolvers a fake IP for your hostname even though your zone is untouched.
DNS provider account takeover, followed by stealth edits to a subset of records, often for login or payment subdomains.

Symptoms vary. Customers complain about certificate warnings, a login page that looks off, or payments that fail. Monitoring might show traffic shifts or TLS certificate changes. If TTLs are short, redirection spreads fast. If TTLs are long, the attack lingers after you fix it.

Where DNS Is Weak Without Extra Controls

DNS is a delegation system. The registry holds the top-level domain, like .com. A registrar sells you the domain example.com and tells the registry which nameservers host your zone. Your DNS provider answers queries about the zone itself, such as the A, AAAA, MX, and TXT records.

That path offers multiple places to attack:

At the resolver cache, by injecting forged answers when DNSSEC is not validated.
Inside your registrar account, by password reset, SIM swap, or phished support channels.
At the registry, by convincing a registrar to submit changes on your behalf.
Inside your DNS provider console, resulting in quiet record edits that are hard to notice.

Every layer has a fix. DNSSEC authenticates answers to stop on-path tampering. Registry Lock hardens the top of the funnel so a compromised registrar account is not enough. Provider security and registrar hygiene cover the rest.

How DNSSEC Stops Tampering

DNSSEC adds digital signatures to DNS records. A validating resolver checks those signatures before trusting an answer. If the signature chain fails, the resolver treats the response as bogus and does not return it to clients.

Three ingredients matter most:

DNSKEY: the public keys that verify record signatures published in your zone.
RRSIG: the signature over each record set, created with your private key.
DS: a hash of your zone’s key published at the parent zone, which creates a chain of trust from the TLD down to your zone.

When a client asks for www.example.com, a validating resolver fetches the answer and the RRSIG. It also fetches the DNSKEY set and checks the DS at the parent, such as .com, to confirm the DNSKEY belongs to your zone. If everything lines up, the response is authentic. If an attacker forges a record, the signature check fails.

Negative answers are protected too. NSEC or NSEC3 proves that a name or type does not exist, which blocks attacks that try to forge NXDOMAIN or hide genuine records.

What DNSSEC Does Not Do

It does not encrypt DNS. It authenticates data. Combine it with DNS over TLS or DNS over HTTPS if privacy on the last mile matters.
It does not stop someone who already controls your registrar or DNS provider account from publishing signed but malicious records.
It does not prevent a registry edit from changing your nameservers. It will faithfully sign whatever the new zone serves.

That is why Registry Lock complements DNSSEC. One prevents forged answers in flight, the other prevents unauthorized edits at the source.

Deploying DNSSEC Without Drama

Good implementation comes down to preparation, a clean DS submission, and careful rollovers. Most managed DNS providers make this straightforward, while self hosted setups require more hands-on work.

Prechecks and prerequisites

Verify your TLD supports DNSSEC and your registrar allows DS record submission.
Confirm your DNS provider supports inline signing or offline signing workflows. For multi-provider setups, confirm multi-signer DNSSEC support.
Choose algorithms. ECDSA P-256 (algorithm 13) is efficient and widely supported. RSA is fine but produces larger packets.
Plan a ZSK and KSK split. The ZSK signs records frequently. The KSK changes less often and anchors trust via the DS.

Managed DNS, the quick path

Enable signing in your DNS provider console for the zone.
Publish the DS at your registrar. The provider shows you the DS data, usually key tag, algorithm, digest type, and digest.
Wait for propagation, then test with a validating resolver and tools like DNSViz or Zonemaster.
Document the rollover policy. Many providers automate ZSK rotation and remind you when a KSK rollover is due.

Self hosted signing

Generate keys with your DNS software, like BIND, Knot, or PowerDNS. Use separate KSK and ZSK.
Sign the zone and serve DNSSEC records. Ensure UDP responses fit with EDNS0; allow TCP fallback if needed.
Publish the DS at the registrar. Double check the digest type and value.
Monitor packet sizes and truncation. Consider minimal NSEC3 iterations to control response bloat.

Key management and rollovers

ZSK rollovers happen more often. Use prepublish and double-sign methods so validators always have the required keys.
KSK rollovers are less frequent because they require a DS update at the parent. Prepublish the new KSK, submit the updated DS, then remove the old one after safe time windows.
CDS and CDNSKEY automation, where supported by your registrar and registry, can update DS records automatically when you rotate keys.

Pitfalls to avoid

DS mismatch. If the DS does not match your published DNSKEY, validators will treat your zone as bogus. Always verify the key tag and digest before submission.
Changing nameservers without coordinating DNSSEC state. If you switch DNS providers, arrange a multi-signer transition or pause signing in a controlled way, then reestablish signing to avoid outages.
Large responses that fragment and get dropped. Prefer ECDSA, enable TCP on authoritative servers, and monitor SERVFAIL spikes from validators.
CDN or multi-CDN setups with apex CNAME workarounds. Ensure your provider supports DNSSEC on ALIAS or ANAME constructs and test failover paths.
Wildcard surprises. Signatures apply to record sets, so check how your wildcard interacts with NSEC or NSEC3 proofs.

Registry Lock, the Safety Catch at the Registry

Registry Lock is a higher assurance control that freezes critical domain functions at the registry. Even if your registrar account gets compromised, an attacker cannot change nameservers, transfer the domain, or delete it while the lock is active.

Under the hood, the registry sets server-level EPP statuses like serverUpdateProhibited, serverTransferProhibited, and serverDeleteProhibited. Only a privileged registrar workflow with out-of-band verification can remove the lock or make protected changes. That workflow varies by TLD and registrar, but the idea is consistent.

Registrar Lock vs Registry Lock, not the same thing

Registrar Lock, often shown as clientTransferProhibited, is applied by the registrar and can usually be toggled inside your account. A compromised account can remove it.
Registry Lock is applied at the registry with server-level statuses. Your web login cannot flip it off. A human-reviewed process is required to change it.

How the out-of-band change flow works

Expect a defined list of authorized contacts, a predefined passphrase or token, and a second factor like a phone callback or an app approval. Some registrars require a signed request using PGP, a security portal with time-limited approvals, or both. Changes are scheduled, often during business hours, and auditors can trace the request trail.

Operations that are usually protected include:

Nameserver changes and glue edits.
Contact updates, like registrant email or phone, that could enable unauthorized transfers.
Domain transfer requests.
Domain deletion or restoration.

Plan for added lead time. Emergency changes are still possible, but they require the out-of-band checks, so keep the authorized contact list current and test the process before a crisis.

Who should use Registry Lock

Brands with high phishing pressure or valuable login portals.
Financial services, healthcare, and government services that face targeted attacks.
Providers with many downstream customers behind a single domain, such as email and SaaS platforms.
Any organization that cannot tolerate a day of misdirected traffic or lost trust.

Costs and operational planning

Expect per-domain setup and monthly fees, plus per-change charges. Prices vary by TLD and registrar.
Document who can authorize changes and where the secret tokens live. Store them with your incident response material.
Set SLAs. Some providers offer faster approval windows for pre-registered emergency contacts.

Real Incidents, Simplified, and the Fix

Major news site hijack in 2013: public reports described a registrar account compromise followed by nameserver changes that redirected the domain. Registry Lock would have blocked the nameserver edit. DNSSEC would not stop that particular change, since the attacker controlled the zone after delegation moved, but it would still protect users of subdomains that did not change if the attacker relied on cache poisoning.
Cryptocurrency phishing in 2018: reports described a BGP hijack that redirected traffic to a fake DNS server, which then answered with forged records. Validating users were protected because DNSSEC would have caused resolvers to discard the bogus answers. Registry Lock does not apply here, since no registry change occurred.
SMS-based takeover at a registrar: attackers used SIM swap to reset a registrar login, then changed records for a trading platform. DNSSEC would not help because the attacker published signed records from the legitimate console. Registry Lock would have forced a phone verification to a predefined number that was not tied to the hacked mobile line, breaking the attack chain.

The pattern is clear. DNSSEC defeats in-flight tampering and cache poisoning. Registry Lock defeats unauthorized registry edits. Both are needed, and they do not replace normal account hygiene or provider security.

Layered Defense That Actually Works

Cover the three planes: registry, registrar, and DNS provider, then add DNSSEC to protect answers in transit.

At the registry: enroll in Registry Lock for primary and high-risk domains. Keep an emergency authorization list up to date.
At the registrar: enforce SSO with MFA, use role accounts with limited scope, and restrict support changes to a named security team. Disable SMS resets and verify domain contacts regularly.
At the DNS provider: use hardware keys or app-based MFA, approve only signed API calls where possible, and require change reviews for critical records like nameservers, MX, and login endpoints.
On the wire: turn on DNSSEC, monitor validation health, and keep key rollovers on a predictable calendar.
Across TLS: publish CAA to control certificate issuance, and consider DANE for internal services where client support exists.

Step-by-step for a single domain

Inventory. Identify the registrar, registry, DNS provider, and key records. Capture current NS, DS, and DNSKEY data.
Turn on DNSSEC. Use provider signing if available. Publish the DS, then validate with multiple resolvers.
Enroll in Registry Lock. Complete the identity proofing and set the out-of-band contacts.
Harden accounts. Enforce MFA, remove unused users, and enable notifications for DNS and contact changes.
Document change windows. Record the process for requesting nameserver or contact edits under Registry Lock.
Monitor. Add alerts for DS mismatches, EPP status changes, and unusual record diffs.

Step-by-step for portfolios and multiple registrars

Consolidate if possible. Fewer registrars means fewer weak links, and it simplifies Registry Lock enrollment.
Group domains by risk. Apply Registry Lock to primary zones and production customer-facing brands first.
Standardize DNSSEC. Pick algorithms and rollover windows, then bake them into runbooks or Terraform modules.
Automate checks. A daily job should compare DS at the parent with DNSKEY in the child across the portfolio.
Train support. Provide a short playbook for suspected hijacks, including emergency contacts at the registrar and registry.

Testing, Monitoring, and Alerting That Help Instead of Harm

Validation checks. Query your zone with a validating resolver, such as 1.1.1.1 or 9.9.9.9, and confirm the AD bit is set in responses when you use dig +dnssec.
DS and DNSKEY coherence. A monitor should alert when the DS at the parent does not match any DNSKEY in the child, or when the key tag changes unexpectedly.
Response size and truncation. Watch for spikes in TCP fallback or SERVFAILs that correlate with large RRSIG responses. Switch to ECDSA if needed.
EPP status tracking. Poll RDAP or WHOIS to confirm serverUpdateProhibited, serverTransferProhibited, and serverDeleteProhibited are present for locked domains.
Change diffs. Log every DNS change and send diffs to a security channel. Pay special attention to MX, NS, CNAME at login or payment subdomains, and TXT records that control email or ACME challenges.
External perspectives. Use DNSViz or Zonemaster regularly and after every change that touches DNSSEC or NS records.

Advanced Options for High Assurance

Multi-signer DNSSEC. If you use two DNS providers, both can sign the same zone with coordinated keys. This avoids outages during provider failover and preserves validation.
CDS automation. If your registrar and registry support CDS and CDNSKEY scanning, your authoritative servers can publish the desired DS updates and keep the chain of trust in sync automatically.
NSEC3 opt-out. For large delegation-heavy zones, opt-out can keep negative responses smaller. Evaluate the tradeoff, then test thoroughly.
DANE for SMTP. Publish TLSA records for mail servers to lock TLS to known certificates. DNSSEC is a prerequisite for DANE, which helps stop SMTP downgrade and impersonation.
CAA with account binding. Limit certificate issuance to your chosen CAs and, where supported, to specific account identifiers to reduce certificate misissuance risk.

Incident Response When You Suspect a Hijack

Confirm scope. Check NS, DS, and high-value records from multiple networks. Compare against known-good snapshots.
Freeze the control plane. Enable or verify Registry Lock. At the registrar and DNS provider, rotate credentials and revoke sessions.
Engage escalation paths. Call the registrar’s security number and open a high-priority ticket. If Registry Lock exists, use the authorized contacts to block pending changes.
Restore delegation first. If nameservers changed, schedule the reversal under Registry Lock. If only records changed, revert through the DNS provider, then shorten TTLs temporarily.
Invalidate caches. For CDNs and resolvers under your control, purge caches. Communicate with customers about the incident and what to expect.
Hunt persistence. Review API logs, secondary DNS zones, and any delegation at child zones.
Post-incident hardening. Add Registry Lock if missing, turn on DNSSEC, and fix the root cause, like weak registrar MFA or open support reset paths.

Practical Concerns Teams Raise

Will DNSSEC break our site for some users? Validating resolvers expect correct signatures. If you publish a wrong DS or botch a rollover, validators will fail. With careful procedures and monitoring, breakage is rare. Start on a staging domain, then promote.
Are there still clients that cannot handle DNSSEC? Clients query resolvers, and validation happens there. You do not need browsers or apps to change. The coverage of validating resolvers is strong across public and enterprise networks.
What about packet size and firewalls? DNSSEC can produce larger UDP packets. Ensure your authoritative servers support EDNS0 and TCP. Avoid middleboxes that break fragmented UDP. ECDSA reduces size compared to RSA.
Does Registry Lock slow down urgent changes? It adds minutes or hours, depending on your registrar’s process. For most organizations, that is acceptable compared to the risk. Pre-register emergency contacts and test an emergency change so there are no surprises.
We use multiple DNS providers. Is that compatible with DNSSEC? Yes, with multi-signer DNSSEC, both providers publish DNSKEYs and sign the zone. Coordinate the keys and DS at the parent, then test failover.
How do we coordinate with a CDN? Many CDNs support DNSSEC on their managed zones, and many DNS providers support DNSSEC with ALIAS or ANAME at the apex. Verify the combination in a lab domain before flipping production.
What if our registrar does not offer Registry Lock? Consider moving your high-value domains to a registrar that does, or work with the current registrar to see if the TLD’s registry offers a lock you can access through them.
Who owns the keys in a managed DNSSEC setup? Providers typically manage ZSK and KSK. That is fine for most teams. If you have compliance needs, ask about customer-supplied KSK, signing audits, and export options.
Can we rely on CAA and certificate transparency instead? CAA and CT are helpful for TLS, but they do not stop DNS hijacking or forged DNS answers. DNSSEC and Registry Lock target different parts of the attack chain.

Taking the Next Step

DNSSEC authenticates your answers and Registry Lock protects your delegation, closing the two biggest doors hijackers use. With tested procedures, staged rollouts, and a registrar that supports strong locks, you can add these controls without slowing the business. Start by enabling DNSSEC on a non-critical domain, enrolling your flagship names in Registry Lock, and rehearsing an emergency change. Make these baselines part of your roadmap this quarter and turn domain hijacking from a crisis into a non-event.

DNSSEC and Registry Lock Keep Hijackers Off Your Domain

Stop Domain Hijacks with DNSSEC and Registry Lock Domain hijacking knocks companies offline, steals customer trust, and quietly reroutes payments or credentials to attackers. It often starts with a small gap in DNS security that gets exploited at the worst...