Preventing Subdomain Takeovers After Deploy Deletions

What Is a Subdomain Takeover?

A subdomain takeover occurs when a DNS record — usually a CNAME or A record — still points to a service endpoint that has been deprovisioned. An attacker can claim that orphaned endpoint on the same cloud platform and serve arbitrary content under your legitimate hostname. The result is a fully authenticated phishing page, malware dropper, or credential harvester hosted on your domain with zero compromise of your actual servers.

The canonical DNS record type involved is the CNAME record, which aliases one hostname to another. If blog.example.com has a CNAME pointing to my-project.vercel.app, and that Vercel project is deleted, anyone can create a new Vercel project claiming my-project.vercel.app. Visitors to blog.example.com will be served the attacker's content — and every security indicator (TLS certificate, URL bar) will show your domain.

How Takeovers Happen

The lifecycle of a subdomain takeover follows a predictable sequence:

1. Provision: A developer creates a project on a platform like Vercel, Netlify, or GitHub Pages and configures a custom domain (e.g., app.example.com) via a CNAME record in their DNS provider.
2. Deprovision: The developer deletes the cloud project — perhaps due to a migration, project cancellation, or reorganization — but forgets to remove the DNS record.
3. Reclaim: An attacker discovers the dangling record (via scanning or enumeration tools), registers the same endpoint name on the same platform, and serves content under the victim's subdomain.

This pattern repeats across every major cloud platform that offers custom domain assignment. The platform itself operates correctly: it assigns the requested endpoint to whoever claims it first. The fault lies entirely in the dangling DNS record left behind.

Real-World Impact

Subdomain takeover is not a theoretical risk. High-profile incidents have affected some of the largest companies in technology:

• Uber (2016): A security researcher took over uber.com subdomains via a dangling DNS record pointing to a deleted AWS Elastic Beanstalk environment. The researcher demonstrated full control over the subdomain's content, including the ability to serve arbitrary JavaScript.
• Slack (2018): A subdomain takeover via a dangling AWS S3 bucket exposed a subdomain associated with Slack's shared link infrastructure. The researcher could have served malware or phishing pages under a verified Slack hostname.
• Shopify (2020): Multiple Shopify subdomains were vulnerable to takeover via dangling CNAME records pointing to deprovisioned third-party SaaS endpoints. The findings were disclosed through Shopify's bug bounty program.

The common thread in all of these incidents: an engineer deleted a cloud resource but didn't delete the DNS record. The business impact includes loss of customer trust, brand damage, and the cost of incident response. For companies handling sensitive data, a successful takeover can also trigger regulatory reporting obligations under GDPR, HIPAA, or PCI-DSS.

Commonly Vulnerable Services

Any platform that allows users to assign custom domains is a potential takeover vector. The most commonly targeted services include:

• Vercel: CNAME from your domain to *.vercel.app. Deleting a project frees the project alias.
• Netlify: CNAME to *.netlify.app. Same reclaim mechanism.
• GitHub Pages: CNAME to *.github.io or an A record to GitHub's Pages IPs. Deleted repositories free the hostname.
• AWS S3 (static hosting): CNAME to an S3 bucket endpoint. Deleted buckets can be re-registered by any AWS account.
• Heroku: CNAME to *.herokuapp.com. Deleted apps free the app name.
• Azure Cloud Services / Azure Storage: CNAME to *.cloudapp.net or storage endpoint.
• Shopify: CNAME to shops.myshopify.com.
• Fastly, Cloudflare Workers, and other edge compute platforms: Any service that assigns per-customer endpoints under a shared domain.

This list is not exhaustive. Any platform that maps customer names to shared infrastructure should be treated as a potential takeover source.

How to Prevent Takeovers

Prevention requires integrating DNS hygiene into your standard operating procedures. These five controls form a defense-in-depth strategy:

1. Remove DNS Records Before Deleting the Service

This is the single most effective control. Make DNS cleanup a prerequisite in your decommissioning checklist. If you use infrastructure-as-code (Terraform, Pulumi, CloudFormation), the same PR that removes the cloud resource should also remove the DNS record. For manual deletions, run a pre-deletion checklist that includes DNS verification.

A practical approach: maintain a mapping of which DNS records point to which cloud resources. When a resource is decommissioned, query this mapping to identify all associated DNS records and delete them before deprovisioning the resource. This way, even if the deletion is reverted or delayed, the dangling record window is eliminated.

2. Audit DNS Records Regularly

Schedule automated DNS audits — weekly for critical domains, monthly for lower-risk zones. For each CNAME and A record in your zone, verify that the target endpoint still resolves and is owned by your organization. Tools that can help:

• dig: Query the target directly to check resolution status
• subjack: Open-source tool that tests CNAME targets for takeover viability
• nuclei: Template-based scanner with dedicated takeover templates
• dnsrecon: DNS enumeration and zone audit tool

3. Use Verification Tokens

Some platforms support verification methods (TXT records, DNS challenge tokens) that prove ownership before a custom domain becomes active. While this primarily prevents accidental or unauthorized domain assignment, it adds a layer of protection against takeovers. If an attacker claims your old endpoint but the platform requires domain verification, the takeover will fail.

4. Set Up Monitoring for DNS Record Failures

Monitor DNS resolution for unexpected NXDOMAIN responses or changes in resolved IP addresses on your critical subdomains. A sudden NXDOMAIN on a subdomain that was previously resolving successfully is a strong signal that the target resource has been deleted. Integrate this monitoring into your alerting pipeline (PagerDuty, Opsgenie, Slack) so DNS issues are triaged with the same urgency as application errors.

5. Prevent Dangling Records at the Provider Level

If you operate a DNS or subdomain service (as we do at is-cool-me), implement checks at registration time. For example, when a user configures a CNAME target, proactively verify that the target exists. If the target later becomes unreachable, flag the record for review. This shifts the detection burden from the domain owner to the platform operator.

How to Check for Existing Takeovers

If you suspect your organization may already have dangling records, run a one-time scan immediately. Here is a practical approach using standard tools:

Using dig for Manual Checks

# Resolve the suspect subdomain
dig +short app.example.com

# If it returns an IP or CNAME, check the target
dig +short my-project.vercel.app

# If the target returns NXDOMAIN or a default landing page
# (e.g., "The page you were looking for doesn't exist"), it is reclaimable.

Using subjack for Automated Scanning

# Install subjack
go install github.com/haccer/subjack@latest

# Run a scan with a list of subdomains
subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt -ssl

Using nuclei for Comprehensive Coverage

# Run takeover-specific templates
nuclei -l subdomains.txt -t ~/nuclei-templates/takeovers/ -o takeovers.txt

These tools check whether a CNAME target is still available for registration. A positive result does not guarantee an active takeover — it indicates a dangling record that could be claimed.

Incident Response: You Found a Dangling Record

If your automated scan or monitoring alert identifies a dangling record, follow this incident response process:

1. Confirm the dangling record: Run a manual dig to verify the record still exists and the target is unresolvable or unclaimed.
2. Check for active takeover: Visit the subdomain in a browser. Does it serve unexpected content? Check the TLS certificate — an attacker may have provisioned a Let's Encrypt certificate for your subdomain.
3. Remove the DNS record immediately: Delete or update the CNAME or A record. This is the only action that definitively closes the takeover window.
4. Assess impact: If you confirmed active takeover, determine what content was served, how long it was active, and whether any users may have been affected. Review server logs for referrer traffic to the compromised subdomain.
5. Notify stakeholders: Depending on severity, contact your security team, legal department, and affected users. If the takeover was used for phishing, consider filing a report with Google Safe Browsing and other threat intelligence feeds.
6. Perform a root cause analysis: Why was the DNS record left behind? Was there a gap in the decommissioning process? Update your runbooks and checklists to prevent recurrence.

Automation: Script Your DNS Audit Checks

Manual audits are error-prone and don't scale. Here is a production-ready Bash script you can adapt for your cron-based DNS audit pipeline:

#!/bin/bash
# dns-audit.sh - Check CNAME records for dangling targets
# Usage: ./dns-audit.sh subdomains.txt

SUBDOMAINS_FILE="$1"
if [[ -z "$SUBDOMAINS_FILE" ]]; then
  echo "Usage: $0 <subdomains-file>"
  exit 1
fi

while read -r subdomain; do
  # Get the CNAME target
  target=$(dig +short "$subdomain" CNAME | head -1)

  if [[ -z "$target" ]]; then
    # No CNAME - check for A record fallback
    ip=$(dig +short "$subdomain" A | head -1)
    if [[ -n "$ip" ]]; then
      echo "[A] $subdomain -> $ip (manual check recommended)"
    fi
    continue
  fi

  # Check if the target resolves
  target_resolved=$(dig +short "$target" | head -1)

  if [[ -z "$target_resolved" ]]; then
    echo "[DANGLING] $subdomain -> $target (target does not resolve)"
  else
    echo "[OK] $subdomain -> $target -> $target_resolved"
  fi
done < "$SUBDOMAINS_FILE"

Extend this script with notification handlers (Slack webhook, email, PagerDuty) and schedule it via cron:

# Run every Monday at 9 AM
0 9 * * 1 /path/to/dns-audit.sh /path/to/subdomains.txt | tee -a /var/log/dns-audit.log

For organizations with hundreds of subdomains, consider building a dedicated DNS audit service. Store historical scan results in a database, track resolution changes over time, and generate weekly reports for your security team.

Beyond CNAME: Other Record Types at Risk

While CNAME records are the most common takeover vector, other record types can also create risk:

• NS records: A delegated subdomain with an NS record pointing to an inactive nameserver can be zone-taken over.
• AAAA records: IPv6 addresses associated with deprecated resources.
• ALIAS/ANAME records: Some DNS providers use synthetic record types that behave like CNAMEs at the zone apex.
• SRV records: Service records pointing to deprovisioned hosts.

Include all record types in your audit scans, not just CNAMEs.

Conclusion

Subdomain takeover is a preventable security issue. The fix is straightforward — remove DNS records when you decommission resources — but it requires discipline and process integration. Automated auditing, monitoring, and incident response playbooks turn a one-time cleanup into a sustainable security practice.

At is-cool-me, we take DNS security seriously. Our platform includes automated checks to reduce the risk of dangling records for our users. If you have questions about securing your subdomains, join our Discord community or reach out through our contact page.

Deployment scenario from operations

A removed hosting project left stale DNS records pointing to reclaimable targets, creating takeover risk.

Common mistakes

• Deleting deployments before removing DNS aliases.
• Failing to inventory stale records after platform migrations.
• Not monitoring hostnames for orphaned targets.

How to verify it works

1. Enumerate CNAME/A records and compare against active controlled assets.
2. Attempt ownership validation checks to detect reclaimable targets.
3. Remove stale mappings and re-validate with resolver checks.