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.
Operational summary
At a glance
- Symptom
- The load balancer is decommissioned, its IP is released, and the cloud provider reassigns it to another tenant.
- Likely cause
- A wildcard record resolves directly to a load balancer's static IP instead of its DNS name.
- Impact
- Every unregistered subdomain under the wildcard silently routes to a third party's infrastructure with no DNS error raised.
- Verification signal
- Re-run the detection test and a controlled negative-path test.
- Safe correction
- 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.
- Rollback or recovery
- Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
The 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.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
Fix commands and configuration
dualstack.my-alb-1234567890.us-east-1.elb.amazonaws.comaws_lb.main.dns_namedig +short $(uuidgen).domain.comVerify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.