Route 53 record pointing to released AWS public IP – Want to understand what is the expected behavior?

Yes, this is expected AWS behavior, and what you observed is a known risk pattern rather than a misconfiguration in Route 53.

1. Reuse of released public IPv4 addresses

When an EC2 instance that has an auto-assigned public IPv4 address is stopped or terminated, the IP is released back to AWS’s public IPv4 pool. AWS may later assign the same IP to any other AWS customer.

Only Elastic IPs remain allocated to your account until you explicitly release them. So if the instance was using a normal public IP, reuse is expected.

2. Route 53 validation behavior

Route 53 does not validate whether a DNS record points to:

An existing EC2 instance

A resource still owned by your account

A currently “claimed” IP address

Route 53 is a DNS-only service. If a record exists, it will return it—regardless of whether the backend resource still exists.

3. Subdomain takeover risk

Yes, this situation can lead to a dangling DNS record scenario.

If a released public IP is later reused by another AWS customer and your Route 53 record still points to it, traffic for your subdomain can unintentionally reach that third-party resource. This is a well-known subdomain takeover class of issue in cloud environments.

4. AWS-recommended best practices

To avoid this risk, AWS generally recommends:

Use Elastic IPs if public IPs are unavoidable

Prefer Route 53 Alias records pointing to ALB, NLB, CloudFront, or API Gateway instead of raw IPs

Manage DNS records through IaC (CloudFormation / Terraform) so they are removed automatically when resources are deleted

Periodically audit Route 53 for A records pointing to public IPs

Avoid long-lived DNS entries pointing to ephemeral infrastructure

Summary

Released public IPv4 addresses can be reused by AWS

Route 53 does not validate backend resource existence

Dangling DNS records can create subdomain takeover risk

Proper DNS hygiene and alias-based architectures prevent this

This is normal AWS behavior, but it requires operational discipline to avoid security exposure.

Yes, this is expected AWS behavior—released public IPv4 addresses return to AWS's shared pool and can be reassigned to other customers, creating subdomain takeover risk if DNS records aren't cleaned up. Route 53 performs no validation or warnings for records pointing to unowned resources, as DNS is designed to be decoupled from infrastructure ownership. To prevent this, implement AWS Config rules to detect unused Route 53 records, use tagging and automation to align DNS lifecycle with resources (e.g., CloudFormation stack deletions should remove associated records), and regularly audit DNS entries with services like AWS Inspector or third-party tools that scan for dangling records. Additionally, consider using AWS Global Accelerator or Application Load Balancer ARNs as aliases instead of raw IPs, as they're tied to your account and won't be reassigned.

The best practice is not to point DNS names to IP addresses directly. For an application hosted on an EC2 instance, for example, the recommended way to expose it to the public internet is to place it behind an Application Load Balancer (ALB) and the ALB preferably behind a CloudFront distribution. The A (IPv4), AAAA (IPv6), and typically HTTPS record sets in the Route 53 hosted zone should be made alias records pointing to the DNS name of the CloudFront distribution or ALB. Their names are guaranteed not to be reused, so even though the alias records will remain in your hosted zone when the CloudFront distribution, ALB, or entire AWS account owning them is deleted/closed, the names will stop resolving to IP addresses or other destinations as soon as the CloudFront or ALB resource is deleted or disabled. Route 53 also waives request fees for alias types of records, making them the least expensive way to publish names in a Route 53 hosted zone.

If you do configure static IP addresses in your Route 53 hosted zone, they will remain there until you delete them, regardless of whether they point to AWS-owned IP addresses reassigned to another customer or any IP addresses entirely outside AWS, such as in an on-premises data centre.

When a Route 53 record points to an AWS public IP that has been released, Route 53 itself does not detect or validate that change. DNS will continue to return the IP address until you update or delete the record. Once the IP is released, AWS can reassign it to another customer, so traffic may either fail (timeouts) or, in rare cases, reach an unrelated resource. The expected behavior is therefore undefined from an application perspective but predictable from DNS: Route 53 will keep serving the record until it’s changed. This is why AWS recommends using stable targets like Elastic IPs, ALB/NLB DNS names, or alias records, rather than raw public IPs, to avoid accidental traffic leakage or outages.