How do you test subdomain takeover prevention?

What subdomain takeover prevention testing is actually checking

The test is not just “does a subdomain resolve.” It asks whether the DNS record still points at a service that no longer belongs to you, and whether that hostname can be claimed by someone else. That means checking for dangling CNAMEs, deprovisioned SaaS targets, expired cloud resources, and stale records that still answer under your brand.

A useful test starts with inventory, then validates ownership. Compare active DNS against the services and platforms that were ever attached to the domain, including marketing tools, app hosting, ticketing systems, and temporary environments. If the target service has been removed but the DNS record remains, treat that as an exposure until the record is removed, repointed, or otherwise reclaimed.

For a broader view of what should already be in scope, the Attack Surface Management Guide is the natural starting point because takeover testing is part of continuous external asset discovery, not a one-off DNS check.

How to run the practical validation step

Once you have the candidate list, test each hostname for takeover conditions in a controlled way. The aim is to confirm whether the external service returns a claimable state, such as a provider landing page, an unbound hostname, or an error pattern that indicates the resource is gone but the DNS alias still exists. Pair that with a review of the underlying platform account, because a record may be safe only if the original service is still provisioned and bound to the hostname.

Do not stop at DNS resolution alone. A subdomain can resolve successfully and still be vulnerable if the target service is orphaned. Equally, an inactive host can look harmless if monitoring only checks for NXDOMAIN, while the underlying delegated service remains claimable. The better test is to correlate DNS, service ownership, and provider state across the full estate.

The DNS Security Guide is directly relevant here because the failure mode is rooted in stale DNS delegation, and DNS logging, zone hygiene, and record lifecycle control are what let you see it early.

What a strong prevention control set looks like

Prevention is strongest when DNS changes and service decommissioning are treated as one workflow. When a service is retired, the record should be removed at the same time, or ownership should be explicitly transferred to the replacement service before cutover completes. This avoids the common gap where the application is gone but the hostname remains published and reclaimable.

Continuous monitoring matters because takeover risk is often created later, not only during initial setup. Watch for abandoned CNAMEs, unexpected edits to DNS, changes in cloud or SaaS binding, and new records that point to services no longer under active ownership. If your organisation uses external providers heavily, the real control is not just record cleanup, but a repeatable process that proves every public hostname still maps to a live, owned destination.

Good DNS hygiene also belongs in the broader control set for internet-facing assets, so a host that disappears from one inventory cannot silently remain reachable through another. That is why external attack surface review, DNS monitoring, and service deprovisioning need to be connected operationally, not managed by separate teams with different handoffs.

Risk and Threat Considerations

subdomain takeover is dangerous because a forgotten hostname can preserve brand trust while the underlying service is no longer yours. An attacker who claims that target can host content under your domain, capture traffic intended for you, or use the trusted subdomain for phishing, malware delivery, or credential harvesting.

Failure mechanism: A DNS record continues to point at a third-party service after the original resource has been deleted, released, or abandoned, leaving the hostname available for registration or rebinding by an outside party.

Impact: The attacker inherits a trusted internet-facing name under your domain, which can create reputational damage, user deception, and downstream compromise if the hostname is used in links, OAuth flows, or embedded resources.

Practitioner Guidance

What to verify: For every public subdomain, verify the live provider binding, not just DNS resolution. If the hostname is meant to be inactive, remove the record instead of leaving a harmless-looking CNAME behind.

What to prioritise: Start with records that point to deprovisioned SaaS, cloud hosting, or temporary environments, because those are the most common takeover candidates and the easiest to miss during decommissioning.

Common mistake: Treating a passing DNS lookup as proof of safety. A record can resolve cleanly and still be takeover-prone if the target service has been abandoned.

Practitioner takeaway: The best prevention test is a lifecycle test, not a point-in-time scan, because takeover risk appears when DNS ownership and service ownership drift apart.

Related resources from NHI Mgmt Group

• How do you test LDAP injection prevention?
• What are the key subdomain takeover prevention best practices?
• How do you test SQL injection prevention?
• What are common mistakes with subdomain takeover prevention?