Service Deleted — DNS Forgotten? How Subdomain Takeovers Start

A campaign site is retired. The help centre moves. A preview environment is deleted. The SaaS subscription ends — but DNS still contains a CNAME from promo.example.com to the old service.

To a visitor, that may look like nothing more than a broken subdomain. From a security perspective, it can become something else: if the target hostname or associated resource can be claimed again at the third-party provider, somebody else may be able to serve content from your own subdomain.

Microsoft and OWASP describe this pattern as dangling DNS and subdomain takeover. It is less an exotic DNS trick than a lifecycle failure: the DNS record outlives the service it once represented.

The dangerous moment is often cleanup

Teams think about DNS when launching. During shutdown, they think about cost. The ticket becomes: delete the cloud app, cancel the SaaS plan, archive the project. The DNS record feels like a small detail and survives.

That is why old campaigns, former staging systems, migrated help centres, temporary landing pages, demos, and proofs of concept deserve special attention.

The better decommissioning question is not only “Is the service shut down?” It is “Which domain, subdomain, redirect, OAuth configuration, and external reference pointed to this service — and what happens to each of them now?”

Not every broken DNS record is automatically takeable

This distinction matters because security guidance should not turn every failed DNS target into an emergency.

A dangling CNAME is not automatically exploitable. A takeover generally needs two conditions:

1. Your DNS still references a resource or service you no longer control.
2. The provider allows another account to claim the relevant resource, hostname binding, or domain association.

Providers differ. Some reserve names after deletion, some require additional domain verification, and others provide service-specific anti-takeover controls. GitHub Pages, for example, recommends verifying custom domains so that another GitHub user cannot simply attach a still-configured domain to a different Pages site.

A good audit should therefore never treat “the DNS target does not respond” as proof of takeover. It is a candidate for manual validation, not an automatic exploit verdict.

Why a taken-over subdomain is more than an ugly 404

A page controlled by somebody else at support.example.com still carries your company domain. That gives it something a random phishing domain does not have: inherited trust.

Potential impact depends on the surrounding architecture:

• phishing or fake login content can appear on a trusted hostname,
• old links and bookmarks can suddenly lead to attacker-controlled content,
• wildcard CSP, CORS, or other allowlists may still trust the subdomain,
• OAuth or SSO configurations may contain stale redirect URIs,
• cookies scoped too broadly to the parent domain can increase impact,
• search results, PDFs, QR codes, and external links may continue to send users there.

The useful question is therefore not only who can serve HTML. It is which other systems still trust that hostname.

Five operational red flags

1. Nobody can assign an owner to each DNS record

The agency manages the website, IT controls the registrar, and marketing operates its own landing-page platform. If nobody can identify the purpose, provider, and owner of a record, obsolete entries become permanent residents.

2. The service is deleted before DNS is changed

OWASP recommends the safer decommissioning order: update or remove DNS while the resource is still under your control, account for TTL and propagation, and only then release the external resource.

3. Wildcard DNS is used for convenience

A *.example.com record can be legitimate, but it expands the trust surface. GitHub explicitly warns against wildcard DNS in the Pages context. Wildcards should be narrow, intentional, and documented.

4. Temporary subdomains never enter an inventory

Everyone remembers www and app. The forgotten names are more likely to be beta, events, jobs, demo, docs-old, or last year's campaign. Temporary infrastructure often survives organizationally long after it stopped being useful technically.

5. DNS and the service have different owners

The person deleting a Vercel, GitHub, Azure, Netlify, helpdesk, or shop resource may have no access to the DNS provider. Decommissioning therefore needs an explicit handoff step.

A useful audit starts with a DNS inventory

For every public domain and subdomain, document at least the record type, current target, business purpose, responsible owner, related provider, whether the target still exists, whether domain ownership is verified at the provider, the last review date, and the intended decommissioning process.

Pay special attention to external targets: cloud hostnames, SaaS subdomains, CDN endpoints, help centres, shop platforms, website builders, and former agency or campaign infrastructure.

OWASP's testing guidance combines subdomain enumeration, provider fingerprint detection, and manual validation. The last step is crucial: automated scanners can identify candidates, but actual claimability depends on the provider's current ownership and verification rules.

Decommissioning needs a definition of done

For an externally reachable web service, “shut down” should mean more than “billing stopped”:

1. Map dependencies: DNS, links, redirects, OAuth/SSO, CSP/CORS, email, monitoring, and documentation.
2. Plan a replacement or redirect if the hostname still has value.
3. Change or remove DNS while the old resource is still under your control.
4. Account for TTL and DNS propagation.
5. Delete the external resource or terminate the service.
6. Verify the hostname again from a clean browser or network.
7. Remove stale trust relationships such as OAuth redirects, allowlists, and webhooks.
8. Update the inventory.

This does not require heavyweight enterprise governance. A small team can make it a short mandatory decommissioning checklist.

Domain verification is a second layer of defence

Where a provider offers domain verification, enable it. GitHub documents custom-domain verification for Pages specifically as a defence against takeover scenarios. Microsoft likewise documents protection mechanisms around verified domains in Azure.

But verification does not replace DNS hygiene. If a record is no longer required, remove it. Provider-side controls are defence in depth, not permission to leave obsolete infrastructure behind indefinitely.

What Website-Pflichtencheck would inspect

A DNS lifecycle and subdomain-takeover review can inventory publicly visible subdomains and DNS targets, identify mappings to third-party services, flag targets that no longer exist, manually validate candidates against current provider behaviour, review wildcard records, and confirm whether provider-side domain verification is enabled.

The review should also inspect the trust relationships that remain around old hostnames: cookies, CSP, CORS, OAuth/SSO, webhooks, email, QR codes, documents, and monitoring.

The goal is not to label every broken subdomain a crisis. It is to create a clean lifecycle: when a resource disappears, the technical trust relationship to that resource must disappear too.

A DNS record is tiny. Its lifetime can still exceed everyone's memory of why it was created. That is exactly why DNS cleanup belongs in routine website operations.