Dangling DNS: how to find and fix it before takeover

Dangling DNS is one of those problems that's easy to create and genuinely hard to catch. A record keeps pointing at a cloud resource after the resource is gone, and unless something is watching for it, nobody notices until it becomes a problem. The good news is you don't have to work this out from scratch. Two of the most credible sources in security, OWASP and AWS, document why dangling DNS happens and what to do about it. This blog covers the risk, what each of them says, how to put their guidance into practice, and where the tooling gaps sit that leave most teams exposed.

Executive summary: Dangling DNS records let attackers take over a subdomain without breaching anything. OWASP and AWS both document the problem and the fix, and updated NIST guidance now names it directly. The fix is simple per record. The hard part is finding dangling records continuously across a real estate of multiple registrars and clouds, which is the gap Red Sift can cover.

Key takeaways:

• A dangling DNS record points to a cloud resource that's been deleted. If the resource name can be reclaimed, an attacker can serve their own content on your subdomain.
• This isn't a sign of a careless team. It's a structural side effect of how quickly cloud resources get created and retired.
• OWASP and AWS both document the problem, so there's clear, credible guidance to follow.
• AWS is candid that its platform doesn't close the gap for you: reclaimable resource names, no universal domain verification, and attackers already scanning for dangling records.
• The fix is straightforward per record. The hard part is continuous discovery across a multi-registrar, multi-cloud estate, which is where Red Sift Attack Surface Management helps.

A dangling DNS record is a DNS entry, usually a CNAME (Canonical Name, which aliases one name to another), that still points to a cloud resource after that resource has been deleted. The service is gone. The record isn't. On many cloud platforms, the resource name then goes back into a shared pool that any customer can claim. An attacker who recreates a resource with that name inherits your subdomain, because your DNS is still sending traffic there.

No breach, no stolen password. The record simply outlives the resource, and the gap it leaves is claimable.

The reason this matters more than a broken page is the trust your domain already carries. A subdomain your customers, browsers, and mail systems treat as yours becomes attacker-controlled. That opens phishing on a domain people recognize, theft of session cookies scoped to the parent domain, hijacked OAuth and SSO login flows, and valid TLS certificates issued in your name through domain-validation checks. If the record chain touches mail, it can mean intercepted password resets too. This is the "taken over" failure mode.

OWASP, the vendor-neutral standards community, treats subdomain takeover as an operational problem rather than a software bug, and its most useful point is also its simplest. Most organizations have no way to detect when the target of a DNS record quietly stops existing. That's the default state, not a failure of diligence. The record and the resource drift apart, nothing reconciles them, and the gap sits open until someone trips over it.

OWASP's prevention guidance is clear and practical: keep an inventory of what your records point to, remove records before the resources they depend on, and watch for the provider error strings a dead resource returns before anyone claims it. It's good, actionable advice, and it's free.

AWS documents this in its own security guidance, and the candor is worth crediting. It's upfront that the platform doesn't close this gap for you, and it names three reasons why:

• Many AWS services let a new customer claim a previously used hostname or resource name.
• AWS doesn't currently offer a universal domain-verification mechanism across its services.
• AWS incident response teams see attackers actively scanning public DNS for CNAME records that point to resources that no longer exist.

That last point matters. This isn't a theoretical risk sitting in a backlog. It's a live scanning behavior, happening now.

Here's the useful distinction between the two voices. OWASP isn't AWS, so it can advise but can't change how the cloud works. AWS could add universal controls, like domain verification that would neutralize most of this, but at this point it hasn't chosen to. That leaves a real gap between what the providers hand you and what you need to stay protected. It's not a gap you created, and closing it doesn't require waiting for a provider to act. It requires visibility, and visibility is something you can add today.

Following this advice for one record you're actively thinking about is easy. Applying it across an estate you can't fully see is the hard part. Cloud changed what DNS is used for, and estates grew with it. In one real enterprise, a single apex domain surfaced more than 25,000 subdomains, with ownership spread across infrastructure, marketing, developers, SaaS vendors, and cloud providers. No single team can see all of that by hand.

So the answer isn't a one-time cleanup. It's a repeatable operating model. These five stages, aligned to the NIST themes, turn the guidance into something you can actually run.

1. Inventory. Discover every domain, every zone, every record, regardless of who manages it: multiple registrars, multiple DNS providers, multi-cloud, and multiple certificate authorities. You can't protect what you haven't found.
2. Baseline. Characterize what good looks like: the registrars and DNS providers you sanction, your approved cloud ranges and certificate authorities, your email authentication posture, and where you sign with DNSSEC. Without a baseline, every change looks the same and nothing looks suspicious.
3. Detect and classify. Surface unexpected changes and suppress the expected noise. Roughly 1% of names change daily, which works out to about 375 events a day. Classification is the only thing that makes that operable.
4. Continuously evaluate. Run the estate against the NIST SP 800-81r3 themes: protecting the DNS service, zone transfer threats, zone content and consistency, minimizing information leakage, external domain integrity, and DNSSEC signing and validation.
5. Prioritize. Tier the estate so the model stays sustainable. Not everything needs the same attention.

Do this and OWASP's inventory advice and AWS's "remove the record before the resource" advice stop being aspirations. They become steps you can measure and repeat.

The stage that trips everyone up is the first one, because you can't inventory or monitor what you can't see, and neither the providers nor the free tooling give you a full view. Cloud-native config checks are useful but single-account and single-cloud by design. Open-source scanners cover more ground but only run when you remember to run them. The records that get taken over are rarely the ones you're thinking about. They're the ones you forgot, inherited in an acquisition, or never knew existed.

Red Sift ASM (Attack Surface Management) covers the gaps the platforms leave open. It discovers domains and subdomains across your entire external footprint, inspects DNS, web, and cloud configurations, and flags dangling records and claimable resources as they appear, across every registrar and cloud rather than one account at a time. In effect, it gives you the continuous verification layer AWS doesn't offer, applied to your whole estate.

Good DNS hygiene, removing the record before the resource, is the first line of defense, and both OWASP and AWS give you a solid playbook for it. Continuous discovery is what catches the records that slip through anyway. You don't need to wait for a provider to close the gap to get ahead of it.

See what your DNS is pointing to with Red Sift ASM or browse the full set of Red Sift guides for more on managing DNS and certificate risk.