Wildcard Records Pinned to Dead Load Balancer IPs
A wildcard A record bound directly to a load balancer's raw IP survives the load balancer's deletion, and the released IP re-enters the cloud provider's allocation pool within hours. Every unregistered subdomain under that wildcard then resolves to whichever tenant receives the IP next, and no existing takeover scanner flags it because the record was never dangling on a CNAME.
At a glance
- Unsafe setting
- A wildcard record resolves directly to a load balancer's static IP instead of its DNS name.
- Failure trigger
- The load balancer is decommissioned, its IP is released, and the cloud provider reassigns it to another tenant.
- Blast radius
- Every unregistered subdomain under the wildcard silently routes to a third party's infrastructure with no DNS error raised.
- Recommended control
- Bind wildcard records to the load balancer's ALIAS/DNS name inside the same Terraform dependency graph, and audit random subdomain resolutions monthly against live infrastructure inventory.
Fix commands and configuration
dualstack.my-alb-1234567890.us-east-1.elb.amazonaws.comaws_lb.main.dns_namedig +short $(uuidgen).domain.comThe Trap
Wildcard DNS records (*.domain.com) configured as A or AAAA entries pointing at the static IP address of a load balancer, rather than an alias or CNAME to the load balancer’s own DNS name.
The Default State
Engineers building a catch-all record for multi-tenant subdomains often skip a CNAME because some registrars and legacy DNS zones reject wildcard CNAMEs at certain apex positions, or because a classic Elastic Load Balancer was assigned a fixed Elastic IP for a past compliance reason. The wildcard gets written as *.domain.com A 52.x.x.x pointing straight at the ELB/NLB’s public IP, and that record is never revisited once the infrastructure it points to is retired.
The Blast Radius
When the load balancer is decommissioned — a Terraform destroy, a CloudFormation stack teardown, an EIP release — the IP address returns to the cloud provider’s general allocation pool. AWS, Azure and GCP all reuse released public IPs, frequently within hours. The wildcard record still resolves every non-existent subdomain to that IP, so whoever the provider hands it to next silently inherits all traffic for *.domain.com. Because the record is a wildcard rather than a fixed hostname, standard subdomain takeover scanners find nothing to enumerate: there is no specific dangling CNAME on a list, because any arbitrary string resolves. An attacker who requests any subdomain, presents a matching TLS certificate for the new tenant, and waits, can capture OAuth callback traffic, session cookies scoped to the parent domain, or HTTP-01 ACME challenges for certificates they never should have been able to issue. Internal tooling that assumes subdomain-based routing integrity — multi-tenant SaaS platforms, preview environments, SSO redirect allow-lists — inherits the exposure without any alert firing, because the DNS zone itself reports no error.
The Lead Mechanic Fix
Never bind a wildcard record to a load balancer’s raw IP. In Route53, use an ALIAS record referencing the load balancer’s stable DNS name (dualstack.my-alb-1234567890.us-east-1.elb.amazonaws.com), not the resolved address. Wire the record into Terraform via aws_lb.main.dns_name as a direct resource attribute so the record set sits in the same dependency graph as the load balancer and gets updated or destroyed atomically with it. Add a monthly audit job that resolves a random unregistered subdomain (dig +short $(uuidgen).domain.com) and checks the returned IP against a live infrastructure inventory, alerting on any address not currently owned by the account.