CertaDNS
Skip to lesson

Subdomain Takeover · lesson 1 of 2

Dangling records

After this lesson you can

Explain how a leftover DNS record hands an attacker a hostname you own.

Assumes you have read The records worth knowing, field by field.

A dangling record is one pointing at something that is no longer yours. It is the most common serious finding in mature domain estates — not because it is hard to avoid, but because nothing breaks when it is created and nothing complains afterwards.

The mechanism

Six steps, and none of them looks like a mistake at the time:

1. Marketing signs up for a SaaS platform.
2. They add:  campaigns.example.com  CNAME  customer-4412.saas.example.
3. The platform serves the site. Everything works.
4. Two years later the subscription lapses. The platform frees the name.
5. The CNAME stays in your zone, because nobody was told.
6. Someone signs up to the same platform and claims customer-4412.

   campaigns.example.com now serves their content.

Your DNS is unchanged and behaving correctly. The record still resolves. It resolves to infrastructure someone else controls.

Why this is worse than it sounds

A hostname under your domain is not neutral. It inherits trust that your organisation spent years accumulating:

  • Phishing that survives inspection. A careful user who checks the address bar sees a genuine hostname on your genuine domain.
  • Certificates. Whoever controls the hostname passes domain validation and obtains a valid certificate for it. The padlock is real. CAA narrows which CA, and does not stop it.
  • Cookies. Anything scoped to .example.com is sent to the attacker-controlled host. Session cookies with a domain-wide scope are exposed by this.
  • Allowlists. Content security policies, CORS configuration, firewall rules and mail filters written in terms of your domain now include a host you do not control.

Which records can dangle

RecordHow it danglesSeverity
CNAMEPoints at a SaaS hostname on a platform where the resource has been released and can be re-claimed.Highest. Easiest to exploit and by far the most common.
A / AAAAPoints at a cloud IP that was released back to the provider’s pool.High, and opportunistic — the attacker must happen to be allocated that address.
NSDelegates a subdomain to nameservers or an account that no longer exists.Severe. Whoever claims it controls the entire subtree, not one hostname.
MXPoints at a mail platform no longer in use.Severe. Mail to that domain is delivered to someone else.
TXTA verification token for a cancelled service.Lower, and real — it may let that platform’s account holder re-assert a claim on your domain.

Dangling NS is the one to look for first

A CNAME hands over one hostname. A dangling NS hands over an entire subdomain tree: the claimant answers for *.eu.example.com and can create any name beneath it, obtain certificates for all of them, and receive mail. It is rarer than a dangling CNAME and considerably worse, and it typically comes from a delegation to a regional office or an agency that was wound up.

Why nobody notices

Every incentive points away from finding these:

  • Nothing breaks. Monitoring is green because the name resolves.
  • The person who created it has usually left, or was never in the DNS team.
  • Deleting a record feels riskier than leaving it, so zones accumulate records nobody will take responsibility for removing.
  • The gap between the subscription lapsing and someone claiming the name can be years, so there is no moment that prompts a review.

The consequence is that a zone of any age is a historical record of every platform the organisation has ever trialled. The next lesson is about finding those and about the process that stops them accumulating.

Last reviewed