← Back to Home

What a dangling CNAME actually looks like

"Dangling subdomain" is the kind of phrase that sounds abstract until you see one. This post is a tour of what they look like up close: how you'd find one manually, why they accumulate, and what changes the moment an attacker gets there first.

We'll use a sanitised but structurally real example throughout.

The setup

Imagine a zone for example.com. Inside it, three years ago, somebody created this record:

marketing-campaign.example.com.    300     IN    CNAME    examplecamp-prod.azurewebsites.net.

A marketing team ran a campaign. They wanted a branded URL. Someone in ops created the CNAME pointing at an Azure Web App the marketing team had spun up. The campaign ran for six weeks. It ended. The Azure Web App was deleted to stop the AWS — sorry, Azure — bill. The DNS record was not deleted, because:

  • The ops engineer who made it left the company in 2024
  • The marketing team thought ops would clean up
  • Ops thought marketing would raise a ticket
  • Nobody runs the report that would surface this

Today, this is what the record looks like when you probe it.

What it looks like from dig

$ dig +short marketing-campaign.example.com CNAME
examplecamp-prod.azurewebsites.net.

$ dig +short examplecamp-prod.azurewebsites.net A
;; <<>> DiG 9.18.x <<>>
;; ANSWER SECTION:
; (no A record returned)

The CNAME exists and resolves fine. The target the CNAME points at returns nothing. In SRE terms that's a broken pointer. In DNS security terms that's a time bomb.

If you hit the URL in a browser you'll get something like:

$ curl -sI https://marketing-campaign.example.com
curl: (6) Could not resolve host: marketing-campaign.example.com

Or on Azure specifically:

404 Web Site Not Found

The web app you have attempted to reach has been stopped.

Why attackers care

Here's the problem: Azure doesn't own the namespace examplecamp-prod.azurewebsites.net forever. Once the Azure Web App is deleted, that subdomain is back in the pool. Anyone with an Azure account can create a new Web App and claim the name.

Nothing prevents this. No verification step, no grace period, no check against existing DNS records in the public internet pointing at that name. It's first-come first-served.

So an attacker runs a scanner that does roughly this:

  1. Pull DNS records from passive DNS sources (SecurityTrails, Shodan, CT logs)
  2. Find records pointing at *.azurewebsites.net, *.herokuapp.com, *.cloudfront.net, *.elasticbeanstalk.com etc.
  3. For each one, check if the target resolves
  4. For each that doesn't resolve, attempt to claim the target at the cloud provider

When they succeed, they own a subdomain of yours. The attacker-controlled Azure Web App now serves content on marketing-campaign.example.com. Browsers trust it. TLS certificates can be issued for it (Let's Encrypt validates by HTTP challenge, which the attacker now controls). Cookies scoped to .example.com are now accessible.

What they do with it

Three common playbooks, in rough order of frequency:

1. SEO link farms. Easy money. The attacker hosts pages full of affiliate links, link-rot spam, or gambling ads. The .example.com domain gives them search engine authority they couldn't buy. Your organic search results start showing pages you didn't create.

2. Phishing. Clone your login page. Link to it from a phishing email. The URL is auth.yourcompany.com, on HTTPS, with a valid certificate. Your own employees won't spot it. Your security awareness training definitely won't teach them how.

3. Malware distribution. This is the Hazy Hawk playbook currently running against Bose, Panasonic, Deloitte, the CDC, and 34+ universities. Abandoned subdomains get turned into malware delivery platforms, often with traffic distribution systems that fingerprint the visitor's browser and location before deciding which payload to serve.

Why they're hard to find manually

In a small estate with a handful of zones, you can find danglers by hand. Dump the zone file, run dig against every CNAME, note the ones with no A record.

In a real enterprise estate that breaks down fast:

  • Scale — 200 zones × 500 records each = 100,000 records to check. At one dig per second with a polite pause between, that's 28 hours of wall time.
  • Change — records are added and removed constantly. A zone that was clean on Monday can have a dangler by Friday.
  • Indirection — CNAMEs can chain. You need to follow the chain to the leaf to know if the resolution actually succeeds.
  • Provider noise — some providers return wildcard responses for nonexistent subdomains, which looks like success to a naive checker. You need to cross-check with an actual connection attempt.
  • Timing — DNS caching and propagation mean a single dig is a snapshot. Real detection needs repeated sampling.

This is why dangling subdomain detection isn't a "run this script once" problem. It's a "run a sustained scanning infrastructure" problem.

How we catch them

DNS Watchdog resolves every CNAME in every zone on every daily scan. When a CNAME fails to resolve to an A record, we open a critical dangling_subdomain finding with the full chain documented.

The finding auto-closes when:

  • You delete the CNAME at the provider (we detect this on the next sync)
  • You recreate the resource the CNAME pointed at (we retry resolution)
  • You restore the original target

We also track the reverse: IP addresses referenced in DNS that don't appear to be hosting anything. These aren't takeover risks in the same way but they're a strong signal of DNS drift and often sit next to real problems.

The short version

A dangling CNAME is a DNS record pointing at a thing that doesn't exist anymore, at a hostname an attacker can claim. You almost certainly have some. Nobody is going to notice them by accident. And the cost of missing one has gone up a lot in the last 18 months, because attackers have built reliable automation to find them.

Book a demo and we'll show you what DNS Watchdog surfaces on an estate your size. If dangling records are in there, you'll see them on the first scan.