Finding them before someone else does — Domain Security Fundamentals

Finding dangling records is a triage exercise: enumerate what your zone points at, work out which targets are unclaimed, and judge which of those can actually be taken. The last step is the one that needs judgement, because most unresolved targets are harmless.

Step 1 — list what you point at

You need the zone contents. From your DNS provider’s export, or a zone transfer if you are permitted one:

# every CNAME target in an exported zone file
awk '$4=="CNAME" {print $1, $5}' example.com.zone | sort -u

# every delegated subdomain
awk '$4=="NS" && $1!="example.com." {print $1, $5}' example.com.zone | sort -u

If you cannot get the zone, you are reduced to guessing names, and that is a much weaker position. Being able to enumerate your own zone is itself worth having.

Step 2 — check each target

for host in $(cut -d' ' -f2 targets.txt); do
  printf '%-50s ' "$host"
  dig +short "$host" | head -1 | grep -q . && echo RESOLVES || echo 'NXDOMAIN  <-- investigate'
done

NXDOMAIN on a CNAME target is the strongest single signal. It means the platform has released the name, and on many platforms releasing means available.

Step 3 — decide whether it is takeable

This is where judgement comes in, and where automated tooling produces its false positives.

Observation	Reading
CNAME target NXDOMAIN, on a platform with open self-service signup	Likely takeable. Highest priority.
CNAME target resolves, and the service returns a "no such site" page	Often takeable — the platform holds the name but the resource is unclaimed. Read the platform’s own documentation on how it allocates names.
CNAME target resolves and serves your content	Fine. In use.
A record pointing at an address not assigned to you	Investigate. Exploitability depends on whether an attacker can obtain that specific address, which for a cloud pool is possible but not on demand.
NS delegation to nameservers that do not answer for the zone	Severe. Treat as urgent.

Do not test by claiming

The definitive test is to register the resource on the platform and see whether you get it. On your own domain that is a legitimate and sensible thing to do. Do not do it for a domain you do not own — claiming someone else’s dangling hostname is an unauthorised act regardless of intent, and demonstrating a takeover by performing one is not a demonstration anybody thanks you for.

Fixing

Delete the record. That is the whole remediation, and it is instant and complete.

The hesitation is always the same — someone might still need it — and it is answerable with evidence: check query volume if your DNS provider reports it, lower the TTL and watch, announce the removal, then delete. A record pointing at infrastructure you do not control is not serving anyone except whoever controls it.

The rule that stops them accumulating

Retire the DNS record before you cancel the service

Cancelling first creates the window. Removing the record first closes it, at the cost of a brief outage on a service you were cancelling anyway. This single ordering rule prevents almost every case.

Record the owner of every record that points at third-party infrastructure — a comment in the zone, a field in your DNS management, an inventory. When a service is cancelled there is then someone to ask.
Put DNS cleanup in the offboarding checklist for vendors, not only for people.
Re-run the enumeration periodically. Quarterly is enough. It is a short script and the findings do not accumulate quietly if something is looking.
Watch certificate transparency for your own domain. A certificate issued for a hostname you did not expect is a strong signal that somebody else controls it. The monitoring module returns to this.

Knowledge check

An audit finds three records: (1) a CNAME to a SaaS hostname returning NXDOMAIN, (2) an A record to a cloud IP not in your account, (3) an NS delegation for eu.example.com to nameservers that return REFUSED. Which do you deal with first?

The CNAME, because a dangling CNAME is the classic subdomain takeover.
The NS delegation, because whoever claims it controls every name under eu.example.com.
The A record, because an attacker could already hold that IP address.
All three are equivalent, since each exposes one name under your domain.

Not this — The CNAME, because a dangling CNAME is the classic subdomain takeover. It is the most common and it should be fixed today. But it exposes exactly one hostname, and one of the others exposes considerably more.

Correct — The NS delegation, because whoever claims it controls every name under eu.example.com. A dangling delegation hands over a whole subtree rather than a single hostname: any name beneath it, certificates for all of them, and mail. Servers answering REFUSED are not serving the zone, so the delegation is live and unserved. Highest blast radius, so it goes first — then the CNAME, then the A record.

Not this — The A record, because an attacker could already hold that IP address. Worth investigating, and it is the least reliably exploitable of the three: an attacker must be allocated that specific address from a provider pool, which they cannot do on demand.

Not this — All three are equivalent, since each exposes one name under your domain. They are not equivalent. The CNAME exposes one hostname; the NS delegation exposes an unbounded number of names beneath it. Blast radius is what orders this list.