Defaults.Exposed

Defaults.Exposed › Reports

DNS Hijacking and Spoofing: How Attackers Steal Domain Records

Published

DNS hijacking is the theft of a domain’s routing. Instead of breaking into your website, an attacker takes control of the DNS records that decide where your domain points — its registrar account, its nameservers, or a single dangling record — and quietly redirects your traffic, your email, or one of your subdomains to infrastructure they own. It is one of the few attacks that can hand over a whole domain without touching the server behind it. The August 2026 defaults.exposed census scanned 432,127,908 domains and found 63,840,407 of them — 14.8% — delegated in DNS but serving nothing: “dark matter” that includes the dangling delegations attackers scan for and seize through subdomain takeover. Alongside it sit 157,064 domains whose DNSSEC is present but broken, leaving their DNS answers open to the spoofing that hijacking’s quieter cousin, cache poisoning, relies on. This guide untangles hijacking, spoofing, and cache poisoning, shows how each one unfolds, and explains how to check your own domain for free.

Most domain owners think of DNS as plumbing — something that either works or does not. Attackers think of it as a control plane: whoever owns the records owns the destination. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

DNS hijacking vs DNS spoofing vs cache poisoning: the terms untangled

These three words get used interchangeably, but they describe different attacks with different fixes. Getting them straight is the first step to defending against any of them.

DNS hijacking changes the real records. The attacker gains control of the authoritative source of truth for your domain — the registrar account, the DNS hosting provider, or the nameserver configuration — and edits what your domain resolves to. The forged answer is now the official answer. Every resolver on earth will faithfully hand it out, because nothing has been forged in transit; the record itself has been rewritten at the source.

DNS spoofing forges the answer without changing the record. The authoritative data is untouched, but somewhere between the resolver and the authoritative server an attacker injects a false response that arrives first. The victim’s resolver believes it, even though the domain’s real records still say something else. Spoofing is an interception attack; hijacking is a control attack.

DNS cache poisoning is the most common form of spoofing at scale. Rather than fool one user once, the attacker plants a forged record inside a recursive resolver’s cache — the shared lookup service used by an ISP, a corporate network, or a public resolver. Once poisoned, that cache serves the false answer to every user behind it until the entry expires. One successful injection can misdirect thousands of people.

The practical difference is who you have to trust. A hijack means your own registrar or DNS account was compromised. A spoof or poisoning means the resolution path was compromised. The defence for the first is account security and registrar locking; the defence for the second is cryptographic signing — DNSSEC — so a forged answer fails validation. We grade the signing layer directly on the DNSSEC DS and DNSSEC DNSKEY methodology pages.

How a real DNS hijack unfolds (registrar, nameserver and resolver paths)

A DNS hijack is not one attack but a family of them, defined by which link in the resolution chain the attacker captures. There are three practical paths, and they demand different defences.

The registrar path. Your domain’s registration lives in an account at a registrar. That account controls the two things an attacker wants most: the delegation (which nameservers are authoritative) and the transfer status (whether the domain can be moved to another registrar). If an attacker phishes the login, reuses a breached password, or defeats weak recovery questions, they can repoint the nameservers to servers they run — and every DNS answer for the domain now originates from the attacker. This is the highest-impact hijack because it captures the entire domain in a single change, and it is why a registrar lock is the single most valuable control most owners never enable.

A registrar hijack often works through the transfer machinery itself. Moving a domain between registrars requires an authorisation code — the EPP or “auth” code — and a domain left unlocked with a leaked auth code can be pulled to an attacker’s registrar before the owner notices. Once transferred, recovery is a slow, evidence-heavy dispute rather than a quick password reset, which is why prevention here matters far more than response. A locked domain refuses the transfer regardless of whether the code has leaked.

The nameserver path. Even with the registration secure, the authoritative nameservers themselves are a target. If the DNS hosting provider’s control plane is breached — or an old, forgotten zone at a provider you no longer use is taken over — the attacker edits records directly. A domain whose nameservers are split across independent providers is harder to fully capture than one that puts every egg in one basket, which is why we grade nameserver diversity as a resilience signal.

The resolver path. The final link is closest to the victim: the recursive resolver a device is configured to use. Malware that rewrites a machine’s DNS settings, or a compromised home router handing out a rogue resolver over DHCP, sends every lookup to a server the attacker controls. Nothing about the domain’s real records changes — but the victim never reaches them. This is hijacking at the last mile, and it is invisible to the domain owner because it happens on the victim’s side of the wire.

Across all three paths the attacker’s goal is the same: become the source of the answer. The single nameserver domains report shows how many domains hand an attacker an easy win by running with no redundancy at all — one nameserver to compromise, one point of failure to exploit.

Dangling DNS and subdomain takeover: the 64-million-domain surface

The lead stat of this report is not a hypothetical. 63,840,407 domains — 14.8% of everything scanned — are delegated in DNS but serve no content. They resolve, they have nameservers, they answer a query — and then there is nothing behind them. We call this “dark matter,” and it is measured in full in Domain Dark Matter: 64 Million Delegated, Empty Domains. A large share of it is the precise raw material for the most automated hijack in use today: subdomain takeover.

Subdomain takeover exploits a dangling record — a DNS entry that points to a resource that no longer exists. The classic case is a CNAME left over from a decommissioned service. A team spins up status.yourbusiness.com pointing at a cloud host, a CDN endpoint, or a SaaS app. Months later the underlying resource is torn down, but nobody removes the DNS record. The subdomain now points into empty space at a provider — and if an attacker can re-register that same resource name at the provider, the dangling record suddenly resolves to their content.

The consequences are severe precisely because the takeover is invisible from the parent domain. The attacker now controls a hostname that genuinely belongs to your brand. They can:

What makes this a 64-million-scale problem rather than a boutique one is automation. Attackers do not hand-pick targets; they scan the entire namespace for records that resolve to claimable resources, exactly the dark-matter signature the census measures. A dangling record is not a subtle misconfiguration an adversary might stumble on — it is a beacon. Every empty delegation is a lottery ticket an attacker can check for free, and 63.8 million of them are sitting on the board.

The fix is unglamorous and permanent: when you decommission a service, delete its DNS records before you release the underlying resource, and audit your zones for entries pointing at hosts you no longer own. Check your domain free at defaults.exposed and the scan will flag delegations and records that resolve to nothing — the first place a takeover hunter looks.

Cache poisoning and why missing DNSSEC leaves the door open

Where hijacking rewrites the real record, cache poisoning fabricates a fake one and slips it into a resolver’s memory. Understanding why it still works in 2026 means looking at what an unsigned DNS answer actually proves: nothing.

Classic DNS is an unauthenticated protocol. When a recursive resolver asks an authoritative server for a record, the answer arrives as a plain UDP packet with no signature. The resolver accepts the first response that matches the query’s transaction ID and source port. That is the whole security model — a 16-bit ID and a port number. An attacker who can guess or force those values, and who replies faster than the real server, can inject a forged answer. The resolver caches it and serves it to everyone until the record’s time-to-live expires. This is the Kaminsky-class attack, and while source-port randomisation raised the cost, it never closed the door.

DNSSEC is the door. DNSSEC (DNS Security Extensions) attaches cryptographic signatures to DNS records and builds a chain of trust from the root zone down to your domain. A resolver that validates DNSSEC will reject a forged answer, because the attacker cannot produce a valid signature. Poisoning simply fails. For a plain-English walk through the trust chain, see What Is DNSSEC: A Plain-English Guide to the DNS Trust Layer.

The census result is stark. The overwhelming majority of domains publish no DNSSEC at all, which means their answers can be forged and there is no signature for a resolver to check. Worse, 157,064 domains publish DNSSEC that is broken — signatures present but failing validation — which is arguably the worst of both worlds: a validating resolver treats a broken chain as a hard failure and the domain becomes invisibly unreachable, while the owner believes they are protected. That failure mode is measured in Broken DNSSEC: 157,064 Domains Are Invisibly Down.

The takeaway is blunt: without DNSSEC, the only thing standing between your users and a poisoned answer is an attacker’s ability to win a race that the protocol was never designed to make them lose. With DNSSEC deployed correctly, cache poisoning stops being a viable path.

The DNS-landlord concentration risk (94M nameservers, two providers)

Individual hijacks capture one domain. The systemic risk is what happens when one control plane sits above millions of them. The census measured exactly that concentration.

Roughly 94 million of the world’s nameservers sit under just two DNS landlords — GoDaddy and Cloudflare. The full distribution is mapped in The DNS Landlords: How GoDaddy and Cloudflare Control Nameservers for 94 Million Domains. Consolidation of this scale is a double-edged sword. Large providers bring competent security teams, DNSSEC support, and DDoS resilience that a small operator cannot match — genuine wins for the median domain. But they also create a mass-hijack surface: a single control-plane compromise, a credential leak in a support tool, or an authentication bypass at one of these providers is not one domain at risk, it is tens of millions.

This is the strategic reason DNS security cannot be reduced to “pick a big provider and forget it.” The provider concentrates both the defence and the blast radius. A domain owner who understands this treats the DNS account with the same care as a bank login — strong unique credentials, hardware-backed multi-factor authentication, and the tightest recovery options the provider offers. The broader landscape, and why so much of the internet’s routing now depends on so few operators, is the subject of DNS Security Explained: Why 94 Million Domains Rely on Two Landlords.

Concentration also raises the value of redundancy. A domain running on a single nameserver, or entirely within one provider, has no fallback if that provider’s control plane is turned against it. Splitting authoritative DNS across independent operators — the nameserver diversity signal we grade — is one of the few structural defences an owner can add without touching the provider’s own security.

Detect and prevent takeover: registrar lock, DNSSEC, monitoring (free check)

Domain takeover is one of the rare attacks that is genuinely cheap to prevent and catastrophic to suffer. A handful of controls, most of them free, close nearly the whole surface. Here is the priority order.

  1. Enable registrar lock. Turn on the transfer-prohibited status (clientTransferProhibited) at your registrar, and if your registry offers a stronger registry-lock service for high-value domains, use it. This stops the highest-impact hijack — an unauthorised nameserver change or domain transfer — even if credentials leak.
  2. Harden the registrar and DNS accounts. Unique, long passwords in a manager; hardware-backed multi-factor authentication, not SMS; and locked-down recovery options. These two accounts are the keys to the domain; treat them as more sensitive than the website itself.
  3. Deploy DNSSEC — and monitor it. Signing your zone defeats cache poisoning by making forged answers fail validation. But deploy it carefully: a broken chain takes you offline for validating resolvers, the failure mode behind those 157,064 invisibly-down domains. Validate after every key rollover.
  4. Kill dangling records. Delete DNS entries the moment the service behind them is decommissioned, and release cloud resources only after the pointing record is gone. Audit zones regularly for records resolving to nothing — the dark-matter signature.
  5. Add nameserver redundancy. Where practical, run authoritative DNS across more than one independent provider so a single control-plane compromise cannot capture the whole domain. Check your SOA configuration while you are in the zone; a neglected start-of-authority record is a reliable tell for a zone nobody is watching.
  6. Monitor continuously. Takeover is only existential if it goes unnoticed. Watch for unexpected nameserver changes, new dangling records, and DNSSEC validation failures, and alert on them.

It also helps to know the warning signs of a hijack already in progress. Unexpected certificate-issuance notices for hostnames you did not request, mail suddenly failing DMARC or bouncing at scale, a registrar email confirming a nameserver or contact change you never made, or a subdomain that starts serving content nobody on your team deployed — each is a symptom of the record theft described above, not a routine glitch. Treat any of them as an incident and verify your delegation immediately.

The first step costs nothing and takes two minutes: find out what an attacker already sees. Check your domain free at defaults.exposed — the scan reads your live DNS from public resolvers and flags dangling delegations, missing or broken DNSSEC, and single-nameserver fragility, the three signals a takeover hunter scans for. To turn a one-off check into continuous takeover monitoring — so a dangling record or a nameserver change raises an alert instead of an incident — see how the fix works.

What this means

For business owners, DNS takeover is not an IT inconvenience — it is a business-continuity event. If an attacker seizes your domain’s records, they own your website’s destination, your email routing, and any subdomain you forgot to clean up, all while the servers behind them run untouched. Customers see a real, correctly-spelled address serving an attacker’s content. The controls that prevent this — a registrar lock, multi-factor authentication on two accounts, and deleting DNS records for services you have retired — cost nothing and take an afternoon. The census shows 63,840,407 domains carrying empty delegations that attackers actively hunt; the only question that matters is whether one of them is yours.

For IT and security teams, the census reframes DNS hygiene as attack-surface management. Dark matter is not clutter — it is the exact inventory an automated takeover scanner is looking for, and 14.8% of the measured internet is sitting in that state. Prioritise a zone audit that removes dangling records, verify DNSSEC actually validates rather than merely existing (157,064 domains prove the difference), and treat registrar and DNS-provider accounts as tier-zero credentials given that roughly 94 million nameservers now concentrate under two providers. Redundancy across independent nameservers is a structural hedge you can add without waiting on a provider.

FAQ

What is DNS hijacking? DNS hijacking is an attack that gives someone else control over where your domain points by altering its DNS records at the source. Rather than breaking into your web server, the attacker captures the authoritative control of the domain — the registrar account, the nameserver configuration, or a dangling record — and redirects your website, email, or a subdomain to infrastructure they own. Because the change is made to the real records, every resolver serves the malicious answer as the official one. The August 2026 census found 63,840,407 domains delegated in DNS but serving nothing, much of it the dangling-record surface hijackers target. You can check your own domain free at defaults.exposed.

What is the difference between DNS hijacking and DNS spoofing? DNS hijacking changes the real records: the attacker gains control of the authoritative source — a registrar account, DNS provider, or nameserver — so the forged destination becomes the official answer every resolver hands out. DNS spoofing leaves the real records untouched but forges the answer in transit, injecting a false response that reaches the victim’s resolver before the genuine one. Hijacking is a control attack you fix with account security and registrar locking; spoofing is an interception attack you fix with DNSSEC, which cryptographically signs answers so forgeries fail validation. The census found 157,064 domains with broken DNSSEC and the overwhelming majority publishing none — leaving spoofing largely undefended.

How does DNS cache poisoning work? Cache poisoning is spoofing at scale. Classic DNS answers are unauthenticated UDP packets, and a recursive resolver accepts the first reply matching the query’s transaction ID and source port. An attacker who guesses or forces those values, and replies faster than the legitimate server, injects a forged record into the resolver’s cache. Every user behind that resolver — an ISP, a company, a public service — then receives the false answer until the record’s time-to-live expires, so one injection can misdirect thousands. DNSSEC stops it by signing records so a validating resolver rejects any forged answer. Without it, only a guessing race protects the cache.

How do I prevent DNS hijacking? Start with a registrar lock (clientTransferProhibited, plus registry lock for high-value domains) so nameservers cannot be changed or the domain transferred without extra authorisation. Secure the registrar and DNS-provider accounts with unique passwords and hardware-backed multi-factor authentication, since those two logins control the whole domain. Deploy DNSSEC to defeat cache poisoning, but validate it after every change so you do not join the 157,064 invisibly-down domains. Delete DNS records for retired services to close dangling-takeover holes, and add nameserver redundancy across independent providers. Then monitor for changes. A free scan at defaults.exposed flags the dangling records, missing DNSSEC, and single-nameserver fragility attackers look for first.

Data to cite

See where your own domain stands

DNS takeover is invisible until it is catastrophic. A dangling record, a missing signature, or a single nameserver is not a problem you feel day to day — it is a problem an attacker’s scanner finds before you do. The only defence that starts working today is knowing what your domain looks like from the outside.

Check your domain free at defaults.exposed — the scan reads your live DNS straight from public resolvers and tells you whether you carry dangling delegations, whether your DNSSEC is missing or broken, and whether you are running on a single fragile nameserver. It takes about 30 seconds and needs no account. If you want those gaps closed and watched — continuous monitoring that alerts on a new dangling record or an unexpected nameserver change before it becomes an incident — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Related from this series: Domain Dark Matter: 64 Million Delegated, Empty Domains · DNS Security Explained: Why 94 Million Domains Rely on Two Landlords · Broken DNSSEC: 157,064 Domains Are Invisibly Down · Single-Nameserver Domains: One Record From Oblivion

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned. All figures are counts of scanned domains. References: RFC 1035 (DNS), RFC 4033–4035 (DNSSEC).

How to cite this report

Press / blog: defaults.exposed (2026). DNS Hijacking and Spoofing: How Attackers Steal Domain Records. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/dns-hijacking-and-spoofing-how-attackers-steal-domain-records

Academic: defaults.exposed. (2026, August 21). DNS Hijacking and Spoofing: How Attackers Steal Domain Records. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/dns-hijacking-and-spoofing-how-attackers-steal-domain-records

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908 domains scanned)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →