Dangling DNS: How Old Records Let Someone Else Use Your Domain

Here’s a job for your next quiet afternoon: delete the records you don’t need any more. It sounds like housekeeping. It’s actually one of the easier ways for someone to put their own content on your domain.

What “dangling DNS” means

A few years ago you signed up for a service. A landing page builder, a help desk, a cloud storage bucket, a test app. It asked you to create a record like this:

CNAME  promo.webcontrol-example.com  →  webcontrol-promo.someplatform.example

The campaign ended. You cancelled the service. Nobody deleted the record.

Now promo.webcontrol-example.com points at a name on someone else’s platform that nobody owns any more. On many platforms, anyone can sign up and claim that name. When they do, your subdomain shows their content.

That’s a subdomain takeover.

Why it’s worse than it sounds

The attacker isn’t on a look-alike domain. They’re on your domain, with a real HTTPS certificate. So they can:

• host a phishing page at login.webcontrol-example.com that’s genuinely yours as far as the browser is concerned
• publish fake invoices or “pay here” pages that customers have every reason to trust
• in some setups, read cookies set for your whole domain
• damage your search ranking with spam content

And because it’s a forgotten record, nobody is watching it.

What’s most at risk

Any record that points at a name or address you don’t control:

• CNAMEs to cloud and SaaS platforms: app hosting, storage buckets, website builders, help desks, status pages, marketing tools.
• A records to cloud IP addresses you’ve given back. Cloud providers hand released IPs to their next customer.
• NS records delegating a subdomain to DNS hosting you’ve closed. This one is the worst: whoever picks it up controls everything under that subdomain.
• MX records to a mail service you’ve left.

When the domain at the other end expires

Everything above assumes the platform is still running, and someone has to sign up there to claim your old name. There’s a quieter version where nobody needs an account anywhere: the domain your record points at stops being registered.

The provider went out of business

Say you used a small booking tool for a few years. Your DNS has:

CNAME  book.webcontrol-example.com  →  webcontrol-example.bookingtool.example

The company folds. Their servers go dark, your booking page stops loading, and it’s easy to assume that’s the end of it. Then nobody renews bookingtool.example, and it goes back on the market for the price of an ordinary registration.

Whoever buys it owns the whole domain. They don’t need to claim your name on anyone’s platform. They create webcontrol-example.bookingtool.example themselves, get a certificate, and book.webcontrol-example.com shows their content. They get every other former customer’s subdomain at the same time, which is what makes a dead provider’s domain worth buying.

It’s worse when the provider did more than host a page:

• NS records pointing at a closed DNS host’s nameservers, such as ns1.olddnshost.example. Register olddnshost.example, run nameservers under it, and you answer for every subdomain delegated to it.
• MX records for a mail provider that’s gone. The new owner receives your email, including password reset links.
• An SPF include: for a sending service that’s gone. The new owner publishes their own SPF record, and their servers are now allowed to send email as you.

A domain you used to own

The same thing happens with your own old domains. Say the online shop was set up when the business had a different name, and after the rebrand someone added this instead of moving it:

CNAME  shop.webcontrol-example.com  →  shop.oldbrand.example

A couple of years later the renewal notice for oldbrand.example arrives. “We don’t use that any more,” so it’s left to lapse. Someone registers it, and not by accident: old business domains still get visitors, links and email, and that’s worth something to a scammer. They set up shop.oldbrand.example, and your shop address now serves their page.

Old domains turn up in more places than CNAMEs. Check for them in SPF records, in DMARC report addresses (rua=mailto:[email protected]), in email forwarding, and as the login email on accounts like your registrar or Cloudflare. If the new owner can receive mail at the old domain, they can reset those passwords.

The nasty part of both cases is that nothing in your DNS changes. The record looks exactly as it did the day it was added. While the target domain is unregistered, visiting your subdomain just gives a “server not found” error, which looks broken rather than dangerous.

How to check your own domain

1. Export your DNS records. In Cloudflare: DNS → Records → Import and Export → Export. Other providers have something similar.
2. For each CNAME, NS and A record, ask: do we still use this? Visit the hostname in a browser. An error page from a platform (“There isn’t a site here”, “No such app”, “NoSuchBucket”, “404 Not Found” from a service you don’t recognise) is the warning sign. So is “server not found”: it can mean the target’s domain has expired.
3. Follow every target to its domain. For each CNAME, NS and MX target, and each SPF include:, take the registered domain (bookingtool.example from webcontrol-example.bookingtool.example) and ask two questions. Is the company still trading? Is the domain still registered? ICANN Lookup answers the second one for most domains, and auDA’s WHOIS for .au names. “Not found”, a parked page or “this domain is for sale” means anyone can take it.
4. Check A records against what you actually run. If you can’t match an IP address to a server or service you pay for, it’s suspect.
5. Delete what nobody can explain. If you’re nervous, write down what you removed so you can put it back. You almost never need to.

Stop it happening again

The real fix is a habit:

• Remove the DNS record first, then cancel the service. Not the other way round. That way there’s never a moment when your record points at nothing.
• When a provider announces it’s closing, treat it as a DNS job. Move off, then delete their records the same week, even if the service still seems to work. Don’t wait for it to break.
• Before you let a domain go, search for it. Look through every DNS zone you manage for records, SPF includes and DMARC addresses that mention it, and change any account logins that use it. Fix those first. If you can’t be sure you’ve found them all, keep renewing it: a few years of renewals is cheap insurance. (More on which domains to keep in Domain hygiene, and on cleaning up SPF in SPF, DKIM and DMARC.)
• Comment every record with what it’s for, who owns it and when it was added. Cloudflare lets you do this on every plan. A record with a comment like “Spring campaign, remove after 2026-10” is one nobody forgets. (I’ve written up the naming and comment conventions I use in Naming conventions for DNS records, Lists and API tokens.)
• Review DNS twice a year, at the same time you review who has access to your accounts.
• Don’t assume Cloudflare’s orange cloud protects you here. A proxied record still sends visitors to whatever target it points at. If that target has been claimed by someone else, Cloudflare will happily serve their content. (More on what proxying does and doesn’t do in orange cloud vs grey cloud.)

What you’ll probably find

On any domain that’s been around for a few years, expect at least one record nobody can explain. Usually it’s harmless: an old verification record, a test subdomain pointing at a server that’s still yours. Sometimes it points at a platform account that closed years ago, a company that no longer exists, or a domain you stopped paying for. Those are the ones you want to find before someone else does.

Want us to go through your DNS and flag anything risky? Get in touch.