Subdomain Takeover: How MSPs Detect and Fix Dangling DNS Records

DNS is just a set of pointers. A CNAME record for campaign.customer.com pointing at some-project.pages-host.com works as long as the customer's account on that hosting service still owns that project name. The moment the project is deleted, the account is closed, or the trial expires, the hosting service frees the name — but the DNS record at the customer's domain registrar has no idea. It keeps pointing at a name that is now available to anyone.

If an attacker registers a new project under that exact freed name on the same hosting service, requests to the customer's subdomain now resolve to content the attacker controls, served under the customer's own domain. Nothing about the customer's registrar, firewall, or endpoints needed to be breached. The vulnerability is administrative, not technical: a cleanup step that never happened.

Subdomains get created faster than they get retired. A marketing agency spins up a campaign microsite on a static host. A developer points a subdomain at a demo environment for a sales call. A vendor integration needs a CNAME during a proof of concept that never gets formally adopted or cancelled. Each of these is a legitimate, reasonable decision at the time — the problem is that none of them go through a change process that includes "remember to remove the DNS record when this is done."

A customer that has existed for five years and used even a handful of third-party hosting or SaaS platforms almost certainly has at least one dangling record somewhere in their DNS zone. No one is being careless; the record simply outlived the reason it was created, and nothing prompts anyone to go back and check.

A takeover check is only as good as the subdomain list feeding it, and asking the customer for a list is the wrong starting point — the whole problem is that subdomains get created outside the process that would have told you about them. Passive discovery does not have this gap. Certificate Transparency logs record every publicly trusted certificate issued for a domain, and DNS enumeration against common naming patterns fills in the rest. Together they surface hostnames that were never handed to you at onboarding.

Run discovery on a schedule, not once. A subdomain that appears between two scans is either a new, deliberate change or something set up without your knowledge — both are worth a look, and the second one is exactly the kind of thing that eventually turns into a dangling record.

Not every CNAME pointing at a third-party service is a takeover risk — most of them point at something that still exists and is correctly configured. The distinguishing signal is the HTTP response when you resolve the record and request it: services that no longer recognize the target name return a distinct, fingerprinted error rather than the expected content. A 404 with specific wording from a static-site host, a bucket-not-found response from a storage provider, and similar patterns from other providers each mean the same thing — the destination is gone and the name is unclaimed.

Treat the check as connect-and-read-only: resolve the record, request the response, compare it against known unclaimed-service fingerprints. Nothing needs to be registered or claimed to confirm the finding. Actually taking over the freed name to prove exploitability is a separate action against a third-party provider, not something to do as part of a routine check.

Subdomain takeover is one specific failure mode inside a broader discovery problem: everything a customer's domains resolve to that nobody is actively tracking. It sits alongside exposed services and certificate issues as part of the same external-footprint review, not as a separate audit with its own tooling and schedule.

SecurityScore.me runs passive subdomain and asset discovery per customer domain and flags dangling records as severity-ranked findings in the same queue as the rest of external monitoring. See domain and website monitoring for the full set of external checks, and security findings for how a dangling-record finding is prioritized against everything else found across a customer's environment.