Apprendre
Dangling DNS and Subdomain Takeover: Finding Records That Point Nowhere
You cancelled the service but left the CNAME. Anyone who can claim that provider hostname now controls a subdomain of your domain — and inherits the trust that comes with it.
Lancez un audit DomainLens frais et utilisez le rapport comme liste de priorités.
What a dangling DNS record is
A dangling record points at a target that no longer belongs to you. The usual shape is a CNAME from a subdomain of yours to a hosted service — a status page, a marketing tool, a staging environment on a cloud provider — that you later cancelled without removing the record.
The record still resolves. The provider still owns the target name. What has changed is that the specific instance behind it is unclaimed, and on many platforms anyone can claim it by creating an account and asking for that name.
; While the service is yours — normal and correct
status.example.com. 3600 IN CNAME acme-corp.statuspage.example.
; After you cancel, the record is untouched but the
; target is unclaimed. Someone else registers
; "acme-corp" on that platform and now serves
; whatever they like from status.example.com.Why it matters more than it looks
The subdomain carries your domain name, and both people and machines extend trust on that basis. An attacker controlling it inherits far more than a page.
- Phishing that passes the eye test, because the hostname genuinely ends in your domain.
- Cookies scoped to the parent domain may be readable, depending on how they were set.
- Content served under your domain can be indexed by Google as yours.
- Certificates can often be issued for the subdomain, so the padlock appears too.
- Any allowlist that trusts *.example.com now trusts the attacker.
How to audit for dangling records
- 1Export the full zone from your DNS provider rather than working from memory — the forgotten records are exactly the ones you will not recall.
- 2List every CNAME whose target is a third-party hostname, and every A record pointing at cloud IP ranges you no longer use.
- 3For each one, resolve the target and fetch it. A provider error page saying the resource does not exist is the signal.
- 4Cross-check against your current vendors: any target belonging to a service you no longer pay for is a candidate.
- 5Delete the record. Do not repoint it somewhere harmless and leave it — an unused record is future debt.
# What does the record point at?
dig status.example.com CNAME +short
# Does the target resolve at all?
dig acme-corp.statuspage.example A +short
# What does it actually serve?
curl -sI https://status.example.com | head -n 3
# A 404 from the provider, or a "no such
# project" page, means the name is claimable.Preventing them from accumulating
CAA is the cheapest of these and the most overlooked — it takes one record and removes the attacker's easiest path to a valid certificate. See DNS record types for the syntax, and index bloat and crawl discovery for cleaning up anything that reached the index.
- Make removing the DNS record part of the checklist for cancelling any service, not an afterthought.
- Prefer a short TTL on records pointing at third-party services, so removal takes effect quickly.
- Publish a CAA record, which limits which authorities can issue certificates for your domain.
- Re-export and review the zone on a schedule — quarterly is enough for most organisations.
- Avoid wildcard records pointing at third parties; they make every possible subdomain a target at once.
How DomainLens contributes
The DNS checker shows what a hostname currently resolves to, which is the first step in confirming whether a record still points somewhere you control. For the certificate side, the SSL checker reports who issued the certificate a hostname presents — an unexpected issuer on a subdomain is worth investigating.
- How do I know if a subdomain is takeover-able?
- The record resolves, but fetching it returns a provider error stating the resource or project does not exist. That combination means the name is unclaimed on the provider side.
- Is an A record pointing at a released IP the same risk?
- Similar but harder to exploit, since the attacker must obtain that specific address. It happens on cloud platforms where addresses are recycled, so remove those records too.
- Does a wildcard DNS record make this worse?
- Considerably. A wildcard pointing at a third party exposes every possible subdomain at once rather than the few you deliberately created.
- What should I do if content was already indexed?
- Remove the DNS record first so the content stops being served, then request removal in Search Console for the affected URLs.