{"id":3089,"date":"2025-12-07T14:46:34","date_gmt":"2025-12-07T11:46:34","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/preventing-subdomain-takeover-and-dangling-dns-on-cloudflare-and-cpanel\/"},"modified":"2025-12-07T14:46:34","modified_gmt":"2025-12-07T11:46:34","slug":"preventing-subdomain-takeover-and-dangling-dns-on-cloudflare-and-cpanel","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/preventing-subdomain-takeover-and-dangling-dns-on-cloudflare-and-cpanel\/","title":{"rendered":"Preventing Subdomain Takeover and Dangling DNS on Cloudflare and cPanel"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>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: <strong>subdomain takeover through dangling DNS records<\/strong>. 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 \u2013 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.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_Is_Subdomain_Takeover\"><span class=\"toc_number toc_depth_1\">1<\/span> What Is Subdomain Takeover?<\/a><\/li><li><a href=\"#How_Dangling_DNS_Records_Create_Takeover_Risk\"><span class=\"toc_number toc_depth_1\">2<\/span> How Dangling DNS Records Create Takeover Risk<\/a><\/li><li><a href=\"#Typical_Risk_Patterns_on_Cloudflare_and_cPanel\"><span class=\"toc_number toc_depth_1\">3<\/span> Typical Risk Patterns on Cloudflare and cPanel<\/a><ul><li><a href=\"#Cloudflare-specific_patterns\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Cloudflare-specific patterns<\/a><\/li><li><a href=\"#cPanel-specific_patterns\"><span class=\"toc_number toc_depth_2\">3.2<\/span> cPanel-specific patterns<\/a><\/li><\/ul><\/li><li><a href=\"#Step-by-Step_Finding_and_Fixing_Dangling_Records\"><span class=\"toc_number toc_depth_1\">4<\/span> Step-by-Step: Finding and Fixing Dangling Records<\/a><ul><li><a href=\"#1_Inventory_all_subdomains_and_records\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Inventory all subdomains and records<\/a><ul><li><a href=\"#On_Cloudflare\"><span class=\"toc_number toc_depth_3\">4.1.1<\/span> On Cloudflare<\/a><\/li><li><a href=\"#On_cPanel\"><span class=\"toc_number toc_depth_3\">4.1.2<\/span> On cPanel<\/a><\/li><\/ul><\/li><li><a href=\"#2_Classify_subdomains_by_purpose_and_owner\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Classify subdomains by purpose and owner<\/a><\/li><li><a href=\"#3_Verify_whether_the_target_is_truly_under_your_control\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Verify whether the target is truly under your control<\/a><ul><li><a href=\"#For_CNAME_records\"><span class=\"toc_number toc_depth_3\">4.3.1<\/span> For CNAME records<\/a><\/li><li><a href=\"#For_A_AAAA_records\"><span class=\"toc_number toc_depth_3\">4.3.2<\/span> For A \/ AAAA records<\/a><\/li><li><a href=\"#For_NS_records_delegated_subdomains\"><span class=\"toc_number toc_depth_3\">4.3.3<\/span> For NS records (delegated subdomains)<\/a><\/li><\/ul><\/li><li><a href=\"#4_Decide_keep_fix_or_remove\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4. Decide: keep, fix, or remove<\/a><\/li><li><a href=\"#5_Safely_remove_or_update_records_in_Cloudflare\"><span class=\"toc_number toc_depth_2\">4.5<\/span> 5. Safely remove or update records in Cloudflare<\/a><\/li><li><a href=\"#6_Safely_remove_or_update_records_in_cPanel\"><span class=\"toc_number toc_depth_2\">4.6<\/span> 6. Safely remove or update records in cPanel<\/a><\/li><li><a href=\"#7_Test_from_the_outside\"><span class=\"toc_number toc_depth_2\">4.7<\/span> 7. Test from the outside<\/a><\/li><\/ul><\/li><li><a href=\"#Hardening_Cloudflare_Against_Subdomain_Takeover\"><span class=\"toc_number toc_depth_1\">5<\/span> Hardening Cloudflare Against Subdomain Takeover<\/a><ul><li><a href=\"#Avoid_risky_wildcard_records\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Avoid risky wildcard records<\/a><\/li><li><a href=\"#Use_hostnames_you_control_as_CNAME_targets\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Use hostnames you control as CNAME targets<\/a><\/li><li><a href=\"#Protect_your_domain_with_DNSSEC_and_registrar_security\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Protect your domain with DNSSEC and registrar security<\/a><\/li><li><a href=\"#Use_Cloudflare_Access_controls_wisely\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Use Cloudflare Access controls wisely<\/a><\/li><\/ul><\/li><li><a href=\"#Hardening_cPanel_DNS_and_Subdomains\"><span class=\"toc_number toc_depth_1\">6<\/span> Hardening cPanel DNS and Subdomains<\/a><ul><li><a href=\"#Always_pair_subdomain_lifecycle_with_DNS_lifecycle\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Always pair subdomain lifecycle with DNS lifecycle<\/a><\/li><li><a href=\"#Keep_DNS_authority_simple_Cloudflare_OR_cPanel_not_both\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Keep DNS authority simple: Cloudflare OR cPanel, not both<\/a><\/li><li><a href=\"#Use_separate_cPanel_accounts_to_avoid_cross-contamination\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Use separate cPanel accounts to avoid cross-contamination<\/a><\/li><li><a href=\"#Combine_DNS_hygiene_with_broader_panel_security\"><span class=\"toc_number toc_depth_2\">6.4<\/span> Combine DNS hygiene with broader panel security<\/a><\/li><\/ul><\/li><li><a href=\"#Make_DNS_Hygiene_a_Routine_Not_a_One-Off_Project\"><span class=\"toc_number toc_depth_1\">7<\/span> Make DNS Hygiene a Routine, Not a One-Off Project<\/a><ul><li><a href=\"#When_to_run_a_DNS_review\"><span class=\"toc_number toc_depth_2\">7.1<\/span> When to run a DNS review<\/a><\/li><li><a href=\"#Simple_automation_and_tooling\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Simple automation and tooling<\/a><\/li><li><a href=\"#Build_a_lightweight_change_process\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Build a lightweight change process<\/a><\/li><\/ul><\/li><li><a href=\"#How_dchostcom_Helps_You_Stay_Safe\"><span class=\"toc_number toc_depth_1\">8<\/span> How dchost.com Helps You Stay Safe<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_Is_Subdomain_Takeover\">What Is Subdomain Takeover?<\/span><\/h2>\n<p><strong>Subdomain takeover<\/strong> is when an attacker gains control over content served from one of your subdomains (for example, <code>blog.example.com<\/code> or <code>dev.example.com<\/code>) 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.<\/p>\n<p>A typical attack chain looks like this:<\/p>\n<ul>\n<li>Your DNS has a <code>CNAME<\/code> record for <code>test.example.com<\/code> pointing to <code>myapp.oldservice.com<\/code>.<\/li>\n<li>You delete the app or account on that external service, but you forget to remove the DNS record.<\/li>\n<li>The external service now sees that <code>myapp.oldservice.com<\/code> is free to register again.<\/li>\n<li>An attacker creates an account on that service and claims <code>myapp.oldservice.com<\/code>.<\/li>\n<li>Because your DNS still points to that hostname, the attacker controls what appears on <code>test.example.com<\/code> under <strong>your<\/strong> domain.<\/li>\n<\/ul>\n<p>The impact ranges from mild to severe:<\/p>\n<ul>\n<li>Phishing and credential theft on a trusted subdomain.<\/li>\n<li>Malware distribution under your brand.<\/li>\n<li>Session hijacking or content injection if cookies or APIs trust <code>*.example.com<\/code>.<\/li>\n<li>SEO damage and browser warnings if the subdomain is abused.<\/li>\n<\/ul>\n<p>The root problem is <strong>dangling DNS records<\/strong> \u2013 DNS entries pointing to dead or uncontrolled resources. To prevent subdomain takeover, you must prevent dangling DNS on Cloudflare and cPanel.<\/p>\n<h2><span id=\"How_Dangling_DNS_Records_Create_Takeover_Risk\">How Dangling DNS Records Create Takeover Risk<\/span><\/h2>\n<p>A <strong>dangling DNS record<\/strong> 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 \u2013 they simply recreate or claim the target you abandoned.<\/p>\n<p>The most common risky records are:<\/p>\n<ul>\n<li><strong>CNAME<\/strong> pointing to a third-party hostname that no longer belongs to you (deleted app, expired account, removed site).<\/li>\n<li><strong>A \/ AAAA<\/strong> records pointing to IP addresses where you no longer manage the server or virtual host.<\/li>\n<li><strong>NS records for delegated subdomains<\/strong> (like <code>dev.example.com<\/code>) pointing to name servers you do not control anymore.<\/li>\n<\/ul>\n<p>On Cloudflare and cPanel, this usually happens after one of these events:<\/p>\n<ul>\n<li>You removed or changed a hosting plan but left old DNS records in place.<\/li>\n<li>You experimented with a SaaS (e.g., a landing page builder or helpdesk) and forgot to delete its DNS integration.<\/li>\n<li>You migrated a site from cPanel DNS to Cloudflare DNS (or back) but never cleaned up the previous zone.<\/li>\n<li>You used temporary subdomains for features or campaigns and never removed them.<\/li>\n<\/ul>\n<p>If you need a refresher on record types and when they are used, our detailed article <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-nedir-a-aaaa-cname-mx-txt-ve-srv-rehberi\/\">explains A, AAAA, CNAME, MX, TXT and SRV records step-by-step<\/a>.<\/p>\n<h2><span id=\"Typical_Risk_Patterns_on_Cloudflare_and_cPanel\">Typical Risk Patterns on Cloudflare and cPanel<\/span><\/h2>\n<h3><span id=\"Cloudflare-specific_patterns\">Cloudflare-specific patterns<\/span><\/h3>\n<p>When Cloudflare is your DNS provider (orange or grey cloud icons in the DNS tab), the following patterns often create dangling records:<\/p>\n<ul>\n<li><strong>Old CNAMEs for retired services<\/strong> \u2013 e.g., <code>status.example.com<\/code> or <code>app.example.com<\/code> still pointing to a third-party hostname that no longer exists in your account.<\/li>\n<li><strong>Staging and preview subdomains<\/strong> created for agencies, QA, or third-party developers that were later decommissioned but left in DNS.<\/li>\n<li><strong>Wildcard records<\/strong> like <code>*.example.com<\/code> pointing to a provider where unused names can be claimed by anyone.<\/li>\n<li><strong>Migrations between providers<\/strong> where Cloudflare continues to publish records for old IP addresses or hostnames even after you moved the site.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"cPanel-specific_patterns\">cPanel-specific patterns<\/span><\/h3>\n<p>On cPanel, DNS zones are often created and manipulated automatically whenever you add\/remove domains and subdomains. Risks appear when:<\/p>\n<ul>\n<li>You <strong>delete a subdomain or addon domain\u2019s files<\/strong> from File Manager but forget that its DNS records are still published.<\/li>\n<li>You move a site from your <strong>cPanel account to another server<\/strong> but leave the original DNS zone in place (especially if cPanel is still acting as authoritative DNS).<\/li>\n<li>You run <strong>multiple sites or clients in one cPanel account<\/strong> and lose track of which subdomain belongs to which project.<\/li>\n<li>You integrate a SaaS via cPanel\u2019s Zone Editor (CNAME or TXT records) and later delete the SaaS configuration but not the DNS.<\/li>\n<\/ul>\n<p>This is a strong reason why we often recommend distinct cPanel accounts for separate clients or larger projects. Our article about <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-addon-domain-mi-ayri-hesap-mi-dogru-secimi-teknik-sekilde-netlestirelim\/\">choosing between addon domains and separate cPanel accounts<\/a> covers the isolation and management benefits in more detail.<\/p>\n<h2><span id=\"Step-by-Step_Finding_and_Fixing_Dangling_Records\">Step-by-Step: Finding and Fixing Dangling Records<\/span><\/h2>\n<p>Let us walk through a practical playbook you can use on any Cloudflare + cPanel setup. The idea is simple: <strong>inventory \u2192 verify \u2192 clean up \u2192 prevent<\/strong>.<\/p>\n<h3><span id=\"1_Inventory_all_subdomains_and_records\">1. Inventory all subdomains and records<\/span><\/h3>\n<p>First, you need a complete picture of what exists today.<\/p>\n<h4><span id=\"On_Cloudflare\">On Cloudflare<\/span><\/h4>\n<ol>\n<li>Log in to Cloudflare and select your domain.<\/li>\n<li>Open the <strong>DNS<\/strong> tab.<\/li>\n<li>Export the zone file (advanced actions) or copy the list of records, especially <strong>A, AAAA, CNAME and NS<\/strong> records.<\/li>\n<li>Sort or filter by <strong>type<\/strong> and <strong>name<\/strong> so you can easily see all subdomains.<\/li>\n<\/ol>\n<h4><span id=\"On_cPanel\">On cPanel<\/span><\/h4>\n<ol>\n<li>Log in to your cPanel account.<\/li>\n<li>Open <strong>Domains<\/strong> and list all domains and subdomains (including addon and parked domains).<\/li>\n<li>Open <strong>Zone Editor<\/strong> and list the DNS records for each domain that cPanel manages.<\/li>\n<li>Export or copy the records to a spreadsheet for easier analysis.<\/li>\n<\/ol>\n<p>If you are not sure whether Cloudflare or your hosting is currently authoritative for DNS, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-dns-mi-hosting-dnsi-mi-en-dogru-nameserver-stratejisi\/\">Cloudflare DNS vs hosting DNS and nameserver strategy<\/a> explains how to check and choose the right setup.<\/p>\n<h3><span id=\"2_Classify_subdomains_by_purpose_and_owner\">2. Classify subdomains by purpose and owner<\/span><\/h3>\n<p>Next, go through the list and label each subdomain:<\/p>\n<ul>\n<li><strong>Production<\/strong> \u2013 live sites, APIs, email-related records.<\/li>\n<li><strong>Staging \/ dev \/ test<\/strong> \u2013 used by developers, QA, or agencies.<\/li>\n<li><strong>Integrations<\/strong> \u2013 subdomains pointing to external SaaS or third-party tools.<\/li>\n<li><strong>Legacy \/ unknown<\/strong> \u2013 nobody on the team remembers why it exists.<\/li>\n<\/ul>\n<p>For each subdomain, note:<\/p>\n<ul>\n<li>Which project or product it belongs to.<\/li>\n<li>Which team or person \u201cowns\u201d it.<\/li>\n<li>Which infrastructure it targets (cPanel, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, SaaS, etc.).<\/li>\n<\/ul>\n<p>Anything in the \u201clegacy \/ unknown\u201d bucket is an immediate review candidate.<\/p>\n<h3><span id=\"3_Verify_whether_the_target_is_truly_under_your_control\">3. Verify whether the target is truly under your control<\/span><\/h3>\n<p>This is the crucial step that detects dangling records.<\/p>\n<h4><span id=\"For_CNAME_records\">For CNAME records<\/span><\/h4>\n<ol>\n<li>Look at the <strong>target hostname<\/strong> (right-hand side of the CNAME).<\/li>\n<li>Visit the subdomain in a browser. Look for messages like \u201cNo such app\u201d, \u201cProject not found\u201d, or default placeholders from the provider.<\/li>\n<li>Log into the third-party service\u2019s dashboard and confirm whether this hostname or app is still in your account.<\/li>\n<li>If you <strong>cannot find it<\/strong> in your account but the provider still allows it to be created, treat it as <strong>dangling and vulnerable<\/strong>.<\/li>\n<\/ol>\n<h4><span id=\"For_A_AAAA_records\">For A \/ AAAA records<\/span><\/h4>\n<ol>\n<li>Check whether the IP address still belongs to a server or hosting service you manage.<\/li>\n<li>Try to connect via HTTP\/HTTPS. If you see a default \u201cIt works!\u201d page from someone else, or an unrelated site, the IP is no longer yours.<\/li>\n<li>Confirm against your server inventory at dchost.com (shared hosting, VPS, or dedicated) and any other environments you operate.<\/li>\n<li>If you cannot map the IP to a server under your control, treat the record as suspicious.<\/li>\n<\/ol>\n<h4><span id=\"For_NS_records_delegated_subdomains\">For NS records (delegated subdomains)<\/span><\/h4>\n<ol>\n<li>Check <code>whois<\/code> or DNS for the name servers listed.<\/li>\n<li>Log into the DNS provider that manages that delegated zone.<\/li>\n<li>If the zone does not exist, or you have no access to that account anymore, remove or update the delegation.<\/li>\n<\/ol>\n<h3><span id=\"4_Decide_keep_fix_or_remove\">4. Decide: keep, fix, or remove<\/span><\/h3>\n<p>Once you know which targets are valid, decide per record:<\/p>\n<ul>\n<li><strong>Keep<\/strong> \u2013 required for production or active staging\/integration.<\/li>\n<li><strong>Fix<\/strong> \u2013 still needed, but should point to new IPs\/hostnames after a migration.<\/li>\n<li><strong>Remove<\/strong> \u2013 unused, unknown, or clearly pointing to dead\/uncontrolled resources.<\/li>\n<\/ul>\n<p>For high-risk cases (e.g., CNAMEs to deleted third-party apps), prefer <strong>removal<\/strong> unless you have a clear migration plan.<\/p>\n<h3><span id=\"5_Safely_remove_or_update_records_in_Cloudflare\">5. Safely remove or update records in Cloudflare<\/span><\/h3>\n<p>For records you want to change on Cloudflare:<\/p>\n<ol>\n<li>In the <strong>DNS<\/strong> tab, locate the record.<\/li>\n<li>If you are fixing a record (e.g., new IP after moving to a new server at dchost.com), edit and update the target.<\/li>\n<li>If you are removing it, delete the record and confirm.<\/li>\n<li>Wait for DNS propagation; you can monitor with <code>dig<\/code> or external DNS checkers.<\/li>\n<\/ol>\n<p>Keep in mind that Cloudflare\u2019s caching and proxying (orange cloud) affect HTTP traffic, but <strong>do not change how DNS authority works<\/strong>. If a record exists and points to a take-over-able target, the risk is there whether or not the record is proxied.<\/p>\n<h3><span id=\"6_Safely_remove_or_update_records_in_cPanel\">6. Safely remove or update records in cPanel<\/span><\/h3>\n<p>For records managed by cPanel DNS:<\/p>\n<ol>\n<li>Open <strong>Zone Editor<\/strong> for the relevant domain.<\/li>\n<li>Find the <strong>A, AAAA, CNAME or NS<\/strong> record you want to change.<\/li>\n<li>Edit the target (for migrations) or delete the record completely if no longer needed.<\/li>\n<li>If you delete an entire subdomain or addon domain from the <strong>Domains<\/strong> section, double-check that its DNS entries were also removed from the zone.<\/li>\n<\/ol>\n<p>While you are in cPanel, it is a good time to review broader security settings. Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-guvenlik-sertlestirme-kontrol-listesi\/\">cPanel security hardening checklist<\/a> covers brute-force protection, malware scanning and other essentials beyond DNS.<\/p>\n<h3><span id=\"7_Test_from_the_outside\">7. Test from the outside<\/span><\/h3>\n<p>After cleanup, verify:<\/p>\n<ul>\n<li>Use <code>dig subdomain.example.com<\/code> or an online DNS lookup tool to confirm records are gone or updated.<\/li>\n<li>Visit subdomains in a browser to ensure no unexpected content appears.<\/li>\n<li>Run basic DNS diagnostics; if you hit common errors, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-hatalari-yuzunden-site-acilmiyor-dns_probe_finished_nxdomain-teshis-rehberi\/\">fixing DNS_PROBE_FINISHED_NXDOMAIN and common DNS errors<\/a> can help.<\/li>\n<\/ul>\n<h2><span id=\"Hardening_Cloudflare_Against_Subdomain_Takeover\">Hardening Cloudflare Against Subdomain Takeover<\/span><\/h2>\n<p>Beyond one-time cleanup, you can configure Cloudflare to make subdomain takeover much less likely.<\/p>\n<h3><span id=\"Avoid_risky_wildcard_records\">Avoid risky wildcard records<\/span><\/h3>\n<p>Wildcard records like <code>*.example.com<\/code> are convenient but dangerous if they point to third-party providers that allow public sign-ups. Instead:<\/p>\n<ul>\n<li>Use explicit subdomains (<code>app.example.com<\/code>, <code>status.example.com<\/code>) rather than wildcards.<\/li>\n<li>If you must use a wildcard, point it to infrastructure you fully control (e.g., your own VPS or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> at dchost.com).<\/li>\n<\/ul>\n<h3><span id=\"Use_hostnames_you_control_as_CNAME_targets\">Use hostnames you control as CNAME targets<\/span><\/h3>\n<p>Instead of pointing Cloudflare CNAMEs directly at third-party hostnames (which might become reclaimable), consider:<\/p>\n<ul>\n<li>Point <code>app.example.com<\/code> to <code>app-origin.example.com<\/code> (still your domain, under your DNS).<\/li>\n<li>Then point <code>app-origin.example.com<\/code> to the provider\u2019s hostname.<\/li>\n<\/ul>\n<p>When you change providers, you only update the second hop. While this does not eliminate takeover risk by itself, it <strong>centralises<\/strong> where provider-specific hostnames live and makes audits easier.<\/p>\n<h3><span id=\"Protect_your_domain_with_DNSSEC_and_registrar_security\">Protect your domain with DNSSEC and registrar security<\/span><\/h3>\n<p>Subdomain takeover does not usually require DNS hijacking, but strengthening DNS integrity reduces overall risk. On Cloudflare:<\/p>\n<ul>\n<li>Enable <strong>DNSSEC<\/strong> and add the DS record at your registrar.<\/li>\n<li>Use strong 2FA and API tokens with minimal scopes for DNS automation.<\/li>\n<\/ul>\n<p>If you want a refresher, we have a dedicated article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-web-sitenizi-nasil-daha-guvenli-hale-getirir\/\">what DNSSEC is and how it makes your website more secure<\/a>, and another guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-guvenligi-rehberi-registrar-lock-dnssec-whois-gizliligi-ve-2fa\/\">domain security best practices such as registrar lock, DNSSEC, Whois privacy and 2FA<\/a>.<\/p>\n<h3><span id=\"Use_Cloudflare_Access_controls_wisely\">Use Cloudflare Access controls wisely<\/span><\/h3>\n<p>Cloudflare provides access control and logging for panel users:<\/p>\n<ul>\n<li>Use separate accounts or role-based access for agencies and developers.<\/li>\n<li>Restrict who can modify DNS records, and review access periodically.<\/li>\n<li>Log and alert on changes to critical records (e.g., root domain, wildcard, MX).<\/li>\n<\/ul>\n<p>The fewer people who can create and forget temporary subdomains, the smaller your attack surface.<\/p>\n<h2><span id=\"Hardening_cPanel_DNS_and_Subdomains\">Hardening cPanel DNS and Subdomains<\/span><\/h2>\n<p>On cPanel-based hosting, a few practical habits go a long way.<\/p>\n<h3><span id=\"Always_pair_subdomain_lifecycle_with_DNS_lifecycle\">Always pair subdomain lifecycle with DNS lifecycle<\/span><\/h3>\n<p>When you create a subdomain for a test or a campaign, write down:<\/p>\n<ul>\n<li>Its expected end date (e.g., \u201cafter Black Friday campaign ends\u201d).<\/li>\n<li>Where it is hosted (cPanel, VPS, or external service).<\/li>\n<li>Who is responsible for removing it.<\/li>\n<\/ul>\n<p>When that project ends, the same person should:<\/p>\n<ul>\n<li>Remove the content or external app.<\/li>\n<li>Delete the subdomain entry in cPanel\u2019s <strong>Domains<\/strong> section.<\/li>\n<li>Confirm the DNS records were removed from <strong>Zone Editor<\/strong> (or manually delete them).<\/li>\n<\/ul>\n<h3><span id=\"Keep_DNS_authority_simple_Cloudflare_OR_cPanel_not_both\">Keep DNS authority simple: Cloudflare OR cPanel, not both<\/span><\/h3>\n<p>One common source of confusion is running <strong>two conflicting DNS zones<\/strong> \u2013 one on Cloudflare and one in cPanel \u2013 and not being sure which is actually serving the internet. We strongly recommend:<\/p>\n<ul>\n<li>Choose one system as authoritative DNS for each domain.<\/li>\n<li>If Cloudflare is authoritative, treat cPanel\u2019s DNS zone as local-only and keep it tidy, or disable it where appropriate.<\/li>\n<li>If your cPanel\/WHM is authoritative, keep Cloudflare (if used) in DNS-only mode or not connected for that domain.<\/li>\n<\/ul>\n<p>Having a single source of truth makes audits and incident response much easier.<\/p>\n<h3><span id=\"Use_separate_cPanel_accounts_to_avoid_cross-contamination\">Use separate cPanel accounts to avoid cross-contamination<\/span><\/h3>\n<p>If you host multiple client sites or projects on the same server, using separate cPanel accounts helps:<\/p>\n<ul>\n<li>Prevent one forgotten test subdomain from affecting another client\u2019s brand.<\/li>\n<li>Keep DNS zones clearly separated for audits and documentation.<\/li>\n<li>Assign responsibility: each account has a clear owner and contact.<\/li>\n<\/ul>\n<p>On our reseller hosting and VPS platforms at dchost.com, this separation is a common pattern we recommend, especially for agencies.<\/p>\n<h3><span id=\"Combine_DNS_hygiene_with_broader_panel_security\">Combine DNS hygiene with broader panel security<\/span><\/h3>\n<p>DNS is only one layer. Ensure your cPanel environment is also hardened against brute force, malware, and misconfiguration. Again, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-guvenlik-sertlestirme-kontrol-listesi\/\">cPanel security hardening checklist<\/a> is a practical companion to this article.<\/p>\n<h2><span id=\"Make_DNS_Hygiene_a_Routine_Not_a_One-Off_Project\">Make DNS Hygiene a Routine, Not a One-Off Project<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"When_to_run_a_DNS_review\">When to run a DNS review<\/span><\/h3>\n<p>Add a quick DNS pass into these moments:<\/p>\n<ul>\n<li><strong>Quarterly security or infrastructure reviews<\/strong> \u2013 scan your Cloudflare and cPanel records and re-verify unknown subdomains.<\/li>\n<li><strong>After every migration<\/strong> \u2013 when moving a site between hosting plans, VPS, or dedicated servers at dchost.com, always clean up old IPs and hostnames.<\/li>\n<li><strong>After deleting a SaaS integration<\/strong> \u2013 remove the corresponding CNAME\/TXT records.<\/li>\n<li><strong>After major marketing campaigns<\/strong> \u2013 retire landing page subdomains fully, including DNS.<\/li>\n<\/ul>\n<h3><span id=\"Simple_automation_and_tooling\">Simple automation and tooling<\/span><\/h3>\n<p>You do not need an enterprise budget to add basic automation:<\/p>\n<ul>\n<li>Use scripts or small tools that list all subdomains from Cloudflare\u2019s API and flag those returning 404\/410 or provider-specific \u201cno such app\u201d pages.<\/li>\n<li>Maintain a shared spreadsheet or configuration repository listing each subdomain, its purpose, and its owner.<\/li>\n<li>Use uptime checks for critical subdomains so you are alerted when they start returning unexpected responses.<\/li>\n<\/ul>\n<p>If you manage multiple sites, the techniques in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-sitesi-uptime-izleme-ve-alarm-kurma-rehberi\/\">website uptime monitoring and alerting guide for small businesses<\/a> can be repurposed to keep an eye on key subdomains as well.<\/p>\n<h3><span id=\"Build_a_lightweight_change_process\">Build a lightweight change process<\/span><\/h3>\n<p>Even a small checklist can prevent mistakes:<\/p>\n<ul>\n<li>For every new subdomain, record who requested it, why, and when it should be reviewed.<\/li>\n<li>For every removed service, ensure someone is assigned to clean up its DNS records.<\/li>\n<li>For agencies, include DNS cleanup in your project close-out checklist.<\/li>\n<\/ul>\n<p>These habits are simple but powerful. Over time, they dramatically reduce the chance that a forgotten test environment becomes a live security incident.<\/p>\n<h2><span id=\"How_dchostcom_Helps_You_Stay_Safe\">How dchost.com Helps You Stay Safe<\/span><\/h2>\n<p>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.<\/p>\n<p>When you host with us \u2013 whether on shared hosting, VPS, dedicated servers, or colocation \u2013 our team can help you:<\/p>\n<ul>\n<li>Review DNS zones on both Cloudflare and cPanel to identify obvious dangling records.<\/li>\n<li>Plan safe migrations so old IPs and hostnames are not left behind after you move to a new server.<\/li>\n<li>Choose a sane nameserver strategy and enable protections like DNSSEC and registrar lock.<\/li>\n<li>Design staging and testing setups that do not leave behind risky, forgotten subdomains.<\/li>\n<\/ul>\n<p>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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3090,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3089","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3089","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3089"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3089\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3090"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3089"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3089"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3089"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}