Dangling DNS Records: The Subdomain Takeover Risk Most MSPs Miss

How a dangling DNS record becomes a security problem

The scenario is straightforward. A client spins up a virtual server on a cloud platform — a Digital Ocean droplet, an Azure VM, an AWS EC2 instance — and a DNS A record or CNAME is created pointing a subdomain at that resource's IP address. Later, the server is decommissioned. The cloud provider releases the IP back into a shared pool. The DNS record, however, is never deleted.

At this point, any other user of the same cloud platform can provision a new resource that receives that same IP address. If they do, the client's subdomain — still faithfully resolving via the unchanged DNS record — now points at infrastructure owned by someone else entirely. The subdomain has been taken over without any compromise of the client's registrar account, DNS provider, or hosting credentials.

Why cloud environments make this worse:

On-premise infrastructure retains its IP address indefinitely. Cloud environments are built around ephemeral resources — servers are created, resized, migrated, and destroyed constantly. IP addresses cycle through shared pools. A subdomain that was safe to leave in DNS last year may not be safe today if the underlying resource was deprovisioned at any point since.

The same mechanism applies to CNAME records pointing at cloud-hosted services. If a subdomain has a CNAME pointing at myapp.azurewebsites.net or myapp.herokuapp.com and the underlying app is deleted, anyone who registers that same application name on the hosting platform now controls the subdomain's content. This is well-documented across Azure App Services, GitHub Pages, Heroku, and similar platforms.

What attackers do with a hijacked subdomain

The value of a hijacked subdomain is its inherited authority. A subdomain of an established domain carries the parent domain's reputation — its age, its backlinks, its trust signals in email and search. That makes it useful for a range of purposes that would be significantly harder to achieve with a fresh domain.

Documented cases of subdomain takeover in the wild include hosting phishing pages that appear under a trusted brand's domain, distributing malware via what looks like a legitimate subdomain, running fraudulent job listings that exploit the parent domain's credibility to direct applicants through affiliate redirect chains, and bypassing browser security policies — such as cookie scope and content security policies — that are configured at the parent domain level.

In documented incidents involving well-known enterprise brands, hijacked subdomains have been used to host convincing fake job postings that redirected through multiple affiliate hops before landing on credential-harvesting forms — entirely under a subdomain that appeared, to any casual inspection, to belong to the brand itself. The same pattern has appeared across managed service providers' client domains more often than is typically reported.

The notification problem:

In most cases, the domain owner is not notified when a subdomain is taken over. Discovery happens reactively — a client or a third party reports content under the domain that shouldn't be there. By that point, the subdomain may have been live for weeks, indexed by search engines, and linked from external sources. Reactive discovery is the norm precisely because most DNS environments have no active monitoring at the record level.

Why MSPs face elevated exposure

A single organisation managing its own domain has one DNS zone to audit. An MSP managing fifty clients has fifty DNS zones — each with its own history of record additions and deletions, its own mix of cloud-hosted services, and its own lifecycle of project subdomains that were created for specific purposes and then forgotten.

The exposure compounds because cloud infrastructure is often provisioned and deprovisioned outside the MSP's direct control. A client's internal development team spins up a staging server, the MSP adds the DNS record, the project ends, the server is deleted — but the DNS record sits in the zone untouched because there's no automated link between infrastructure lifecycle and DNS hygiene. Multiply that pattern across a client roster and the number of potentially dangling records accumulates quietly.

There's also a reputational dimension specific to the MSP relationship. If a client's subdomain is taken over and used for phishing or malware distribution, the client holds the MSP responsible for the DNS infrastructure that allowed it. The technical explanation — "the record was left over from a decommissioned server" — is accurate but not a satisfying answer when the client's brand has been used to target their customers.

The DMARC angle on inactive subdomains

Subdomain takeover has a specific intersection with email security that's worth calling out separately. A dangling subdomain that gets taken over can be used to send email that appears to come from a trusted sub-brand of the client's domain — and if the parent domain's DMARC policy doesn't explicitly cover that subdomain, those messages may pass through with no valid policy applied.

DMARC's sp= tag (subdomain policy) applies to subdomains that don't have their own DMARC record — but only for subdomains that don't send email of their own. For subdomains that are actively taken over and used to send mail, the attacker controls the infrastructure and can configure whatever SPF and DKIM they like. The protection from the parent DMARC record is limited.

A low-effort step that closes a real gap:

For any subdomain that exists in DNS but is not used for email, adding a restrictive DMARC record directly on that subdomain is a low-risk precaution with meaningful security value. A record like v=DMARC1; p=reject; on an inactive subdomain prevents it from being used as an email spoofing vector if taken over — regardless of what the attacker configures on the underlying server. This is particularly relevant for subdomains pointing at cloud resources where IP reassignment is possible.

What DNS hygiene looks like in practice

Closing subdomain takeover exposure comes down to two practices applied consistently across all client DNS zones: auditing existing records and maintaining a removal discipline whenever cloud infrastructure is decommissioned.

An audit of existing A and CNAME records should check whether each record points to infrastructure the client still owns. For A records pointing to IP addresses, that means verifying the IP is still allocated to the client's account on the relevant cloud platform — not just that the IP resolves to something. For CNAME records pointing to cloud platform hostnames, that means confirming the application, bucket, or function at the target still exists and still belongs to the client.

Records that warrant particular scrutiny:

dns A records pointing to public cloud IPs — Digital Ocean, AWS, Azure, GCP, Linode, Vultr. IPs on these platforms are routinely reassigned after release.
link CNAMEs pointing to platform subdomains — *.azurewebsites.net, *.github.io, *.s3-website.amazonaws.com, *.netlify.app. If the target app or resource is deleted, the CNAME becomes claimable.
schedule Records for project or staging subdomains — Subdomains created for short-term projects, experiments, or client demos are rarely cleaned up after the project ends.

The removal discipline component is harder to enforce without tooling. The best point to delete a DNS record is when the cloud resource it points to is deprovisioned — but that action typically happens in an infrastructure dashboard that has no connection to the DNS zone. Building that link operationally, even if it's just a checklist item in an offboarding procedure, reduces the accumulation of dangling records over time.

Monitoring: the early warning most DNS environments lack

Periodic audits close known gaps, but they don't catch new ones as they form. Active monitoring is what bridges the gap between audits. For DNS specifically, there are two signals worth watching: unexpected changes to DNS records — additions or modifications that weren't made by the MSP team — and anomalous resolution patterns on subdomains that should have low or zero traffic.

A subdomain that pointed at a deprovisioned server and received no queries for months suddenly receiving requests is a meaningful signal. It may indicate that the IP has been claimed by another party and is now serving content — which means the subdomain has already been taken over. Detecting that promptly, rather than when a client or third party reports it, is the difference between a quick cleanup and a reputational incident.

For MSPs, monitoring across all client zones in a single view is the practical requirement. Per-client monitoring through separate tools doesn't scale and tends to get deprioritised for clients that have historically had no incidents. Consolidated monitoring surfaces anomalies across every client's DNS zone in one place, with alerting that fires before a human needs to go looking.

What good DNS monitoring covers:

change_history Record change history — An audit log of every addition, modification, and deletion across all client zones, with timestamps and attribution.
notifications_active Alerting on unexpected changes — Notification when a DNS record changes outside of a known maintenance window or without attribution to a team member.
health_and_safety Resolution health checks — Regular checks that records resolve as expected, including detection of NXDOMAIN responses that indicate a CNAME target has been deleted.

Managing this across a client roster

The operational challenge for MSPs isn't understanding the risk — it's applying consistent hygiene across every client's DNS zone without that becoming a significant overhead. The answer is a DNS management workflow that's built around the MSP model: client-organised, with full record history, active monitoring, and DMARC visibility on the same pane as the DNS zone.

With Albaspot, every DNS record across every client zone is visible in a unified view. Record changes are logged with full attribution. Monitoring and alerting cover the DNS and hosting layers for all clients without separate configuration per client. DMARC records — including subdomain policies — sit in the same interface as the DNS zone, so the connection between a subdomain's DNS entry and its DMARC coverage is visible rather than implied.

That structure means a quarterly DNS hygiene review across all client zones is a realistic operational cadence rather than a project. It means an unexpected DNS change on a client's zone surfaces in a monitoring alert rather than a client complaint. And it means the subdomain records that most commonly become dangling are tracked alongside the infrastructure they're supposed to point at — making the gap visible before it's exploited.