Patch, the HackerManiacs host: a cartoon young woman with a raspberry-pink bob, a violet hoodie and headphones around her neck, gesturing as she explains

Hey, I’m Patch. Today’s weakness is a name that outlived the thing it pointed to. Everything here happens in a legal practice lab on HackerDNA, and the company in it is fictional. Only test systems you own or have written permission to test.

This Daily Hack is about DNS hygiene. A fictional bank keeps a tidy DNS zone, and that tidiness hides a problem: one subdomain still points at a cloud resource the marketing team deleted. Your job is to cross-reference the records against live probes and name the subdomain that could be taken over.

I rated this one medium rather than easy: HackerDNA lists it as level 3 of 4, and it asks you to hold a DNS export and a set of probe results in your head at the same time. I won’t give you the answer. You’ll find it yourself in the challenge.

What a dangling CNAME is

A CNAME record is a DNS alias: it says “this name is really that other name”. Lots of cloud services expect you to point a subdomain at a hostname they give you, like a storage bucket or a hosted app.

A subdomain takeover becomes possible when that record points at a third-party resource that has been deleted, but whose name anyone can re-create. The record still resolves. The thing it resolves to is an empty slot, waiting to be claimed. MDN has a clear write-up of the pattern in its subdomain takeover article.

Three stages. Healthy: a subdomain CNAME points to a cloud bucket that exists and serves the company page. Dangling: the bucket is deleted but the CNAME is left, so the provider answers that the bucket does not exist. The risk: anyone re-creates a bucket with that name, and the company subdomain serves content it does not control. — The record never changed. What changed is who owns the thing on the other end.

Why it matters

The deleted bucket is not the bug. An empty bucket is harmless. The leftover DNS record is the vulnerability, because it keeps a real, trusted name of the company pointing at an address a stranger can claim.

And a real subdomain carries real trust. Content served from a genuine *.example address can receive cookies scoped to the parent domain, is familiar to customers, and can often be used to obtain a valid TLS certificate for that name. A phishing page on promo.yourbank.example is far more convincing than one on a random domain, because it genuinely is a bank subdomain.

Approaching the challenge

You’re given a DNS export and a set of probe results. The work is cross-referencing, not attacking. OWASP’s testing guide covers the same check under Test for Subdomain Takeover.

1. List the aliases

Read the DNS export and note every subdomain that is a CNAME to an external target. In this lab there are a handful, each pointing at some cloud resource. That is your candidate list.

2. Ask what each target actually answers

Resolving is not the same as existing. For each candidate, look at the probe result for the target it points to. A live target answers normally. A claimable one returns the provider’s does-not-exist error, the kind of response a cloud host sends when the named bucket or app was torn down.

# The shape of a takeover signature (illustrative, not the lab's data):
HTTP/1.1 404 Not Found
<Error><Code>NoSuchBucket</Code></Error>

That NoSuchBucket-style response is the tell. It means the resource is gone but the record stayed behind.

3. Don’t get distracted by the healthy names

Several subdomains here point at targets that answer perfectly normally, things like a status page, docs or a login. Those are decoys. A name that resolves and serves content is fine. You’re hunting the one whose target has vanished.

4. Name the right thing

The challenge asks for the subdomain that can be taken over, not the cloud target it points at. The vulnerable name is subdomain, and you’ll find it yourself in the challenge. Blaming the deleted bucket, or answering with the cloud target’s hostname, is the common miss.

How defenders catch and prevent it

Tie DNS lifecycle to resource lifecycle

The root cause is an ordering mistake: the resource was deleted while the record pointing at it was left behind. Fix the order and the gap never opens.

Two rows. Unsafe order: delete the cloud bucket first, defer DNS cleanup, and the name dangles with a claimable gap. Safe order: remove or repoint the DNS record first, wait for cached answers to expire, then delete the bucket, so the name never points at nothing. — The DNS record dies first, the resource dies last. Never the other way around.

Use a teardown checklist

Make “remove or repoint the DNS record” an explicit step in decommissioning, so cleanup is never the thing that gets forgotten when a campaign ends. If you might reuse the name, hold it rather than leaving it pointed at nothing.

Scan your zones continuously

Attackers scan for dangling records across every provider. Do it to yourself first. Regularly check your zones for CNAMEs whose targets return a known takeover signature, and alert on any new one. A finding here is cheap to fix and expensive to ignore.

Know every provider you use

Takeover signatures differ by provider, and the resources that can be claimed differ too. Inventory which external services your subdomains point at, so a scan knows what “does not exist” looks like for each one.

Takeaways

A dangling CNAME is a record that still resolves to a resource that’s gone.
The deleted resource is fine; the leftover record is the vulnerability.
The signature is the target’s does-not-exist response, like NoSuchBucket.
Live subdomains (status, docs, login) are decoys. Hunt the one whose target vanished.
Decommission in the safe order: record first, resource last. Scan your own zones.

Want to try the cross-referencing yourself? It’s a Daily Hack on HackerDNA (today’s is free; the archive is part of Pro). You can open HackerDNA here (affiliate link).

That’s the lab. Not the answer: the understanding. Stay curious. Stay authorized.