Export every record in your zone, resolve the target of each CNAME, and check whether the service behind it still exists and belongs to you. Records pointing at deleted cloud resources are dangling and can be claimed by someone else. Delete them, or re-point them, before a stranger does it for you.
What a dangling record is
A dangling record is a DNS entry whose target no longer serves your content. The usual case is a CNAME that points at a hosted app, storage endpoint or platform subdomain you have since deleted. Microsoft's guidance describes the sequence: a resource is created and given a CNAME, the resource is later deprovisioned, the CNAME stays, and another party then provisions a resource with the same name and receives your traffic.
MDN describes the result the same way, noting that an attacker who takes over the name can potentially read cookies set from the main domain, run cross site scripting or get around content security policies. The background is in our explainer on dangling DNS and subdomain takeover. This post is the audit.
Step by step audit
- Export the zone. Pull a full record list from each DNS provider, including the ones nobody remembers. Zone export or API listing is better than the web table.
- List targets. Keep records that point elsewhere: CNAME, and also A or AAAA records that point at cloud IP addresses you may have released, plus NS records for delegated subdomains.
- Resolve each target. Query the name and note the result: a normal answer, NXDOMAIN, or a provider "no such site" page.
- Check ownership. For each live target, confirm a resource in one of your accounts matches it. If no one can name an owner, treat it as suspect.
- Triage. Use the table below.
- Fix and record. Remove or repair the record and note who decided and when.
| Result | Meaning | Action |
|---|---|---|
| Target returns NXDOMAIN | Target name does not exist | Delete the record, or recreate the resource yourself |
| Provider shows an unclaimed or default page | Name is free to claim on that platform | Delete now, then investigate |
| Target is live and in your account | Healthy | Add an owner tag in your inventory |
| Target is live, owner unknown | Possible third party content | Ask around, then remove if unclaimed |
Cases that are easy to miss
- Delegations. An NS record that hands a subdomain to a name server you no longer run is a takeover path of its own.
- Old environments. Staging, preview and demo subdomains are often created by a script and never deleted.
- Email and verification records. CNAME entries created for a mail or marketing platform can outlive your contract with it.
- Released IP addresses. An A record to a cloud address you gave back may point at someone else's server later.
Make it routine
Run the audit once, then schedule it. Resolve targets weekly and alert on any change from healthy to NXDOMAIN. Add a step to your offboarding of any hosted service: remove the DNS record first, then delete the resource. Our checklist for decommissioning a subdomain safely covers the order.
Try it yourself
The continuous monitoring demo shows how a change in a tracked inventory is surfaced. Click through it and look at how a newly appearing item is flagged for review, which is the same habit you want for DNS targets.
Click through it at your own pace, or open it full screen.
Safeguard covers the software side: asset discovery, SBOM and dependency scanning, and reachability analysis. DNS audits stay with your DNS tooling. The free scan is at gold.safeguard.sh/scan.
Quick check
How often should I check for dangling records?
Weekly is a sensible default for an automated check, plus a manual review whenever a service is retired.
Is deleting a suspicious record safe?
Usually yes, but confirm nothing still relies on it. Check traffic logs, or lower the record lifetime first so a rollback is quick.
Sources
Last reviewed: 19 October 2026.
