Dangling DNS Finder

Dangling DNS Finder

Find DNS records that point at infrastructure that no longer exists — the classic subdomain-takeover setup. A CNAME to a deleted ELB, or an A record to a released cloud IP, can be silently reclaimed by someone else and used to serve content under your domain.

This skill drives the repo's own tool, findmytakeover.py. It enumerates every DNS record and every live infrastructure endpoint (IPs, ELB/LB hostnames, etc.) across the configured AWS/GCP/Azure accounts, then reports any DNS record whose value has no matching live resource. No wordlists, no guessing — a record is dangling because the thing it points at is not in your inventory.

Do not write new scripts to resolve DNS or probe endpoints — the tool already collects both sides and diffs them. Your job is to configure it, run it, and interpret the output.

Prerequisites

• Read-only cloud credentials for the accounts being scanned, already set up in the local CLIs:
  • AWS — ViewOnlyAccess + SecurityAudit (or an assumable IAM role)
  • GCP — Viewer (Application Default Credentials, or a service-account key)
  • Azure — Reader (Azure CLI login, or tenant/client/secret)
  • Cloudflare — read-only API token (CLOUDFLARE_API_TOKEN env, or a token string)
  • Oracle (OCI) — read/inspect group (~/.oci/config DEFAULT profile, or a config path)
• Dependencies: pip3 install . from the repo root (installs from pyproject.toml).

Workflow

1. Configure

The tool reads findmytakeover.config (YAML) — default path is the repo root, override with -c. Enable only the providers the user actually has. For each, set enabled: true and pick credentials:

• credentials: default — use the local CLI's logged-in creds and auto-discover accounts/projects/subscriptions. Simplest; prefer this.
• Otherwise an IAM role name (AWS), a service-account JSON path (GCP), or a tenant/client/secret mapping (Azure) — and list accounts: explicitly.

A provider appears under both dns: and infra: — both must be enabled for the dangling check to run (it needs both sides to diff). Use exclude: for IP ranges/domains that are known-safe and should never be flagged (e.g. SaaS email domains, reserved ranges).

Confirm the config with the user before running — wrong account scope is the main way this wastes time.

2. Run

python3 findmytakeover.py -c findmytakeover.config
# add -d dump.csv to also save the raw DNS + infrastructure inventory

It prints how many DNS records and infra resources it collected per provider, then one line per dangling record:

Found dangling DNS record - <name> with value <value> in <cloud> cloud (account/...: <id>)

Use -d <file> whenever the user wants to inspect the raw data or when a result looks surprising — the dump shows exactly what DNS and infra were compared.

3. Report

Present the dangling records as a table: Subdomain · Value (target) · Cloud · Account. Group by cloud. Call out anything sensitive (customer-named subdomains, *-prod hosts) for manual confirmation before any deletion.

Frame confidence honestly (see Interpreting results) — a value missing from the inventory is a strong signal, not proof, and some classes of record are expected to have no backing infra.

4. Remediate (show, don't run)

The tool only reports; it does not delete. For each confirmed dangling record, show the user the deletion command for their DNS provider (e.g. aws route53 change-resource-record-sets with a change batch, gcloud dns record-sets delete, az network dns record-set ... delete).

DNS deletion is hard to reverse and outward-facing — default to showing the command and letting the user run it. Only run it yourself if they explicitly say so, and never batch-delete customer-named or *-prod records without a record-by-record confirmation.