Preventing Subdomain Takeover and Dangling DNS on Cloudflare and cPanel

If your domains sit on Cloudflare and your sites are hosted on cPanel, you already have a solid technical foundation. But there is a quiet class of vulnerabilities that bypasses firewalls, WAF rules, and strong passwords completely: subdomain takeover through dangling DNS records. It does not require breaking into your server; it only requires you to forget to clean up a DNS entry. That is why we see this issue regularly during security reviews for new customers at dchost.com. A test subdomain for a marketing campaign, a temporary staging environment, a retired SaaS integration, or a migration between hosting providers – all of these can leave behind DNS records that point to resources you no longer control. In this guide, we will focus on Cloudflare and cPanel specifically and walk through how subdomain takeover attacks happen, what dangling DNS records really are, how to systematically find and remove them, and how to set up simple processes so you do not have to think about this risk every week.

What Is Subdomain Takeover?

Subdomain takeover is when an attacker gains control over content served from one of your subdomains (for example, blog.example.com or dev.example.com) without touching your main server or domain registrar. They do this by exploiting DNS records that still point at a third-party service you once used but have since removed or let expire.

A typical attack chain looks like this:

• Your DNS has a CNAME record for test.example.com pointing to myapp.oldservice.com.
• You delete the app or account on that external service, but you forget to remove the DNS record.
• The external service now sees that myapp.oldservice.com is free to register again.
• An attacker creates an account on that service and claims myapp.oldservice.com.
• Because your DNS still points to that hostname, the attacker controls what appears on test.example.com under your domain.

The impact ranges from mild to severe:

• Phishing and credential theft on a trusted subdomain.
• Malware distribution under your brand.
• Session hijacking or content injection if cookies or APIs trust *.example.com.
• SEO damage and browser warnings if the subdomain is abused.

The root problem is dangling DNS records – DNS entries pointing to dead or uncontrolled resources. To prevent subdomain takeover, you must prevent dangling DNS on Cloudflare and cPanel.

How Dangling DNS Records Create Takeover Risk

A dangling DNS record is any record that still exists in your zone file but no longer points to an asset you control. The attacker does not modify your DNS – they simply recreate or claim the target you abandoned.

The most common risky records are:

• CNAME pointing to a third-party hostname that no longer belongs to you (deleted app, expired account, removed site).
• A / AAAA records pointing to IP addresses where you no longer manage the server or virtual host.
• NS records for delegated subdomains (like dev.example.com) pointing to name servers you do not control anymore.

On Cloudflare and cPanel, this usually happens after one of these events:

• You removed or changed a hosting plan but left old DNS records in place.
• You experimented with a SaaS (e.g., a landing page builder or helpdesk) and forgot to delete its DNS integration.
• You migrated a site from cPanel DNS to Cloudflare DNS (or back) but never cleaned up the previous zone.
• You used temporary subdomains for features or campaigns and never removed them.

If you need a refresher on record types and when they are used, our detailed article explains A, AAAA, CNAME, MX, TXT and SRV records step-by-step.

Typical Risk Patterns on Cloudflare and cPanel

Cloudflare-specific patterns

When Cloudflare is your DNS provider (orange or grey cloud icons in the DNS tab), the following patterns often create dangling records:

• Old CNAMEs for retired services – e.g., status.example.com or app.example.com still pointing to a third-party hostname that no longer exists in your account.
• Staging and preview subdomains created for agencies, QA, or third-party developers that were later decommissioned but left in DNS.
• Wildcard records like *.example.com pointing to a provider where unused names can be claimed by anyone.
• Migrations between providers where Cloudflare continues to publish records for old IP addresses or hostnames even after you moved the site.

Cloudflare itself does not automatically check whether a target hostname is still associated with your account on an external service, so you must do this validation.

cPanel-specific patterns

On cPanel, DNS zones are often created and manipulated automatically whenever you add/remove domains and subdomains. Risks appear when:

• You delete a subdomain or addon domain’s files from File Manager but forget that its DNS records are still published.
• You move a site from your cPanel account to another server but leave the original DNS zone in place (especially if cPanel is still acting as authoritative DNS).
• You run multiple sites or clients in one cPanel account and lose track of which subdomain belongs to which project.
• You integrate a SaaS via cPanel’s Zone Editor (CNAME or TXT records) and later delete the SaaS configuration but not the DNS.

This is a strong reason why we often recommend distinct cPanel accounts for separate clients or larger projects. Our article about choosing between addon domains and separate cPanel accounts covers the isolation and management benefits in more detail.

Step-by-Step: Finding and Fixing Dangling Records

Let us walk through a practical playbook you can use on any Cloudflare + cPanel setup. The idea is simple: inventory → verify → clean up → prevent.

1. Inventory all subdomains and records

First, you need a complete picture of what exists today.

On Cloudflare

1. Log in to Cloudflare and select your domain.
2. Open the DNS tab.
3. Export the zone file (advanced actions) or copy the list of records, especially A, AAAA, CNAME and NS records.
4. Sort or filter by type and name so you can easily see all subdomains.

On cPanel

1. Log in to your cPanel account.
2. Open Domains and list all domains and subdomains (including addon and parked domains).
3. Open Zone Editor and list the DNS records for each domain that cPanel manages.
4. Export or copy the records to a spreadsheet for easier analysis.

If you are not sure whether Cloudflare or your hosting is currently authoritative for DNS, our article on Cloudflare DNS vs hosting DNS and nameserver strategy explains how to check and choose the right setup.

2. Classify subdomains by purpose and owner

Next, go through the list and label each subdomain:

• Production – live sites, APIs, email-related records.
• Staging / dev / test – used by developers, QA, or agencies.
• Integrations – subdomains pointing to external SaaS or third-party tools.
• Legacy / unknown – nobody on the team remembers why it exists.

For each subdomain, note:

• Which project or product it belongs to.
• Which team or person “owns” it.
• Which infrastructure it targets (cPanel, VPS, SaaS, etc.).

Anything in the “legacy / unknown” bucket is an immediate review candidate.

3. Verify whether the target is truly under your control

This is the crucial step that detects dangling records.

For CNAME records

1. Look at the target hostname (right-hand side of the CNAME).
2. Visit the subdomain in a browser. Look for messages like “No such app”, “Project not found”, or default placeholders from the provider.
3. Log into the third-party service’s dashboard and confirm whether this hostname or app is still in your account.
4. If you cannot find it in your account but the provider still allows it to be created, treat it as dangling and vulnerable.

For A / AAAA records

1. Check whether the IP address still belongs to a server or hosting service you manage.
2. Try to connect via HTTP/HTTPS. If you see a default “It works!” page from someone else, or an unrelated site, the IP is no longer yours.
3. Confirm against your server inventory at dchost.com (shared hosting, VPS, or dedicated) and any other environments you operate.
4. If you cannot map the IP to a server under your control, treat the record as suspicious.

For NS records (delegated subdomains)

1. Check whois or DNS for the name servers listed.
2. Log into the DNS provider that manages that delegated zone.
3. If the zone does not exist, or you have no access to that account anymore, remove or update the delegation.

4. Decide: keep, fix, or remove

Once you know which targets are valid, decide per record:

• Keep – required for production or active staging/integration.
• Fix – still needed, but should point to new IPs/hostnames after a migration.
• Remove – unused, unknown, or clearly pointing to dead/uncontrolled resources.

For high-risk cases (e.g., CNAMEs to deleted third-party apps), prefer removal unless you have a clear migration plan.

5. Safely remove or update records in Cloudflare

For records you want to change on Cloudflare:

1. In the DNS tab, locate the record.
2. If you are fixing a record (e.g., new IP after moving to a new server at dchost.com), edit and update the target.
3. If you are removing it, delete the record and confirm.
4. Wait for DNS propagation; you can monitor with dig or external DNS checkers.

Keep in mind that Cloudflare’s caching and proxying (orange cloud) affect HTTP traffic, but do not change how DNS authority works. If a record exists and points to a take-over-able target, the risk is there whether or not the record is proxied.

6. Safely remove or update records in cPanel

For records managed by cPanel DNS:

1. Open Zone Editor for the relevant domain.
2. Find the A, AAAA, CNAME or NS record you want to change.
3. Edit the target (for migrations) or delete the record completely if no longer needed.
4. If you delete an entire subdomain or addon domain from the Domains section, double-check that its DNS entries were also removed from the zone.

While you are in cPanel, it is a good time to review broader security settings. Our cPanel security hardening checklist covers brute-force protection, malware scanning and other essentials beyond DNS.

7. Test from the outside

After cleanup, verify:

• Use dig subdomain.example.com or an online DNS lookup tool to confirm records are gone or updated.
• Visit subdomains in a browser to ensure no unexpected content appears.
• Run basic DNS diagnostics; if you hit common errors, our guide on fixing DNS_PROBE_FINISHED_NXDOMAIN and common DNS errors can help.

Hardening Cloudflare Against Subdomain Takeover

Beyond one-time cleanup, you can configure Cloudflare to make subdomain takeover much less likely.

Avoid risky wildcard records

Wildcard records like *.example.com are convenient but dangerous if they point to third-party providers that allow public sign-ups. Instead:

• Use explicit subdomains (app.example.com, status.example.com) rather than wildcards.
• If you must use a wildcard, point it to infrastructure you fully control (e.g., your own VPS or dedicated server at dchost.com).

Use hostnames you control as CNAME targets

Instead of pointing Cloudflare CNAMEs directly at third-party hostnames (which might become reclaimable), consider:

• Point app.example.com to app-origin.example.com (still your domain, under your DNS).
• Then point app-origin.example.com to the provider’s hostname.

When you change providers, you only update the second hop. While this does not eliminate takeover risk by itself, it centralises where provider-specific hostnames live and makes audits easier.

Protect your domain with DNSSEC and registrar security

Subdomain takeover does not usually require DNS hijacking, but strengthening DNS integrity reduces overall risk. On Cloudflare:

• Enable DNSSEC and add the DS record at your registrar.
• Use strong 2FA and API tokens with minimal scopes for DNS automation.

If you want a refresher, we have a dedicated article on what DNSSEC is and how it makes your website more secure, and another guide on domain security best practices such as registrar lock, DNSSEC, Whois privacy and 2FA.

Use Cloudflare Access controls wisely

Cloudflare provides access control and logging for panel users:

• Use separate accounts or role-based access for agencies and developers.
• Restrict who can modify DNS records, and review access periodically.
• Log and alert on changes to critical records (e.g., root domain, wildcard, MX).

The fewer people who can create and forget temporary subdomains, the smaller your attack surface.

Hardening cPanel DNS and Subdomains

On cPanel-based hosting, a few practical habits go a long way.

Always pair subdomain lifecycle with DNS lifecycle

When you create a subdomain for a test or a campaign, write down:

• Its expected end date (e.g., “after Black Friday campaign ends”).
• Where it is hosted (cPanel, VPS, or external service).
• Who is responsible for removing it.

When that project ends, the same person should:

• Remove the content or external app.
• Delete the subdomain entry in cPanel’s Domains section.
• Confirm the DNS records were removed from Zone Editor (or manually delete them).

Keep DNS authority simple: Cloudflare OR cPanel, not both

One common source of confusion is running two conflicting DNS zones – one on Cloudflare and one in cPanel – and not being sure which is actually serving the internet. We strongly recommend:

• Choose one system as authoritative DNS for each domain.
• If Cloudflare is authoritative, treat cPanel’s DNS zone as local-only and keep it tidy, or disable it where appropriate.
• If your cPanel/WHM is authoritative, keep Cloudflare (if used) in DNS-only mode or not connected for that domain.

Having a single source of truth makes audits and incident response much easier.

Use separate cPanel accounts to avoid cross-contamination

If you host multiple client sites or projects on the same server, using separate cPanel accounts helps:

• Prevent one forgotten test subdomain from affecting another client’s brand.
• Keep DNS zones clearly separated for audits and documentation.
• Assign responsibility: each account has a clear owner and contact.

On our reseller hosting and VPS platforms at dchost.com, this separation is a common pattern we recommend, especially for agencies.

Combine DNS hygiene with broader panel security

DNS is only one layer. Ensure your cPanel environment is also hardened against brute force, malware, and misconfiguration. Again, our cPanel security hardening checklist is a practical companion to this article.

Make DNS Hygiene a Routine, Not a One-Off Project

Security teams that stay ahead of subdomain takeover usually do not rely on a single big audit. Instead, they build small, repeatable checks into everyday workflows. You can adopt the same mindset even if you are a small business or a solo developer.

When to run a DNS review

Add a quick DNS pass into these moments:

• Quarterly security or infrastructure reviews – scan your Cloudflare and cPanel records and re-verify unknown subdomains.
• After every migration – when moving a site between hosting plans, VPS, or dedicated servers at dchost.com, always clean up old IPs and hostnames.
• After deleting a SaaS integration – remove the corresponding CNAME/TXT records.
• After major marketing campaigns – retire landing page subdomains fully, including DNS.

Simple automation and tooling

You do not need an enterprise budget to add basic automation:

• Use scripts or small tools that list all subdomains from Cloudflare’s API and flag those returning 404/410 or provider-specific “no such app” pages.
• Maintain a shared spreadsheet or configuration repository listing each subdomain, its purpose, and its owner.
• Use uptime checks for critical subdomains so you are alerted when they start returning unexpected responses.

If you manage multiple sites, the techniques in our website uptime monitoring and alerting guide for small businesses can be repurposed to keep an eye on key subdomains as well.

Build a lightweight change process

Even a small checklist can prevent mistakes:

• For every new subdomain, record who requested it, why, and when it should be reviewed.
• For every removed service, ensure someone is assigned to clean up its DNS records.
• For agencies, include DNS cleanup in your project close-out checklist.

These habits are simple but powerful. Over time, they dramatically reduce the chance that a forgotten test environment becomes a live security incident.

How dchost.com Helps You Stay Safe

At dchost.com, we see the full spectrum: small brochure sites on shared hosting, high-traffic WooCommerce stores on VPS, and mission-critical SaaS platforms running on dedicated or colocated servers. Across all of them, DNS hygiene and subdomain management are recurring themes in security conversations.

When you host with us – whether on shared hosting, VPS, dedicated servers, or colocation – our team can help you:

• Review DNS zones on both Cloudflare and cPanel to identify obvious dangling records.
• Plan safe migrations so old IPs and hostnames are not left behind after you move to a new server.
• Choose a sane nameserver strategy and enable protections like DNSSEC and registrar lock.
• Design staging and testing setups that do not leave behind risky, forgotten subdomains.

Subdomain takeover is not a problem you solve once. It is a risk you keep small with good habits, clear ownership, and occasional expert support. If you would like us to review your current Cloudflare and cPanel setup, or if you are planning a migration to a new hosting, VPS, dedicated server or colocation environment, our team at dchost.com is ready to help you design a clean, secure DNS and hosting architecture you can rely on.