DNS Record Cleanup: Find Stale Records, Audit Zones, and Remove

DNS record cleanup is finding and removing stale records - old A records pointing to decommissioned servers, CNAMEs pointing to moved services, MX records for retired email providers. The cleanup process: audit each record, verify it still resolves to a live endpoint, and remove what doesn’t. The team that does this quarterly has clean zones. The team that hasn’t cleaned in years has hundreds of stale records pointing to nothing.

Table of contents

• Why stale DNS records are a problem
• Find stale records
• The cleanup workflow
• Subdomain takeover
• Automation with Infrastructure as Code
• FAQ

Why stale DNS records are a problem

Stale DNS records cause:

• Security risk: Subdomain takeover. An attacker registers the IP/hostname a stale CNAME points to and serves content on your subdomain.
• Wasted load: Old records still resolve and clients still try to connect to dead endpoints.
• Confusion: Engineers don’t know which records are still in use.
• Email deliverability: Old MX records cause backscatter or send to retired servers.

Major subdomain takeover incidents (Slack, GitHub, AWS customers) have all involved stale DNS records. The team that cleans quarterly avoids the risk; the team that hasn’t cleaned in years has many takeover candidates.

Find stale records

Tools:

• DNSdumpster, SecurityTrails, crt.sh: External scan of public DNS records.
• OctoDNS (open-source): Compare DNS zone files across providers, find discrepancies.
• dnscontrol (open-source): Declarative DNS management with preview.
• terraform-provider-dns: Manage DNS via Terraform.
• awslabs/dnsdiag: DNS diagnostics.

Manual audit approach:

# Get all records for a zone
dig +short example.com ANY
dig +short _dmarc.example.com TXT

# Verify each A record resolves and the host is alive
for ip in $(dig +short example.com A); do
  nc -zv -w 3 $ip 80
done

The team that uses an automated scanner finds issues faster than manual review.

The cleanup workflow

For each record in the zone:

1. Verify the endpoint is alive (curl, nc, ping).
2. Check usage logs - any traffic to this hostname in the last 90 days?
3. Check with team owners - is anyone using this?
4. If unsure, lower TTL first (60s) for a week, then remove.
5. Document what was removed and why.

The team that lowers TTL before removing has a safety net if the record was still in use. The team that just deletes and hopes has at least one outage from a too-aggressive cleanup.

Subdomain takeover

Subdomain takeover happens when:

1. Your DNS has a CNAME to myapp.herokuapp.com (or similar third-party provider).
2. The Heroku app is deleted.
3. The DNS record still points to myapp.herokuapp.com.
4. Someone else registers myapp on Heroku (or the provider releases the name).
5. Your subdomain now serves attacker-controlled content.

Prevention:

• Audit CNAMEs to third-party services quarterly.
• Use host providers with reserved names (won’t release deleted names).
• Use NS records to delegate subdomains you fully control.
• Remove CNAMEs immediately when decommissioning the upstream service.

Tools:

• Subjack, SubOver, can-i-take-over-xyz: Open-source takeover scanners.
• Detectify, ProjectDiscovery: Commercial scanners.

The team that scans for subdomain takeover candidates finds the risk before the attacker does.

Automation with Infrastructure as Code

The best long-term fix: manage DNS in code (Terraform, dnscontrol, OctoDNS).

With Terraform:

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 300
  records = ["203.0.113.42"]
}

The team that uses IaC has every DNS record in version control. Cleanup is terraform destroy for the resource. The team that uses the registrar’s web UI has no audit trail and no easy cleanup.

FAQ

How often should I audit DNS records?

Quarterly for most zones. Monthly for high-risk zones (CNAMEs to third-party providers, exposed services). The team that does this catches subdomain takeover candidates before they’re exploited.

What is the biggest DNS security risk?

Subdomain takeover via stale CNAMEs. Major companies have had incidents (Microsoft, GitHub, AWS customers). The fix: audit CNAMEs to third-party providers, remove records pointing to deleted services.

How do I know if a record is stale?

Three checks: (1) does the endpoint respond? (2) any traffic to the hostname in the last 90 days? (3) does any team owner claim it? The team that uses all three has the most accurate answer.

Should I delete DNS records or just lower TTL?

Lower TTL first (60s) for a week, then delete. The lower TTL means clients cache for less time, so when you delete the recovery is fast. The team that just deletes has at least one bad experience from a too-aggressive cleanup.

What tools do you recommend?

OctoDNS or dnscontrol for declarative DNS management (sync across providers, audit diffs). Subjack or can-i-take-over-xyz for subdomain takeover scanning. AWS-native: Route 53 health checks and CloudWatch logs for traffic analysis.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references:

• Static/Domains