Subdomain takeover prevention: Securing DNS against dangling CNAMEs

We once spent about three days tracking down why a legacy marketing landing page was intermittently serving a 404 page that looked nothing like our internal design. It turned out we had a dangling CNAME record pointing to an AWS Elastic Beanstalk environment that had been decommissioned months prior. An attacker had claimed the vanity URL on the platform, effectively hijacking our subdomain.

That’s the core of a subdomain takeover. It happens when your DNS points to a cloud resource that no longer exists or is no longer under your control. If an attacker notices that your promo.example.com CNAME points to a non-existent bucket or service, they can simply provision that exact resource name, and your DNS will happily route your traffic—and your cookies—directly to them.

The mechanics of a dangling CNAME

When you configure a CNAME record, you're telling the internet that a specific subdomain is an alias for another domain. If that target domain expires or is deleted, the CNAME remains active in your DNS provider’s zone file. It's essentially a signpost pointing to a vacant lot.

In the cloud, these "vacant lots" are easy to claim. If you use a provider like AWS, Azure, or Heroku, and you delete the resource without removing the DNS record, the cloud provider makes that specific service name available for anyone else to register.

Identifying and mitigating subdomain takeover

To prevent these issues, you need to treat your DNS records as infrastructure-as-code. If you aren't managing your DNS through Terraform, Pulumi, or AWS CloudFormation, you're likely already drifting into a state of insecurity.

1. Audit your existing records

Start by pulling your entire DNS zone file. Use a tool like dig or nslookup to resolve every CNAME you have. If you get an NXDOMAIN (non-existent domain) response for the target, you’ve found a dangling CNAME.

Bash
# Quick check for a specific record
dig +short promo.example.com
# If it returns a target like 'example.elasticbeanstalk.com', 
# check if that target is actually reachable.

2. Implement a validation lifecycle

We’ve learned that the most effective DNS security strategy is to delete the record before you delete the resource. If you're using ephemeral environments—like those we often discuss when hardening cloud-native HTTP clients—ensure your CI/CD pipeline includes a "teardown" step that explicitly removes the DNS entry.

3. Use verification tokens

Many cloud providers allow you to prove ownership of a domain. If you're pointing a CNAME to a service, ensure you’ve configured the provider to require a verification token (usually a specific TXT record) on your DNS side. This prevents an attacker from simply "claiming" your resource name in their own account.

Security hardening for cloud infrastructure

Beyond just cleaning up records, you need to consider how your cloud infrastructure handles identity and service discovery. If you have a complex setup, you might want to look into how you manage your internal traffic, similar to how we manage Kubernetes security with gVisor and Kata to isolate runtime environments.

Flow diagram: DNS Record: CNAME → Resource Exists?; B -- Yes → Traffic Routed Properly; B -- No → Attacker Provisions Resource; Attacker Provisions Resource → Subdomain Takeover Occurs

Dealing with the "orphaned" problem

We often find that developers create temporary vanity URLs for testing and forget about them. I've found it helpful to add a TTL (Time to Live) to these records. If a record is rarely queried, it’s a candidate for deletion. If you’re worried about breaking something, set the TTL to 60 seconds and watch your logs for a week. If no one hits it, kill it.

When things go wrong

If you discover you've been vulnerable for a while, don't panic. The first step is to remove the DNS record immediately. Then, check your logs for any unusual traffic patterns. If you're worried about session hijacking, ensure your cookies are protected using the techniques I covered in my post on __Host- prefix usage.

I’m still not convinced there’s a perfect "set it and forget it" tool for this. Most automated scanners miss edge cases where the CNAME points to a domain that is parked but not yet fully claimed by an attacker. For now, manual auditing paired with strict infrastructure-as-code policies is the best defense we have. I’d love to hear how you’re handling DNS lifecycle management in your own environments—there’s always a better way to automate this.