Subdomain Takeover: Dangling DNS Records

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

The defect in one sentence, and why it is yours

A subdomain takeover happens when a DNS record on your domain still points at a cloud service you stopped using, and a stranger signs up for that service, claims the abandoned resource, and can then publish whatever they like at an address that is genuinely yours.

OWASP's Web Security Testing Guide, in test WSTG-CONF-10, states that the vulnerability requires two conditions at once: the external DNS record for a subdomain is configured to point to a non-existing or non-active resource, and the service provider hosting that resource does not handle subdomain ownership verification properly (OWASP WSTG-CONF-10).

Both halves matter, but only one of them is under your control, and it happens to be the one that is trivial to fix. No ICANN policy governs this. No registrar or registry is involved. It is a configuration defect in your own zone meeting a verification gap at a vendor — which is why the remediation is unilateral and immediate, and why nobody but you is going to do it.

How a record comes to dangle

The mechanic runs in three stages, and the middle one is where the defect is created.

Creation. You point docs.example.com at a provider-assigned hostname using a CNAME record — an alias saying “this name is really that other name,” which carries no assertion whatsoever that the target belongs to you. RFC 1034 defines the semantics that make this true (RFC 1034); the alias is a pointer, not a claim of ownership.
Deprovisioning. You delete the cloud resource or cancel the service. The provider releases that hostname back into its pool. Your CNAME is not removed, because nothing in the provider's workflow can reach into your zone. The record is now dangling: pointing at a resource that no longer exists.
Takeover. Someone provisions a new resource with the same provider and requests the same hostname. The provider hands it over, because it is unclaimed and because ownership of the pointing domain was never verified. Your subdomain now resolves, through your own zone, to their content, with your domain in the address bar.

OWASP names the abusable record types as A, CNAME, MX, NS and TXT, and flags NS as the most severe: a takeover of a delegation can give an attacker control over the whole DNS zone beneath it, not merely one hostname. The cheat sheet gives the concrete case — a subdomain delegated to a hosted zone that has since been deleted, where an attacker creates a new hosted zone for the same name and may be assigned matching nameservers (OWASP prevention cheat sheet).

The expired-domain variant

OWASP's second worked example does not involve a cloud provider at all. A CNAME on your domain references another domain, that domain later expires, and the attacker simply registers it. There is no service to claim and no fingerprint to detect — only an ordinary registration, made by anyone, at the moment the name becomes available.

This is where subdomain takeover and expired-domain loss meet directly, and it is the reason a dangling-record audit should resolve CNAME chains all the way to the end rather than stopping at the first hop. A record pointing at a vendor's hostname is one risk; a record pointing at a small vendor's own domain, or at an agency that has since closed, is the same risk with a longer fuse. The gTLD lifecycle determines when that fuse burns down: after deletion a name sits in a 30-day Redemption Grace Period and then a 5-day Pending Delete before it is released for anyone to register.

Why this is worse than defacement

The instinctive assessment — someone is serving content on a subdomain nobody uses — understates it considerably, because the attacker is operating inside your own origin. Microsoft's guidance on dangling DNS entries sets out the consequences: loss of control over subdomain content and the brand damage that follows; harvesting of session cookies from visitors, including cookies scoped to the parent domain; phishing conducted from an authentic subdomain, with working MX records; acquisition of valid TLS certificates for the subdomain, which both removes browser warnings and widens cookie access; and escalation into cross-site scripting, cross-site request forgery and CORS-bypass attacks.

That last item is the one that turns a forgotten record into a breach of the main application. CORS — the browser rule set deciding which other origins may read your site's data — is very commonly configured to trust your own subdomains, on the reasonable-sounding assumption that you control them all. A takeover makes that assumption false without changing a line of the policy.

Assuming HTTPS protects you is the related error. The attacker obtains their own certificate for the subdomain through the provider, so the padlock appears exactly as it should.

Testing for it

OWASP sets out a three-phase methodology, and the third phase is not optional (OWASP WSTG-CONF-10).

Enumeration. Discover which subdomains exist, drawing on Certificate Transparency logs, passive DNS and brute force. Your zone file is a starting point, not the answer, because delegated child zones and records nobody documented will not be in the inventory you keep.
Fingerprint detection. Match the error page each service returns against known signatures to identify resources that are gone and claimable. Tooling exists for this and it is fast; OWASP names examples for both enumeration and fingerprinting.
Manual validation. Confirm both the DNS record and the actual service state before reporting anything. Fingerprints produce false positives, and a report that turns out to be a service responding oddly costs you credibility on the next one.

If you do find a dangling record, investigate before you delete. Deleting it destroys the evidence of whether it had already been claimed and what was served from it. Assume it may have been in use.

Common mistakes

Decommissioning a service without a matching step to delete the DNS record. This single omission is the root cause of the entire class.
Doing it in the wrong order: deleting the cloud resource first opens the window immediately, and it stays open until somebody notices.
Leaving the CNAME in place “in case we come back to it.” You will not, and the record will outlive everyone who remembers why it exists.
Auditing only the subdomains listed in internal documentation, when the zone contains records nobody remembers creating.
Forgetting NS records delegated to a third-party DNS provider whose account was closed — the highest-severity case, and the one least likely to appear in an application inventory.
Ignoring TXT records used for SaaS domain verification, which OWASP lists among the abusable types.

The pattern underneath all six is ownership. Records are created by whoever needed a hostname that afternoon and are never assigned to anyone thereafter, so at decommissioning time there is no one whose job it is to remove them.

Getting the order of operations right

The OWASP cheat sheet gives a decommissioning sequence, and following it removes the exposure entirely rather than shortening it (OWASP prevention cheat sheet):

Redirect or preserve the subdomain first, so that links do not break.
Update or remove the DNS record.
Wait out the TTL — the number of seconds resolvers may cache the answer, typically between 300 and 3,600 — so that no resolver is still handing out the old answer.
Only then decommission the cloud resource.

Do it in that order and there is never a moment when a live record points at a released resource. Do it in the reverse order, which is the intuitive order, and you create the vulnerability yourself.

Standing controls worth having

An inventory mapping every DNS record to the service it points at and a named owner. Without an owner, no record is ever anybody's to delete.
Weekly scanning of your own zone for cloud-provider error fingerprints indicating a missing resource, as the OWASP cheat sheet recommends, alongside Certificate Transparency monitoring.
Version-controlled DNS and CI/CD checks that validate record cleanup during deprovisioning, so the runbook is enforced rather than remembered.
A preference for providers that require proof of domain ownership before serving a custom hostname — typically a verification TXT record tied to the account. This removes OWASP's second precondition outright, which is worth weighing when choosing a vendor.
Provider record types whose lifecycle is coupled to the resource, where they exist, so the reference disappears when the resource does.
Dangling-record checks in offboarding, triggered whenever a SaaS contract ends rather than whenever someone remembers.

None of this is difficult. It is unowned, which is a different problem and a harder one.

Frequently Asked Questions

How do I fix a subdomain takeover?

Delete the stale DNS record, which ends the takeover immediately and needs no cooperation from a registrar, a registry or the cloud provider. Before deleting it, capture what the record pointed at and what was being served, because that evidence is gone once the record is. Then work out the residual exposure: any content already served under your name, any session cookies collected from visitors, any TLS certificate the attacker obtained for the subdomain, and any CORS or authentication policy elsewhere in your systems that trusts subdomains of your domain implicitly.

What is a dangling DNS record?

A dangling record is a DNS record that points at a resource which no longer exists — most often a CNAME aliasing a cloud provider hostname for a service that was deleted or cancelled. The record keeps resolving because DNS has no way to know the target is gone; a CNAME is an alias, not a claim of ownership, so nothing verifies that the target is still yours. The record becomes a vulnerability at the moment the provider releases that hostname back into its pool, where any customer can claim it.

Can a subdomain takeover affect my main website?

Yes, in several ways that are easy to underestimate. Session cookies are frequently scoped to the parent domain and readable by any subdomain, so an attacker serving script from a subdomain of yours may be able to read them. CORS policies routinely trust your own subdomains, which turns a takeover into read access against your main application's data. Authentication flows, single sign-on redirect allowlists and content security policies that whitelist by domain suffix have the same problem. And phishing sent from a genuine subdomain of your brand is markedly more effective than any lookalike domain.

Does HTTPS prevent subdomain takeover?

No. Once an attacker controls the resource your record points at, they can obtain their own domain-validated TLS certificate for that subdomain — issuance depends only on demonstrating control of the name, which they now have. The certificate is genuine and publicly trusted, so the browser shows a padlock and no warning. HTTPS makes the takeover more convincing rather than less. What HTTPS does give you is Certificate Transparency: certificates issued for your subdomains appear in public logs, so monitoring those logs can surface a takeover you did not otherwise detect.

Which DNS record types can be taken over?

OWASP names A, CNAME, MX, NS and TXT records. CNAME is the most common in practice because it is how custom hostnames are attached to cloud services. NS is the most severe: taking over a delegation can hand an attacker control of the entire DNS zone beneath that subdomain rather than a single hostname, so every record under it becomes theirs to write. MX enables mail sent and received under your name. TXT records used for SaaS domain verification are the least obvious and are routinely left behind when a service is cancelled.

How often should we scan for dangling records?

The OWASP prevention cheat sheet recommends weekly scanning for cloud-provider error fingerprints that indicate a missing resource, combined with Certificate Transparency monitoring. Weekly is a reasonable floor for an organization of any size, because the window between a resource being released and someone claiming it is not predictable. The more durable fix is structural rather than scheduled: put DNS under version control, add a CI/CD check that validates record cleanup during deprovisioning, and make dangling-record review part of offboarding whenever a SaaS contract ends.

Who is responsible — us or the cloud provider?

Both preconditions are required, so both parties contribute, but the practical answer is that you own the remediation. OWASP identifies the second condition as the provider failing to verify subdomain ownership properly before serving a custom hostname, and providers that require a verification record before accepting a hostname eliminate that half of the defect. You cannot make a provider adopt that control on your timetable. You can delete your own record in seconds. Choose providers that verify ownership where the choice exists, and treat your zone as the part you are accountable for.

Subdomain Takeover