DNS Zone Cleanup

What this skill does

Walks a DNS zone export (BIND format or AWS Route53 / Cloudflare API) and identifies records that are likely dangling: CNAMEs to NXDOMAIN, A/AAAA records pointing at retired IPs, and TXT records with stale verification keys. Flags subdomain-takeover candidates.

Inputs

• zone_source: path to a BIND-format zone file, or a directive like aws:Z123ABC / cloudflare:<zone-id>.
• Optional aws_profile or CLOUDFLARE_API_TOKEN env vars.
• Optional infra_inventory: a YAML file listing currently-allocated IPs and CNAMEs (e.g., from Terraform state) to confirm "still in use".

Steps

1. Load the zone:
   • BIND: read text and parse with a small reader.
   • AWS: aws route53 list-resource-record-sets --hosted-zone-id <id>.
   • Cloudflare: curl -H "Authorization: Bearer $TOKEN" https://api.cloudflare.com/client/v4/zones/<id>/dns_records.
2. For each record, classify by type. Focus on A, AAAA, CNAME, TXT.
3. Resolve each CNAME's target with dig +short <target>. If NXDOMAIN, mark dangling-cname. Cross-check against the takeover database (e.g., *.s3.amazonaws.com patterns) and tag takeover-risk when applicable.
4. For each A/AAAA record, ping or TCP-connect to the IP on a known port (e.g., 80/443/22). No response after retries marks unreachable-host.
5. If infra_inventory is provided, cross-reference: any A/CNAME not listed there is unmanaged; tag accordingly without auto-deleting.
6. For TXT records that look like verification keys (google-site-verification=, MS=, _acme-challenge), check whether the corresponding service is still configured. Older than 1 year and unmatched -> stale-verification.
7. For NS records pointing at delegation servers, confirm those servers actually serve the subzone (dig NS <subzone> @<server>); if not, mark broken-delegation.
8. Group findings by severity: takeover-risk first, then dangling-cname, then unreachable-host, then advisory.
9. Emit a markdown report.

Output

dns-cleanup.md with a per-severity section, each row showing record type, name, target, observation, and a suggested action (delete vs verify vs migrate). Stdout prints counts.

Verification

For each takeover-risk candidate, attempt to fetch https://<name> and check whether the response includes a "domain not configured" or "no such bucket" message that confirms takeover potential. Re-resolve a sample of records 30 minutes later to rule out transient DNS misses; persistent NXDOMAIN remains flagged. Coordinate with infra owners before any deletion suggestion is acted on.

Edge cases

• Records with very low TTL: a single failed lookup may be transient; require two failed lookups separated by TTL.
• Wildcard records (*.api): will resolve for any subdomain; skip the dangling-CNAME check and document the wildcard separately.
• DNSSEC-signed zones: do not touch DNSKEY/RRSIG records.
• Email-related records (MX, SPF, DKIM): check their referenced hosts but err toward "warn, do not propose deletion" — incorrect deletion breaks email.