Find and Delete Dangling DNS Records Before Attackers Do

A dangling DNS record is a record that still points at a service you no longer run, like a closed blog platform account or a deleted cloud app. If that record is a CNAME, a stranger can sometimes sign up at the same provider, claim the name, and serve their own content on your subdomain. The fix is simple: export your zone, check every CNAME target, and delete the ones that point at nothing you own.

Here is the part that surprises most people. Microsoft's own security guidance says an attacker who takes over your subdomain can use it to get a valid TLS certificate for it, so the padlock in the browser will look normal. Your HTTPS setup does not protect you here, because the attacker is not breaking it. They are simply standing where your old service used to stand.

By the end of this guide you will be able to back up your DNS zone, find every CNAME that points somewhere outside your domain, test each target, delete the dead ones safely in cPanel or Cloudflare, and confirm the cleanup worked.

What a dangling DNS record actually is

A CNAME record (short for canonical name) says "this name is an alias for that other name". RFC 1035, the original DNS standard, describes the owner of a CNAME as an alias and the target as the canonical or primary name. So blog.example.com might be an alias for a hostname at a blogging or hosting provider.

MDN, Mozilla's web documentation, describes the problem like this: a subdomain takeover happens when a subdomain has a CNAME in DNS but no host is providing content for it. That can happen before a site is published, or after you remove the site but forget the DNS record.

MDN uses a nice analogy, and it is worth keeping in your head. Your subdomain is like an electrical outlet. If you unplug your appliance but leave the power on at the breaker (DNS), anyone can walk up and plug in their own.

Why this matters: MDN says what an attacker can do from your subdomain. They can potentially read cookies set from the main domain, run cross-site scripting, get around content security policies, capture logins, or send malicious content to your visitors. Microsoft adds phishing from an authentic-looking name, and says that if MX records are involved, attackers could receive email sent to your subdomain.

Made-up example: you used a hosted blog service for two years at blog.example.com. Last spring you moved the posts to your main site and closed the blog account. The CNAME for blog still points at example-blog.provider.example.com, a made-up provider hostname. If that provider lets anyone register the name example-blog again, the next person to do so controls what visitors see at blog.example.com. Nothing on your main site changed, and nothing alerts you.

Before you start

This is a low-risk job if you go slowly, and a painful one if you delete the wrong record. Gather these first.

• Login to wherever your DNS is hosted. This is usually your hosting control panel (cPanel), your DNS provider (Cloudflare), or your domain registrar. If you are not sure, check where your nameservers point.
• Logins for the third-party services you have used: hosting accounts, website builders, landing page tools, help desk tools, email services, cloud platforms. You need these to confirm that each target still belongs to you.
• A terminal with dig, the DNS lookup tool from BIND 9. If you cannot use a terminal, you can still do the account checks by hand.
• A backup of your current zone. You will make this in Step 1. Do not skip it.
• Time: 30 to 60 minutes for a small business zone with a few dozen records. Larger zones take longer.
• Someone who knows the history. If a colleague or agency set up records years ago, ask them before deleting anything you do not recognise.

Heads up: email records are the classic accident. MX records, SPF in TXT records, and DKIM keys published as CNAME records look strange but are often essential. Treat every mail-related record as "keep" until you have proved otherwise. Our guide to SPF, DKIM and DMARC for small business email explains what each one does.

Step-by-step: find and remove dangling records

Step 1: Export your DNS zone as a backup

You want a full copy of every record before you change anything, so you can put a record back in a minute if you got it wrong.

In Cloudflare, go to the DNS Records page for your domain, select Import and Export, then select Export. Cloudflare's documentation says the export uses zone file format, and each record's comments and tags are added as an inline comment starting with ;.

If you prefer the API, this request downloads the same export. You need a token with DNS Read or DNS Write permission, and your zone ID.

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export" \
  --request GET \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

The dashboard gives you a file to download, and the API prints the same text in your terminal, which you can copy into a file named example.com.zone.txt. Either way you should see one record per line. Proxied records carry the tag cf-proxied:true and DNS-only records carry cf-proxied:false, which matters later.

In cPanel, open cPanel > Domains > Zone Editor and click Manage next to your domain. The Manage Zone screen shows each record with its Name, TTL, Type and Record value. The cPanel documentation does not describe a zone file export from this screen, so copy the table into a text file or spreadsheet, or take screenshots. If your host offers a full account backup, take one as well.

Quick tip: save the backup with the date in the file name, for example example.com-zone-2026-10-23.txt. You will thank yourself in six months.

Step 2: List every CNAME record

Now you want only the aliases, because those are the records most likely to dangle. Microsoft's guidance calls CNAME records especially vulnerable.

If you have a Cloudflare export file, this command prints every line that contains a CNAME record.

grep CNAME example.com.zone.txt

You should see lines that look roughly like this sample, with your own names and targets.

blog.example.com.    300  IN  CNAME  example-blog.provider.example.com. ; cf-proxied:false
shop.example.com.    300  IN  CNAME  example-shop.provider.example.com. ; cf-proxied:true
selector1._domainkey.example.com.  3600  IN  CNAME  selector1.mail.example.com.

In cPanel, use the record type filter in the Manage Zone screen to show only CNAME records. The cPanel documentation says you can filter the list by entering a name or by selecting a record type filter.

Write each CNAME into a simple list: the name, the target, and a note on what it was for. If the target ends in your own domain, for example www.example.com, it is usually safe because you control that name. Focus on targets at other companies.

Step 3: Ask what each target is, and who owns it

This is the step that matters most, and it is not a technical one. For each external target, answer two questions. Does the service behind it still exist? And is it in an account that you or your company control?

Microsoft's advice is exactly this: regularly review your DNS records and confirm that each target exists and is owned by your organisation. Log into the provider account and look for the site, app, or custom domain setting that matches the hostname.

Heads up: do not guess. A target that still resolves in DNS is not proof that it is yours. A target that looks unfamiliar is not proof that it is dead. Only the provider account tells you the truth.

Sort each record into one of three groups.

• Keep: the service exists and you can see it in your own account.
• Delete: the service is gone, the account is closed, or you no longer use that provider.
• Ask first: nobody knows. Find the person who created it, check old invoices, or ask the provider's support.

Step 4: Test each target with dig

DNS tests give you useful evidence for the "Delete" and "Ask first" groups. dig is a DNS lookup tool, and its manual gives the basic form as dig @server name type.

This command asks for the CNAME of your subdomain and prints only the short answer.

dig blog.example.com CNAME +short

You should see the target hostname, for example example-blog.provider.example.com., if the CNAME is published and not proxied.

This command checks whether the target itself still exists in DNS. The +noall +answer options clear the extra output and show only the answer section.

dig example-blog.provider.example.com +noall +answer

If you see one or more address records, the name exists at the provider. If you see nothing, run it again without the options to read the full header.

dig example-blog.provider.example.com

Look at the status in the header. A status of NXDOMAIN means the authoritative server says the name does not exist (RFC 1035 calls this a Name Error). For a CNAME target, that is a strong hint the old service is gone.

Why this matters: a target that does not exist is not automatically safe. It may be exactly the name an attacker can register at the provider. That is why Step 3 comes first, and why you delete rather than ignore.

Heads up for Cloudflare users: if a record is proxied, Cloudflare's documentation says lookups resolve to Cloudflare anycast IPs instead of the original DNS target. So dig from outside will not show you the real target of a proxied CNAME. Use your zone export or the dashboard to read the target instead, then run dig against the target hostname directly.

Step 5: Visit the subdomain in a browser

Open a private browser window and go to the subdomain, for example https://blog.example.com. You are looking for anything that is not your content.

Typical warning signs are a generic error page from the provider saying the site does not exist, a parking page, or a certificate warning. Any of these suggests the alias points at a provider that has no working site for you.

If you see content you did not publish, treat it as a possible takeover, not a cleanup job. Jump to the security notes further down.

Step 6: Delete the dead records

Delete one record at a time, then test, then move to the next. That way, if something breaks, you know exactly which change caused it.

In Cloudflare, go to the DNS Records page, find the record, select Edit, then select Delete, and select Delete again to confirm. These are the steps in Cloudflare's own documentation.

In cPanel, open cPanel > Domains > Zone Editor, click Manage next to the domain, click Delete next to the record, then click Continue in the confirmation dialog.

The Cloudflare API can also delete a record, but for a one-off cleanup the dashboard is simpler.

After each deletion you should see the record disappear from the list. Write the deletion into your notes with the date and the reason.

Step 7: Fix the process so it does not happen again

The record dangled because someone shut down a service and stopped there. MDN says the order of operations is the real defence.

• When you set up a new service, claim the site or custom domain at the provider first, and create the DNS record last.
• When you shut down a service, remove the DNS record first, then delete the service.
• Keep an inventory of your domains, subdomains and the provider behind each one, and update it when things change.

Microsoft says the same thing in a different way: make "remove DNS entry" a required check when you decommission a service. If you move hosts often, add this to your website migration plan as its own line item.

Variants worth knowing

Cloudflare proxied records

Proxied CNAMEs hide their target from public lookups, as noted in Step 4. Your zone export still lists them, tagged cf-proxied:true. Check these by reading the target from the export, not by running dig on your own subdomain.

Records that look like CNAMEs but are not

The same thinking applies to any record that sends people or mail somewhere you no longer control. Microsoft's guidance specifically mentions MX records being abused to receive email for a subdomain. If you stopped using a mail provider, confirm its MX records are gone too, after you are sure no mailbox still depends on them.

Azure, as one example of a cloud provider

Microsoft's page goes deeper for Azure customers. It describes a PowerShell tool called Get-DanglingDnsRecords that finds dangling CNAMEs, and Azure DNS alias records that tie a record's life to the resource, so the record empties when the resource is deleted. At the time of writing (23 October 2026), the page lists alias record support for Azure Front Door, Traffic Manager, Azure CDN endpoints and public IPs. If you use Azure, read that page in full. Other clouds have their own tools, but the manual review in this guide works everywhere.

How to check it worked

Run these checks for each record you deleted, and once more for the zone as a whole.

1. Confirm the record is gone from the authoritative view. In Cloudflare or cPanel, search the record list for the name. It should not be there.
2. Ask DNS directly. The command below should print nothing once caches have expired.
3. Check the status in the full output. It should show NXDOMAIN for the name, unless you still have other records at that same name.
4. Visit the subdomain in a private browser window. It should fail to resolve, instead of showing a provider error page.
5. Take a fresh export and compare it with your backup. The only differences should be the records you meant to delete.

This command checks whether the deleted CNAME is still being served.

dig blog.example.com CNAME +short

Remember that resolvers may keep the old answer for a while. RFC 1035 defines the TTL (time to live) as the time a record may be cached before the source should be asked again. If the old record had a TTL of 3600, give it up to an hour. Our guide on lowering DNS TTL before a hosting move explains caching in more depth.

Quick tip: the dig manual says BIND 9's dig accepts several queries on one command line, with global options such as +short placed before the first query. That is handy when you want to recheck a batch of names in one go.

dig +short blog.example.com CNAME shop.example.com CNAME

Troubleshooting

I deleted the record but the subdomain still works

Symptom: dig or the browser still returns the old answer. Likely cause: your computer, your network, or a public resolver cached the record for the length of its TTL. Fix: wait at least one full TTL period, then test again. You can also ask the authoritative nameserver directly with dig @ns1.example.com blog.example.com CNAME +short, replacing ns1.example.com with one of your real nameservers.

dig shows Cloudflare IP addresses instead of the target

Symptom: you expected a provider hostname but got IP addresses. Likely cause: the record is proxied, and Cloudflare returns its anycast IPs instead of the original target. Fix: read the target from your zone export or the dashboard, then test the target hostname itself with dig.

Email stopped arriving after the cleanup

Symptom: messages bounce or go missing after you deleted records. Likely cause: you removed an MX record, a TXT record used for SPF, or a DKIM CNAME such as one under _domainkey. Fix: restore the exact record from your Step 1 backup. Then confirm with your email provider which records it needs, before you touch mail records again.

The target returns NXDOMAIN, but the service is still in my account

Symptom: your provider dashboard shows the site, yet the target name does not resolve. Likely cause: the provider changed its hostnames, or the custom domain was removed from the site even though the site itself remains. Fix: in the provider dashboard, find the current hostname or domain setting it wants you to use, and update the CNAME to match. Do not leave the old one in place.

A subdomain shows content I did not publish

Symptom: a page, redirect or login form at your subdomain that you do not recognise. Likely cause: possible takeover. Fix: MDN says the first step is to "cut power" by removing the DNS entry. Delete the record, then investigate. Microsoft also advises checking whether secrets such as OAuth credentials or sensitive data were sent to the subdomain, and following your incident response steps.

I cannot tell whether a record is still needed

Symptom: a CNAME with a target you do not recognise, and nobody remembers it. Likely cause: an old integration or a verification record. Fix: search your email and invoices for the provider's name, and ask the provider's support whether that hostname is linked to your account. If it truly belongs to nobody, delete it, keep the backup, and watch for complaints for a week.

Security notes and when to get help

A takeover can give an attacker a valid certificate for your subdomain, as Microsoft's page explains. RFC 8659 says a CAA record lets you name the certificate authorities allowed to issue certificates for your domain. That narrows the field, but it does not remove the dangling record, so CAA is no substitute for deleting it. Do both. See our guide on CAA records and choosing certificate authorities.

Microsoft also notes that web apps often share session cookies across *.example.com. If your main site sets cookies for the whole domain, a takeover of any subdomain is more serious, so mention this to your developer.

Ask your host or a developer for help if your zone has hundreds of records, if you find content you did not publish, or if you are unsure whether a record supports email or a payment flow. Handing them your backup file and your Keep, Delete, Ask first list will save everyone time.

The one message worth forwarding

Copy this to your developer, host, or whoever manages your DNS.

"Hi, I am cleaning up dangling DNS records on example.com to prevent subdomain takeover. I have exported the zone as a backup and listed every CNAME that points at an outside provider. Could you confirm which of these targets still exist in accounts we control? I plan to delete any that point at closed or deleted services, one at a time, and test after each. From now on, can we make 'remove the DNS record first' a required step whenever we shut down a service? Thanks."

Every DNS record you leave behind is a promise that something still lives there, so delete it before someone else makes that promise true.