Three kinds of dangling — DNS Security Practitioner

A dangling record points at infrastructure that no longer exists. Three record types do it, and they hand an attacker very different things.

Ranked by what they give away

Record	Points at	What claiming it gives an attacker
`NS`	A nameserver that no longer serves the zone	Control of everything under that name — every record, including the ability to pass an ACME DNS-01 challenge and obtain a valid certificate. The most severe of the three and the least often looked for.
`CNAME`	A SaaS platform where the account was closed	A web presence on your hostname, a valid certificate for it, and cookies scoped to your domain. The common one.
`MX`	A mail service no longer in use	Mail addressed to that name, including password resets and anything a supplier sends to an address nobody monitors.

The dangling NS

Delegating internal.example.com to a provider and later closing the account leaves the delegation in place. Whoever obtains that nameserver name becomes authoritative for the whole subtree.

internal.example.com.  NS  ns1.some-provider.example.

The account is closed. The name becomes available.
An attacker registers it.

They now answer for:
   anything.internal.example.com
   _acme-challenge.internal.example.com   <- certificates
   internal.example.com  MX               <- mail

It is worse than a CNAME takeover by a wide margin, because it is a whole namespace rather than one hostname, and a CAA record at the apex does not prevent issuance for names the attacker now controls unless it explicitly constrains them.

Finding all three

# CNAMEs whose target does not resolve
for name in $(list of names in the zone); do
  target=$(dig +short CNAME $name)
  [ -n "$target" ] && ! dig +short A $target >/dev/null     && echo "DANGLING CNAME: $name -> $target"
done

# NS delegations whose servers do not answer
dig +short NS sub.example.com | while read ns; do
  dig +short A $ns || echo "DANGLING NS: $ns"
done

# MX hosts that do not resolve
dig +short MX example.com | awk '{print $2}' | while read h; do
  dig +short A $h || echo "DANGLING MX: $h"
done

The hard part is the first line — enumerating the names in your zone. That comes from the zone file itself if you hold it, from your provider’s API, or, unhelpfully, from anyone who can walk your NSEC records.

NXDOMAIN is not the same as safe

A target that does not resolve is dangling. Whether it is exploitable depends on whether the name can be claimed — an available domain registration, or a subdomain at a provider with open sign-up. Treat every one as exploitable until you have established the target cannot be obtained, because that is much quicker than being wrong.

Knowledge check

Which dangling record type is the most severe, and why?

NS — claiming it makes the attacker authoritative for the entire subtree, including the _acme-challenge name used to obtain certificates.
CNAME — it is the most common, so it carries the most risk in aggregate.
MX — mail interception exposes password resets.
They are equivalent, since all three point at infrastructure the attacker can claim.

Correct — NS — claiming it makes the attacker authoritative for the entire subtree, including the _acme-challenge name used to obtain certificates. A CNAME takeover yields one hostname. An NS takeover yields every name beneath it, plus mail for those names and the ability to pass DNS-01 validation for any of them.

Not this — CNAME — it is the most common, so it carries the most risk in aggregate. It is the most common and the most written about, and its blast radius is a single hostname.

Not this — MX — mail interception exposes password resets. Serious, and narrower: it captures mail to one domain and grants no control over any other record.

Not this — They are equivalent, since all three point at infrastructure the attacker can claim. The mechanism is shared and the consequence is not. Scope is what separates them.