Dangling DNS Record
A dangling DNS record is a published DNS entry (A, AAAA, CNAME, NS, or MX) that still points to an IP address or third-party resource that has been deprovisioned, released, or expired, leaving the name resolving to infrastructure your organization no longer controls. Because anyone who reclaims that underlying IP or service inherits the traffic, dangling records enable interception, content control, and subdomain takeover.
Decommissioning a server feels like the end of a task, but in DNS it is only half of one. The moment a cloud instance is torn down or a SaaS endpoint is cancelled, the A or CNAME record that pointed to it keeps answering queries for everyone on the internet, quietly advertising an address you no longer own. That orphaned pointer is a dangling DNS record, and it is broader than the subdomain takeover headlines suggest: it covers any record whose target has been released back to a shared pool where an adversary can grab it. The gap between deleting the resource and deleting the record is the entire attack window.
Reviewed by Aakash Harish
Security Research Contributor, Legba
Reviewed 2026-05-28 · Updated 2026-05-28
What it is
A dangling (or orphaned) DNS record is a resource record in an authoritative zone whose target no longer resolves to infrastructure under the record owner's control. The classic lifecycle, documented by Microsoft, is: you provision a cloud resource with a fully qualified domain name, point a CNAME such as app.example.com at it, later deprovision the resource, but forget to remove the CNAME. The record is now advertised as live yet routes to nothing the organization owns. The danger materializes when the released target can be re-claimed: an attacker registers the same cloud FQDN, re-uses the freed elastic IP, or re-registers an expired domain referenced by an NS or MX record, and instantly inherits all traffic destined for the dangling name. This is a superset of subdomain takeover (see the related subdomain-takeover finding): subdomain takeover is the exploitation outcome when the dangling target happens to be a claimable third-party service, while dangling records also include A/AAAA records pointing to recycled IP ranges and NS/MX delegations to lapsed domains where the takeover mechanics differ.
What an organization stands to lose here is not an abstract server but the trust embedded in its own domain. Once an attacker controls the resource behind a dangling record, every browser, mobile app, and partner integration that resolves that name hands them traffic. Microsoft documents the direct consequences: harvesting of session cookies scoped to the parent domain (including Secure cookies, because the attacker can mint a valid TLS certificate for the hijacked name), credential phishing under an authentic-looking hostname, interception of email when an MX record is involved, and escalation into XSS, CSRF, and CORS bypasses against the trusted parent site. CISA considered DNS pointer integrity serious enough that Emergency Directive 19-01 compelled federal agencies to audit every public DNS record and confirm it resolves to its intended destination. The reputational and regulatory fallout from a phishing page or data-exfiltration site served from your own subdomain typically dwarfs the trivial cost of deleting one stale record.
At a glance
How attackers find and exploit it
- Enumerate the target's full DNS footprint using passive sources (certificate transparency logs, passive DNS databases, search-engine scraping) and active brute-force of subdomain wordlists to build a candidate list of records.
- Resolve each record and flag candidates whose CNAME targets a known third-party service fingerprint, whose A/AAAA record points to an IP that returns no service or a default cloud landing page, or whose NS/MX target domain is unregistered.
- Query the suspected target service directly: request the cloud FQDN or hit the IP on common ports to confirm it returns a 'NoSuchBucket', '404 Not Found', 'There isn't a GitHub Pages site here', or provider-specific 'unclaimed' response indicating the resource is free to claim.
- Re-claim the released resource by registering the same bucket or app name with the cloud provider, allocating the freed elastic IP, re-registering the expired delegated domain, or onboarding the unclaimed SaaS endpoint to the attacker's own account.
- Serve attacker-controlled content from the now-hijacked subdomain, obtain a domain-validated TLS certificate for it via an ACME challenge to lend it legitimacy, and use it for cookie theft, phishing, malware delivery, or interception of email and API traffic that still resolves to the dangling name.
How to detect it on your surface
- Export the complete set of resource records from every authoritative and secondary zone you operate, including records held at registrars and third-party managed-DNS providers, so the inventory is not limited to your primary zone file.
- For each A/AAAA record, cross-check the target IP against your current cloud inventory and IPAM to confirm the address is still allocated to and controlled by your organization.
- For each CNAME record, identify the target service and verify the corresponding resource (bucket, app, distribution, page, SaaS tenant) still exists and is owned by you, treating common cloud and SaaS suffixes as high priority.
- For NS and MX records, confirm every delegated nameserver domain and mail-exchange domain is registered, unexpired, and under your control, since a lapsed delegation target is as exploitable as a freed IP.
- Reconcile the DNS inventory against your decommissioning and change-management tickets to surface records whose backing resource was deleted but whose entry was never removed.
Detection signals
- A CNAME or HTTP request to the target returns a provider 'unclaimed resource' fingerprint such as 'NoSuchBucket' (S3), 'There isn't a GitHub Pages site here.', Heroku's 'No such app', or Azure's default 'Web App - Unavailable' page.
- An A/AAAA record resolves to an IP that no longer answers on expected ports, returns connection refused, or now serves an unrelated default cloud splash page indicating the IP was recycled to another tenant.
- An NS or MX record delegates to a domain whose WHOIS shows it is unregistered or expired, or whose nameservers return SERVFAIL/REFUSED for the delegated zone.
- DNS resolution succeeds (NOERROR with a valid answer) while the underlying service health check, TLS handshake, or application monitor for that hostname has been failing, indicating a live pointer to dead or foreign infrastructure.
Validate before you report
- Resolve the record end to end and capture the live answer chain (A/AAAA, CNAME target, delegated NS, or MX host) as timestamped evidence rather than relying on the cached zone file.
- Probe the resolved target on its expected protocol and record the exact response body, status code, and any provider claim-state fingerprint that proves the resource is released and re-registrable.
- Confirm reclaimability without hijacking production: check whether the cloud FQDN or bucket name is available to register, or whether the delegated domain shows as available at the registrar, to distinguish a truly orphaned target from one merely behind a firewall.
- Determine the blast radius by checking whether cookies, CSP allowlists, OAuth redirect URIs, or email routing for the parent domain extend to the dangling name, since this separates a low-impact orphan from a high-impact takeover path.
- Document the responsible owner and the decommissioning gap by correlating the record against asset and change records, so the validated finding ships with the context needed to remediate and to prevent recurrence.
What looks like this but isn't
- An internal-only or split-horizon record that resolves to an RFC 1918 private IP or an intentionally non-public target is not exploitable from the internet; confirm the record is actually externally resolvable before flagging it.
- A record pointing to a temporarily stopped or scaled-to-zero resource you still own (for example a paused App Service or a stopped instance retaining its reserved IP) looks dead but is not reclaimable by an attacker; verify ownership and reservation state, and treat alias records that auto-empty on deletion as self-healing.
Remediation
- Immediately remove the dangling record from the authoritative zone, or repoint it to a current resource you own, prioritizing NS and MX records and any subdomain that shares cookies or trust with the parent domain.
- If the target may already be hijacked, treat it as an incident: revoke and rotate any secrets, OAuth tokens, or session cookies that could have been exposed to the subdomain, and review logs for traffic sent to the orphaned name.
- Where the provider supports it, bind the record's lifecycle to the resource using alias-style records that automatically empty when the backing resource is deleted, and enable domain-ownership verification (for example a TXT verification record) so no other tenant can claim the name.
- Fix the process that left the record behind by adding 'remove or repoint DNS record' as a mandatory, gated step in every decommissioning runbook before the underlying resource is torn down.
- Reverse the teardown order going forward: serve maintenance content or repoint the name, update or delete the DNS record, wait for TTL/propagation, and only then deprovision the cloud resource, as recommended by the OWASP prevention guidance.
- Re-scan the full external surface after cleanup to confirm the record is gone and that no sibling records share the same root cause.
Operational checklist
- Maintain a service catalog mapping every public DNS record to its backing resource and a named owner, refreshed continuously rather than at audit time only.
- Run automated dangling-record detection across all zones and registrars on a recurring schedule, covering A/AAAA, CNAME, NS, and MX records.
- Apply deletion locks or change controls to any resource that has a custom DNS name so the pointer must be removed before the resource can be destroyed.
- Prefer lifecycle-coupled alias records and enforce per-service ownership verification (claim tokens, verification TXT records) wherever the platform offers them.
- Keep DNS record TTLs deliberately short for resources that change frequently so cleanup propagates quickly, and review CT logs for unexpected certificates issued against your subdomains.
- Gate every decommissioning ticket on a DNS-cleanup sign-off and reconcile completed teardowns against the live zone weekly.
What to do next
A dangling DNS record is one of the cheapest exposures to fix and one of the most expensive to ignore: deleting a stale line in a zone file costs minutes, while letting an attacker claim the resource behind it can cost you a phishing page, harvested sessions, and intercepted mail flying under your own brand. The pattern is preventable with one discipline change, removing or repointing the record before the resource dies, and one standing control, continuous reconciliation of every public record against a resource you actually own. The concrete next step is to pull your full external DNS inventory today and validate, not just resolve, every record whose target you cannot positively confirm.
Methodology
Each finding-type guide is built from Legba Recon's real detection and validation logic, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.
FAQs.
References.
- 01
- 02Subdomain Takeover Prevention Cheat SheetOWASP Cheat Sheet Series
- 03
- 04Subdomain takeoverMDN Web Docs
- 05CAPEC-142: DNS Cache PoisoningMITRE CAPEC
