Subdomain Takeover: Cloudflare and cPanel DNS Cleanup

Subdomain takeover through dangling DNS records can occur when a DNS entry still references an abandoned resource that another account can claim and use for your hostname. Strong passwords and request filtering do not repair that ownership gap. A retired staging site, campaign or SaaS integration can leave such a record behind. This guide covers the Cloudflare and cPanel workflow: identify which DNS service is authoritative, verify the target and its owner, remove or repair the mapping, and check the result before releasing the old resource.

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. In a dangling-DNS attack, they exploit records that still point at an abandoned third-party resource that they can claim.

A possible attack chain on a service that allows abandoned resource names to be reclaimed 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.
• If the service also accepts your custom hostname for the attacker’s resource without fresh ownership verification, your unchanged DNS lets the attacker serve content 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 sensitive cookies are shared with the compromised subdomain or APIs trust *.example.com.
• SEO damage and browser warnings if the subdomain is abused.

The problem in this attack is an abandoned DNS target that can be reused. A broken record is a reason to investigate; it does not by itself prove that another account can take over the hostname.

How Dangling DNS Records Create Takeover Risk

A dangling DNS record still references a resource that has been deprovisioned or is no longer under your administrative control. Using a third-party service is not itself a dangling-DNS condition. Takeover becomes possible if an attacker can claim the abandoned target and use it for your hostname without modifying your DNS.

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 a DNS service where your delegated zone has been removed or is no longer under your control.

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 left stale records in the authoritative zone or kept delegations to the old DNS service. An unused, non-authoritative copy of a zone does not by itself direct public traffic.
• 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, the following patterns can create dangling records. Review both proxied (orange-cloud) and DNS-only (grey-cloud) address 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 service where another account could claim the abandoned target or bind a hostname covered by the wildcard.
• Migrations between providers where Cloudflare continues to publish records for old IP addresses or hostnames even after you moved the site.

Validate the target’s ownership in the external service’s account dashboard; a record’s presence in Cloudflare DNS is not proof that the target is still associated with your account.

cPanel-specific patterns

cPanel keeps domain configuration and DNS records in related interfaces, but a hosting entry and a public DNS delegation are different things. Check both when a domain or subdomain changes. Risks appear when:

• You delete a subdomain or addon domain’s files from File Manager but forget that its DNS records are still published. Missing files alone do not establish takeover risk; check whether the referenced hosting resource remains under your control.
• You move a site from your cPanel account to another server but leave stale records in a zone that is still authoritative for the site.
• 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 a CNAME in cPanel’s Zone Editor and later delete the SaaS configuration but not the DNS record.

Distinct cPanel accounts can make separate clients or larger projects easier to inventory and assign to an owner. 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

Use the same sequence for each hostname: identify authority → inventory → verify ownership → keep, fix or remove → recheck → document. For planned retirement, keep control of the old resource until the DNS change has taken effect and cached references have been considered.

1. Inventory all subdomains and records

First, establish which service publishes the public zone and whether any child zones are delegated elsewhere. A record visible in a dashboard may belong to an inactive zone. Export the configured records from each authoritative service, then compare them with hosting and project inventories; public lookups alone do not enumerate every hostname.

On Cloudflare

1. Select the domain in Cloudflare and open DNS → Records.
2. Use Import and Export → Export to save a zone copy. Keep the record name, type, configured target, TTL and proxy status in your audit inventory.
3. Start with A, AAAA, CNAME and child-zone NS records. Include wildcard mappings, the full CNAME chain, and related MX, TXT and certificate-validation dependencies before deciding what to retire.
4. Sort by name and type, and record any separately delegated child zone. Its records must be inventoried at that child zone’s DNS provider.

On cPanel

1. Open Domains in cPanel and list domains, subdomains, addon domains and aliases used by the account.
2. Open Zone Editor → Manage for each relevant zone and copy its records into the inventory.
3. If a zone or record type is missing, ask the hosting administrator for the relevant WHM/DNS-cluster inventory. cPanel features and visibility depend on permissions; its list is not proof of a complete public zone.
4. Label each copy as authoritative, delegated, local or inactive after checking the public delegation. Do not assume an export control is available in every cPanel interface.

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.

In a Cloudflare full setup, Cloudflare is authoritative. In a supported partial CNAME setup, another provider remains authoritative while selected hostnames use Cloudflare’s proxy; this setup currently requires Business or Enterprise. The orange/grey cloud switch controls HTTP/HTTPS proxying, not delegation. Check the registrar’s nameserver assignment and follow any child-zone NS delegation before editing.

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:

• Project or product, technical owner and responsible account/team.
• Authoritative DNS provider, record name/type/target, TTL, proxy status and any CNAME or delegation chain.
• Actual resource identifier and account at cPanel, a VPS provider or the SaaS service.
• Dependent websites, APIs, email and certificate validation, plus the review or retirement date.

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. Read the configured CNAME target from the authoritative DNS dashboard or API and follow the chain to the final service. Cloudflare proxying or flattening can hide the configured CNAME from public answers.
2. Check the hostname’s expected HTTP/HTTPS response. “No such app”, “Project not found”, a default page or a TLS error is an investigation clue, not proof of takeover.
3. Confirm the exact resource and custom-domain binding in the correct provider account. Check other responsible teams or accounts before concluding that it is abandoned.
4. Classify a confirmed abandoned mapping as dangling. A takeover additionally requires the provider to let another account claim a usable resource or hostname binding; verification tokens, reservation rules and routing restrictions can prevent that. Use provider documentation and support to confirm the conditions.

For A / AAAA records

1. Read the configured A and AAAA targets from the authoritative provider. Public answers for a proxied Cloudflare name show Cloudflare edge addresses, so they are not an origin inventory.
2. Confirm the IP assignment, active server or hosting resource, and hostname/vhost mapping in your account records. An IP’s network owner is not proof that your account still controls that resource.
3. Check HTTP/HTTPS using the intended hostname. A default page or unrelated content may indicate a virtual-host, DNS or deployment error; it does not by itself prove loss of the IP.
4. Reconcile the result with all relevant hosting inventories, including any VPS at dchost.com. If ownership remains unknown, investigate with the responsible owner before deleting a production record.

For NS records (delegated subdomains)

1. Distinguish the domain’s registrar-level nameserver delegation from an NS delegation for a child zone, such as dev.example.com, inside its parent zone.
2. Query the parent’s authoritative nameserver for the child’s NS records, then query each delegated server for the child zone’s SOA/NS data. A response shows what a server publishes; confirm the child zone’s administrative account separately.
3. If the zone seems absent or access is lost, contact the responsible owner or DNS provider. A registrar/WHOIS lookup for a nameserver’s domain cannot prove that your organisation owns the hosted child zone.
4. For an active child zone, arrange a controlled repair or migration. For a confirmed retired zone, remove its delegation from the parent and review child DS records and any in-bailiwick glue with the DNS administrator. Keep unrelated parent-zone NS/SOA records intact.

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 – confirmed unused records. Investigate unknown records with their owners before deleting them; urgently remove or repoint records that lead to uncontrolled resources.

For high-risk cases (e.g., CNAMEs to deleted third-party apps), promptly remove the record or repoint it to a controlled target. A migration plan alone is not a reason to leave a dangling record in place.

5. Safely remove or update records in Cloudflare

For records you want to change on Cloudflare:

1. Save the current record values and identify dependent services before the change.
2. In DNS → Records, select Edit for the exact name and type. To repair it, enter the verified controlled target and save. To retire it, choose Delete and confirm.
3. Check other A/AAAA targets, CNAME aliases and wildcard fallback for the hostname. Deleting one record does not necessarily remove every route to it.
4. Verify the configured values, authoritative DNS replies and external service response as described below. Allow for previous TTLs and any provider configuration delay before releasing a resource you still control.

Cloudflare proxy status changes the request path: a proxied A/AAAA/CNAME resolves to Cloudflare edge addresses, while DNS-only traffic resolves toward the configured origin. Neither mode proves that you still own the origin or SaaS binding. A dangling mapping needs cleanup in both cases, but whether an attacker can serve the hostname depends on the provider’s claim rules, custom-domain verification and the actual Cloudflare/origin routing. Cloudflare also restricts some cross-account CNAME routes; an error or block is not evidence of a completed takeover.

6. Safely remove or update records in cPanel

Use these steps only when cPanel/WHM or its DNS cluster is authoritative for the affected zone. If Cloudflare publishes it, the public change belongs there; a local cPanel edit alone will not update Cloudflare.

1. Open Zone Editor → Manage and find the precise A, AAAA or CNAME record. Use Edit → Save Record to repair it, or Delete → Continue for a confirmed unused record.
2. The available types depend on version and enabled features. The documented cPanel Zone Editor does not offer the same type list as WHM. For NS delegation edits or records you cannot see, ask the hosting administrator; authorised administrators can use WHM DNS Zone Manager, which documents NS editing.
3. Change a child-zone delegation in the authoritative parent zone. Changing the registered domain’s nameserver assignment is a separate registrar operation; editing apex NS records locally does not perform that change.
4. After retiring an entry in Domains, recheck the public zone and any relevant DNS-cluster copies. Do not use Reset DNS Zone as a cleanup shortcut: it can erase other custom records.

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

Use explicit record types and keep the response status and answer/authority sections visible. The examples below use reserved example names: replace them with your hostname and the nameservers/resolvers you have identified.

• Find the delegation path: dig +trace example.com. NS. For a delegated child, also trace dig +trace dev.example.com. NS. Trace follows DNS referrals; it does not prove account ownership or validate DNSSEC signatures.
• Check each current authoritative server: replace ns1.authoritative.example. below with an actual nameserver from the delegation. Compare every changed record type, not just IPv4.

dig @ns1.authoritative.example. app.example.com. A +norecurse
dig @ns1.authoritative.example. app.example.com. AAAA +norecurse
dig @ns1.authoritative.example. app.example.com. CNAME +norecurse

For a child-zone delegation, query the parent and the child separately. Replace both server placeholders with their actual nameservers; repeat for the other servers in each set.

dig @ns1.parent.example. dev.example.com. NS +norecurse
dig @ns1.child.example. dev.example.com. SOA +norecurse
dig @ns1.child.example. dev.example.com. NS +norecurse

• The parent may return a referral in the AUTHORITY section. A former child server can still answer for a zone after its parent delegation is removed, so its reply alone does not show that public resolvers still use it.
• Repeat the A/AAAA/CNAME checks through the recursive resolvers used by your users, such as dig @resolver.example. app.example.com. A with a real resolver substituted. Compare answers after the previous TTLs expire. DNS and browser caches can differ; negative answers may also be cached.
• NXDOMAIN means the queried name, or the final name in a returned CNAME chain, does not exist. NOERROR with no relevant answer may be NODATA for that type; inspect the authority section to distinguish it from a referral. An empty +short result, timeout or SERVFAIL does not prove successful deletion.
• For a proxied or flattened Cloudflare record, reconcile the public answer with its configured target in Cloudflare. The edge IP may remain the same after an origin change, and a CNAME query may not expose a flattened record. Keep proxy settings intact while checking the configuration.
• Finally, visit the intended HTTP/HTTPS hostname and confirm the expected page, redirect or retirement behavior. Recheck wildcard fallback and dependent APIs/email where relevant. For resolution errors, see our DNS troubleshooting guide.

The BIND dig manual documents explicit query types, @server, +trace and +norecurse. Plain dig app.example.com defaults to an A lookup; it does not check every record type.

Hardening Cloudflare Against Subdomain Takeover

Beyond one-time cleanup, use these DNS management and account-security practices to reduce opportunities for dangling records and unauthorized changes.

Avoid risky wildcard records

Wildcard records like *.example.com can broaden exposure if their target becomes claimable by another user. Public sign-ups alone do not establish takeover risk; whether an attacker can claim the target or bind your hostname matters. To limit exposure:

• Use explicit subdomains (app.example.com, status.example.com) rather than wildcards.
• If you need a wildcard, keep its target and hostname routing under documented control (for example, a VPS or dedicated server), and include the full wildcard namespace in the audit.

Optional: centralise CNAME targets for easier management

For easier management of provider-specific targets, you can consider an intermediate hostname under your own domain. This is an organisational option, not a substitute for verifying control of the final target:

• 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 update the second hop. This can centralise provider-specific targets when several aliases share one origin hostname, but the final target still needs lifecycle checks and cleanup. Adding an intermediate hostname does not make a dangling final target safe.

Use an intermediate alias only if the external service supports that custom-domain arrangement. Follow its required DNS and verification records; the extra hop is a management choice, not a way around provider validation.

Protect your domain with DNSSEC and registrar security

DNSSEC authenticates DNS data; it does not check whether a target resource is still yours. A correctly signed dangling record remains dangling. For an existing full Cloudflare setup, follow the provider’s DNSSEC procedure and coordinate the DS record with the registrar; for a delegated child zone, the DS belongs in the parent zone.

• Enable DNSSEC using the active DNS provider’s instructions and verify the matching DS is published in the parent. During a DNS-provider change, coordinate old/new DS and signing keys; a stale DS can break validation.
• Use two-factor authentication for DNS/registrar accounts and tokens limited to the required zones and operations. Inventory-only automation should have read access.

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.

Restrict Cloudflare dashboard and DNS permissions

Cloudflare provides dashboard roles and audit logs. Assign DNS permissions to named team members and use the available logs as part of your change review.

• Give agencies and developers individual membership and the minimum role and domain scope needed.
• Restrict who can modify DNS and review access when projects or contracts end.
• Review changes to apex, wildcard, delegation and MX records; if your monitoring supports it, alert on unexpected changes.

Every authorised DNS change should leave an owner and a review date, including temporary records created by automation.

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:

• Confirm dependencies and remove or repoint the project’s DNS mappings at the authoritative service while you still control the target.
• Allow for previously cached DNS answers and relevant provider delays, then recheck the DNS and application path before releasing an app, hostname or IP that another account could claim. Lowering TTL now does not shorten answers already cached with an older TTL.
• Retire the resource and, where appropriate, remove its cPanel Domains entry. Review associated email, files and certificate workflows before removing a domain configuration.
• Confirm the public records remain correct and clean up stale local/cluster copies without restoring the abandoned target.

Keep a clear source of truth for authoritative DNS

A Cloudflare zone and a cPanel zone can legitimately coexist. What matters is knowing which system publishes each public zone and whether any split/local or delegated configuration is intentional. Keep one documented change owner and an explicit map of these roles.

• Full Cloudflare setup: public records belong in Cloudflare, even when a record is grey-cloud/DNS-only. Keep cPanel’s local configuration consistent with its actual mail, certificate and hosting dependencies.
• cPanel/WHM authority: public changes belong on its authoritative nameserver set or DNS cluster. Cloudflare proxying with another authoritative provider requires a supported partial setup; simply selecting DNS-only in Cloudflare does not preserve or transfer authority.
• Delegated child zones: maintain the NS referral in the parent provider and the child records at the delegated provider. Record both owners.
• Local-zone cleanup: do not disable or delete a cPanel zone solely because Cloudflare is public. Have the administrator check email routing, DNS-cluster roles and certificate validation first. cPanel documents mail-routing implications of zone deletion. Its documented Let’s Encrypt AutoSSL plugin cannot issue wildcard certificates when DNS is hosted by a third party; keeping a local zone copy alone does not remove that limitation.

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

Use separate cPanel accounts to clarify client boundaries

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

• Make each client’s forgotten test subdomains easier to identify and assign for cleanup; account separation does not itself prevent subdomain takeover.
• Keep DNS zones clearly separated for audits and documentation.
• Assign responsibility: each account has a clear owner and contact.

For agencies, separate client accounts can help organise ownership. Verify that the chosen hosting plan and control-panel licence support the account structure you need.

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

Do not rely on a single big audit. Build small, repeatable checks into everyday workflows, whether you manage a security team, a small business or a solo project.

When to run a DNS review

Add a quick DNS pass into these moments:

• Periodic review: a quarterly audit can be a starting schedule; shorten the interval for frequent changes or sensitive hostnames.
• Before and after migrations: reconcile old/new addresses, CNAME chains and delegation with the hosting inventory.
• Before cancelling a SaaS integration: remove or repoint traffic-bearing records before releasing the target. Review TXT and other verification records against that provider’s retention rules, rather than deleting them automatically.
• After campaigns and team handovers: close the ownership record only after DNS and resource cleanup have been checked.

Some TXT records actively protect ownership: GitHub Pages asks you to keep its verification TXT record so the domain remains verified. Microsoft likewise documents App Service domain-verification TXT records that stop another subscription binding the domain. These are provider-specific protections, not general permission to keep every obsolete verification token.

Simple automation and tooling

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

• Use a read-scoped Cloudflare API token to list configured records, following pagination and including relevant delegated zones through their own providers.
• For records expected to serve web traffic, flag unexpected HTTP responses or provider error pages for investigation. A 404/410 is a triage signal, not evidence that a target is claimable.
• Compare DNS targets with the resource/account inventory, and track owner, purpose and review date in a shared register or configuration repository.
• Monitor critical hostnames for expected content and DNS changes. An HTTP check cannot verify a non-web record or replace the provider-account ownership check.

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 requester, owner, purpose and review date.
• For every retiring service, assign DNS cleanup before resource release and record the verification result.
• For agency handovers, include the DNS provider, account owner, delegated zones and outstanding cleanup in the close-out checklist.

Keep the result of each review: what changed, who approved it, which DNS servers and application paths were checked, and which ownership questions remain open. This makes the next review and any incident investigation easier.

Coordinate DNS Cleanup with Your Hosting Provider

For a site hosted at dchost.com or another provider, keep hosting support, the authoritative DNS owner and any external SaaS owner aligned. A hosting account does not automatically give its administrator control of Cloudflare, the registrar or a third-party application.

When you request help with an inventory or migration, provide:

• The affected hostnames, record types, configured targets and authoritative DNS service.
• The active hosting/resource identifiers and the team that owns each external integration.
• The intended outcome: keep the service, repair the target or retire it.
• The dependencies, change window and DNS/application checks needed before old resources are released.

Confirm which checks and changes your selected support arrangement covers, then assign the remaining actions to the DNS, registrar or SaaS owner. Close the task only when the public routing and the resource inventory agree. Clear ownership, cleanup before release and a recorded recheck are the practical controls that keep retired Cloudflare and cPanel projects from leaving active DNS behind.