Your app team shipped a project last year. They spun up an EC2 instance, pointed a subdomain at it, and moved on. Six months later, the project got killed. The instance got terminated. The Elastic IP got released.
Nobody touched DNS.
That subdomain — still carrying your organization’s brand trust — is now resolving to an IP address controlled by a stranger. Maybe a researcher. Maybe an attacker.
Here’s the worst part: your monitoring thinks everything is fine. The A record resolves. The IP is live. There’s no NXDOMAIN, no 404, no “bucket not found” error page. Every standard dangling DNS check passes clean. The record isn’t dangling — it’s pointing to a perfectly healthy IP address. It just doesn’t belong to you anymore.
The Detection Gap
The concept is deceptively simple. A DNS record — A, CNAME, NS — points to a resource your organization no longer controls. An attacker claims that resource and now controls what gets served on your subdomain.
Most subdomain takeover detection focuses on finding dangling DNS records that could be claimed by an attacker — NXDOMAIN responses, “NoSuchBucket” error pages, or service-specific 404s. Tools like dnsReaper are purpose-built for this and do it well. But when AWS recycles an IP to a new customer, the A record still resolves to a live, responding address. There’s no error to detect. This variant is invisible to resolution-based scanning.
The Kill Chain: EC2 + Recycled IP
Here’s how this plays out in AWS at enterprise scale:
Step 1: An app team gets a subdomain for their project. In most enterprises, this happens through one of several paths: the central DNS team creates an A record in the parent zone via a ticket request (app.yourcompany.com → 52.x.x.x), the app team’s IaC pipeline creates a Route 53 record in a delegated zone as part of their deployment, or the central team delegates an entire subdomain via NS records to a Route 53 hosted zone in the app team’s AWS account. All three are common. All three create the same dependency between a DNS record and a cloud resource.
Step 2: The app team provisions an EC2 instance, allocates an Elastic IP, attaches it, and the A record resolves to that EIP.
Step 3: The project wraps up. The team terminates the instance and releases the Elastic IP back to the AWS pool. They close the Jira ticket. Done. Nobody tells the central DNS team. If the A record lives in a delegated zone, the central team may not even know the underlying resource is gone.
Step 4: AWS recycles that IP. Another customer’s workload gets assigned 52.x.x.x. Your A record now points to their infrastructure. The DNS record resolves successfully. The IP responds to connections. Nothing looks broken.
Step 5: At this point, anyone AWS assigns that IP to can receive traffic intended for your subdomain. It could be an innocent customer who never notices. Or it could be an attacker — researchers have documented campaigns where actors allocate hundreds of Elastic IPs and check each one against passive DNS records to identify subdomains they’ve accidentally inherited. Either way, your monitoring won’t flag it because the record never stopped resolving.
Layered Defense: Security Architecture That Actually Catches This
Because the recycled IP variant is invisible to conventional DNS scanning, you need to shift your detection strategy from “does this record resolve?” to “does this record point to something we own?”
Layer 1: Preventive Controls — Make the Dangerous Path Harder
SCPs and resource tagging. Service Control Policies can restrict who can release Elastic IPs or delete Route 53 hosted zones, and enforce tagging requirements on public-facing resources. Tags like dns-record, dns-zone, and resource-owner create an auditable link between infrastructure and DNS. Neither of these are silver bullets on their own — tags get missed, SCPs can’t orchestrate multi-step workflows — but they’re prerequisites that make your detective controls and automation effective.
Requirement: No A records pointing to ephemeral cloud IPs. At the centralized DNS level, the parent zone team should never create A records — or delegate subdomains — that resolve directly to EC2 public IPs or Elastic IPs. If a subdomain needs to front an EC2 workload, require a load balancer or CloudFront distribution in front of it — resources with stable, non-recyclable DNS names. This eliminates the recycled IP vector at the architecture level. At the AWS account level, deploy automation (via Lambda, EventBridge, or AWS Config custom rules) to detect or prevent Route 53 A records pointing to ephemeral IPs within delegated zones. The central team controls the parent zone, but app teams with delegated zones can still create their own A records — so enforcement needs to exist at both layers.
Requirement: No uncontrolled subdomain delegation. Full NS delegation to a cloud-hosted zone should require security review and lifecycle tracking. This is the highest-risk pattern and most enterprises have zero visibility into how many delegated subdomains exist. The reason it’s high-risk: if the app team’s AWS account is decommissioned or the Route 53 hosted zone is deleted, an attacker who reclaims that zone gets full DNS control over the subdomain. They can create any record they want — MX records for email interception, TXT records to pass domain validation, additional A records. The works.
Layer 2: Detective Controls — This Is Where Most Enterprises Fail
Standard DNS scanning won’t catch recycled IP takeovers. You need controls that answer a different question: does this record point to something we own?
CloudTrail event correlation — your most actionable detection. Monitor CloudTrail for ReleaseAddress (Elastic IP releases), TerminateInstances, and DeleteHostedZone events. When any of these fire, use EventBridge + Lambda to automatically cross-reference Route 53 for A records or NS delegations still pointing to the released resource. If a match exists, that’s an immediate alert — not a quarterly finding. This catches the gap at the moment it’s created, before AWS recycles the IP. It’s custom work, but it’s straightforward to build and it’s the single most valuable detection for this attack vector.
CSPM tools — you have the data, but you’ll need to build the check. If you’re running a CSPM platform like Dome9 (Check Point), Orca, Wiz, or Prisma Cloud, you already have a continuously updated inventory of your cloud resources and their IPs. The missing piece: none of these tools natively cross-reference your DNS records against that inventory to flag “A record pointing to an IP we don’t own.” But the data is there. Build a custom policy or query that pulls your Route 53 records and validates each A record against your known cloud IPs. It’s not plug-and-play, but it’s the right long-term architecture.
AWS Config rules — possible but non-trivial. In theory, you can write custom Config rules that evaluate whether DNS records still point to resources you own. In practice, this requires Lambda-backed evaluation logic that cross-references Route 53 against your EC2 and EIP inventory. It’s more engineering effort than a simple Config rule. Worth doing if you have the team to build and maintain it, but don’t underestimate the investment.
DNS resolution scanning (for classic variants only). Tools like dnsReaper, subjack, nuclei templates, and the community-maintained can-i-take-over-xyz repository will catch S3, Beanstalk, and CloudFront takeover patterns where error pages are visible. They won’t catch recycled IPs. Use them as one layer, not your entire strategy.
Layer 3: Process and Governance — Technology Can’t Fix a Broken Process
Tie DNS lifecycle to resource lifecycle. Your decommissioning checklist must include DNS cleanup as a mandatory step — DNS records pointing to resources you don’t control should be treated as policy violations, not technical debt. If the CloudFormation or Terraform template that creates the resource also creates the DNS record, the teardown process must remove both atomically. If DNS records are created outside of IaC, you’ve already lost visibility.
Periodic subdomain delegation audits. Go find every NS delegation in your zone files. Verify that each one points to a Route 53 hosted zone you actually own and manage. Do this quarterly at minimum.
Change management integration. A lightweight approval workflow that validates “does this record point to a resource we own?” before creation — and “has the DNS record been removed?” before resource decommissioning — is enough.
What To Do Now
If you take one thing from this post, make it this: audit all of your existing subdomain delegations and A records this week.
Enumerate every NS delegation, every CNAME pointing to an AWS service, every A record resolving to an Elastic IP or EC2 public IP. Cross-reference each one against a live resource in your AWS accounts. Don’t just check whether they resolve — check whether they resolve to something you own.
Is this IP still ours? That’s the only question that matters. Don’t wait for an attacker to ask it first.
If this was useful, subscribe to StepToCyber for weekly post on securing AI adoption at enterprise scale.
References:
kmsec.uk, “Passive Takeover — Uncovering (and Emulating) an Expensive Subdomain Takeover Campaign“ — Documents a real-world campaign using ~700 Elastic IPs to cycle through AWS IP space and claim dangling A records.
Assetnote / PortSwigger, “Introducing Ghostbuster“ — Coverage of the Ghostbuster tool built to detect dangling Elastic IP takeovers.
AWS, “Continually Enhancing Domain Security on Amazon CloudFront“ — AWS’s mitigations requiring SSL/TLS certificate verification for CloudFront alternate domain names.
Punk Security, “dnsReaper“ — Open-source tool for detecting dangling DNS records vulnerable to subdomain takeover.