By Yair Knijn · July 17, 2025

You released the cloud IP but left the DNS record. An attacker took the address and your subdomain.

The audit lead signs the decommissioning ticket once the instance shows terminated and the elastic IP shows released. The compute is gone, the bill drops, the change closes clean. Nobody asks what was still pointing at that address.

The wrong assumption is that decommissioning ends at the resource. Releasing an IP and retiring the DNS record are two separate actions in two separate systems, and the checklist only enforces the first. The A record for legacy.yourcompany.com stays in the zone, now aimed at an address you no longer control.

How a released elastic IP becomes someone else's foothold

Cloud IPs are not retired when you let them go. They drop back into a shared regional pool and get handed to the next account that asks. In a busy region that next allocation can land within hours. The attacker does not need to guess your address. They allocate elastic IPs in a loop, check what public DNS still resolves to each one, and wait for a recycled address that an old record still names.

The moment they get the address your record already references, your subdomain resolves to their box. No phishing, no zone edit, no credential theft. You handed them a name your customers, your TLS automation, and your internal tooling already trust, and you did it by closing a ticket.

Dangling A and CNAME records: the takeover mechanics

A dangling record is any DNS entry whose target no longer belongs to you. An A record points at a released elastic IP. A CNAME points at a deprovisioned bucket or app endpoint whose name is now claimable. Same failure, same outcome: the name resolves, the target is attacker-controlled. Researchers spent late 2024 into 2025 reclaiming roughly 150 abandoned S3 buckets that old DNS still referenced and watched them field millions of requests for images, updates, and configs, which is what a dangling record looks like at scale.

Once they hold the address, request a certificate for the subdomain through any free CA and the validation passes, because they genuinely control what the name resolves to. CISA's own guidance treats an unexpected certificate appearing in Certificate Transparency logs for one of your subdomains as a takeover signal worth alerting on. By the time that cert shows up, the foothold is already live and serving valid HTTPS under your name.

Why decommissioning workflows skip the DNS retirement step

The cloud console makes the trap easy. Releasing an elastic IP is one button in the compute pane. The DNS record lives in a different service, often a different account, sometimes a registrar the platform team never logs into. Nothing in the release flow warns you that records still resolve to the address.

• The teardown runbook lists "release IP" and "terminate instance" but never "remove the record that named it."
• The person decommissioning owns compute, not the zone, and assumes DNS is someone else's cleanup.
• Records get created by hand during incidents and never tracked, so no inventory ties the name to the address.
• Short-lived addresses from auto-scaling churn faster than anyone reconciles the zone.

Tying address release to record removal in IPAM

The fix is to refuse to release an address until you know what resolves to it. That requires a system that already maps every address to its DNS records and reconciles that map against what DNS actually serves, not against a stale spreadsheet. Before reclaim, you query the address, see legacy.yourcompany.com still bound to it, and retire the record in the same motion. Release becomes a two-key action: the IP goes back to the pool only after its records are gone.

Spot IPAM treats an address and the names pointing at it as one record, so reclaiming an IP inside an Environment surfaces every dangling A and CNAME before the release goes through and blocks the handoff until they are cleared. See how the reconciliation works on the features page.