Subdomain Takeover Prevention Checklist for DNS and Cloud Teams

Overview

This guide gives you a reusable checklist for subdomain takeover prevention. The goal is not to create a one-time project. It is to build a habit: inventory hostnames, verify ownership of what they point to, identify orphaned records, and remove or remediate anything that no longer has a valid backing resource.

At a practical level, a takeover risk often appears when all three conditions are true:

• A public DNS record exists for a subdomain.
• That record points to a third-party or cloud-managed endpoint.
• The underlying resource is deleted, unclaimed, or reassigned in a way that another party could potentially claim.

That does not mean every stale DNS record is exploitable, and it does not mean every NXDOMAIN or service error leads to takeover. The safe operating model is simpler: treat stale external mappings as security debt until they are confirmed safe or removed.

For most teams, a durable DNS security audit has five phases:

1. Inventory all public subdomains and record types.
2. Classify which records point to third-party platforms, cloud services, and internally managed infrastructure.
3. Validate whether the destination resource still exists and is owned by your organization.
4. Remediate by deleting, repointing, reclaiming, or restricting risky records.
5. Operationalize the process so it runs after changes, not only after incidents.

If you also maintain ownership records and registrar data, pair this process with a broader domain governance review. For that, see WHOIS, RDAP, and Domain Ownership Validation: What Still Works.

Checklist by scenario

Use this section as the core audit worksheet. Start with a full export from your DNS provider, then work through each scenario.

1. Baseline inventory of public DNS records

• Export all public zones and records, including A, AAAA, CNAME, MX, TXT, SRV, NS, and wildcard entries.
• List every subdomain that resolves publicly, even if it is rarely used.
• Mark business owner, technical owner, environment, and purpose for each hostname.
• Flag records with no clear owner or no documented application dependency.
• Separate externally facing production records from test, staging, campaign, and legacy records.
• Identify records managed outside your central DNS workflow, such as delegated subzones or ad hoc vendor-managed entries.

This first pass often surfaces the largest risk: subdomains that still exist in DNS even though nobody can explain why.

2. CNAME records pointing to third-party services

• Review every CNAME that points to a vendor domain, cloud edge endpoint, app hosting platform, CDN, help desk, form tool, or marketing service.
• Confirm the target service is still in use and the account is still active.
• Verify the exact hostname is registered or bound inside the vendor account your team controls.
• Check whether the vendor requires explicit domain claiming, token validation, or certificate validation for custom hostnames.
• Look for service responses that suggest an unconfigured, unclaimed, or missing tenant.
• Delete records for retired services instead of leaving them in place "just in case."

External CNAMEs deserve special attention because they are easy to forget after a migration. This is the classic place to run a dangling DNS record check.

3. Cloud resources that were renamed, deleted, or recreated

• Review application endpoints tied to storage, static site hosting, load balancers, API gateways, app services, and managed front doors.
• Compare DNS records against live cloud inventory, not just IaC state or old runbooks.
• Confirm the named resource still exists in the correct account, subscription, or project.
• Check for environments where resources were deleted but DNS was preserved to avoid TTL delays and then never cleaned up.
• After replatforming, confirm old hostnames were repointed or retired rather than left attached to dead targets.

One common failure pattern is partial decommissioning: the workload is gone, but DNS remains because it was managed by another team.

4. Subdomains used for campaigns, support tools, or temporary launches

• Audit one-off hostnames created for events, microsites, product launches, migrations, and partner integrations.
• Set an explicit expiration review date for each temporary hostname.
• Confirm whether campaign teams can request DNS directly without central security review.
• Remove records as part of launch closure, not months later during general cleanup.
• Search ticketing systems and change logs for old requests that may not have been reversed.

Temporary subdomains create disproportionate risk because they are created quickly and rarely revisited.

5. Delegated subzones and split responsibilities

• List any delegated subzones managed by business units, subsidiaries, regional teams, or external partners.
• Verify who controls the nameservers and how changes are approved.
• Confirm the delegated zone is still required and not abandoned.
• Check whether your security review process includes records beneath delegated namespaces.
• Require the delegated owner to maintain the same retirement and validation standards as the parent domain team.

A secure parent zone does not guarantee secure delegated subzones. Ownership gaps often hide there.

6. Wildcard DNS and catch-all routing

• Document any wildcard records and the systems behind them.
• Confirm wildcard routing does not expose unused hostnames to a platform that can serve unexpected content.
• Review whether wildcard coverage masks stale application paths or retired environments.
• Test a sample of nonexistent subdomains to understand how the platform responds.
• Limit wildcard use where exact hostnames would be safer and easier to audit.

Wildcards do not automatically create takeover conditions, but they complicate attribution and can obscure which names are truly intentional.

7. Certificate and TLS dependencies

• Confirm each active subdomain has a certificate lifecycle that matches the intended platform.
• Review whether old custom domains remain configured solely because certificates auto-renew.
• Check for hostnames still present in certificate management tools even though the service was retired.
• Make sure certificate validation records in DNS are still needed.

Certificate artifacts can keep forgotten hostnames alive longer than teams expect. As part of a broader domain validation API or DNS validation tool workflow, certificate checks can help surface names that still look operational but no longer serve a business purpose.

8. SaaS offboarding and vendor changes

• When canceling a vendor, include DNS cleanup in the offboarding checklist.
• Remove custom domains before or during account closure, not afterward.
• Verify that all verification tokens, redirect endpoints, and branded hostnames are retired.
• Track every hostname introduced by vendors in your vendor inventory.
• Require service owners to attest that customer-facing DNS mappings were removed.

Vendor transitions are one of the best times to run a full subdomain takeover checklist because ownership assumptions change quickly.

9. Continuous monitoring and validation

• Set up recurring scans for records pointing to known external service patterns.
• Alert on NXDOMAIN responses, parking responses, unconfigured custom domain messages, or changes in resolved targets.
• Monitor for newly added public records outside the approved change path.
• Retain historical snapshots of zone files so you can compare drift over time.
• Use validation tooling to cross-check DNS answers, HTTP responses, TLS state, and ownership metadata in one workflow.

A strong process does not rely on memory. It makes drift visible early.

What to double-check

After the main audit, pause on the details most likely to produce false confidence. These are the checks that catch records that look harmless at first glance.

Ownership versus reachability

A hostname resolving successfully does not prove you still control the destination. A live HTTP response, valid certificate, or clean DNS answer only confirms that something is there. It does not confirm that the backing service is still attached to your account. For each externally mapped subdomain, verify both:

• The DNS target resolves as expected.
• The underlying service binding or custom domain registration is still owned by your organization.

Service messages that imply reclaimability

If a hostname returns a generic setup page, an "unknown domain" message, or a prompt to configure a custom domain, treat that as a review trigger. Do not assume it is benign because the page is not serving attacker content. The question is whether someone else could claim that hostname on the provider.

Records created outside infrastructure-as-code

DNS often outlives the systems that created it. Check manually added console changes, registrar-managed records, emergency cutover entries, and vendor instructions followed outside normal deployment pipelines. The most fragile records are often the least documented.

Low-risk labels that still resolve publicly

Names like old, test, beta, staging, help, or promo may feel unimportant, but they are still part of your public namespace. Attackers do not limit themselves to production labels.

TTL and rollback assumptions

Teams sometimes delay cleanup because they want an easy rollback path. If that happens, define a short review window and owner. "We might need it later" is not a valid long-term reason to keep a risky external mapping in place.

Delegation boundaries

If another team says a hostname is "the vendor's problem" or "the subsidiary's problem," verify the control plane. The public brand impact remains yours if the subdomain is under your primary domain family.

Common mistakes

These mistakes show up repeatedly in DNS cleanup efforts and can turn an otherwise reasonable process into an incomplete one.

• Scanning only production apps. Many stale records live in staging, support, marketing, and regional environments.
• Treating NXDOMAIN as the only failure signal. Some takeover-prone situations still resolve normally in DNS.
• Assuming the application team removed DNS. App decommissioning and DNS cleanup are often owned by different groups.
• Ignoring vendor offboarding. If custom domains are part of the service, DNS retirement should be part of the contract exit workflow.
• Keeping unused records for convenience. Old aliases, campaign links, and fallback endpoints accumulate quickly and become hard to assess later.
• Relying on one data source. Zone files, cloud inventory, ticket history, and live endpoint behavior each reveal different problems.
• Missing delegated namespaces. Security reviews that stop at the parent zone leave blind spots.
• Failing to assign ownership. A hostname with no accountable owner tends to stay in DNS indefinitely.

If your team builds validation systems for other inputs as well, the pattern should feel familiar: prevention comes from explicit ownership, consistent checks, and low-friction review workflows. The same operational discipline appears in adjacent topics such as API Rate Limiting and Validation: How to Protect Verification Endpoints Without Breaking UX and GDPR and CCPA Considerations for Validation APIs.

When to revisit

Use this final section as your action plan. A subdomain takeover review is most useful when tied to change events, not just annual audits.

Revisit this checklist at these moments:

• Before seasonal planning cycles when teams retire campaigns, merge tools, or clean up budgets.
• When workflows or tools change including platform migrations, CDN changes, rebrands, and SaaS replacements.
• After application decommissioning, environment consolidation, or cloud account restructuring.
• After mergers, acquisitions, regional rollouts, or subsidiary domain integration.
• When a security review finds undocumented hostnames or inconsistent DNS ownership.
• Whenever a vendor requires new custom domain mappings or domain verification steps.

A practical operating rhythm looks like this:

1. Run a monthly automated inventory and flag new external mappings.
2. Run a quarterly manual review of public subdomains with owners.
3. Trigger an immediate review after vendor offboarding or infrastructure migrations.
4. Require DNS cleanup sign-off in every decommissioning checklist.
5. Keep a short remediation queue: delete unused records, reclaim valid ones, and document justified exceptions.

If you want this process to stick, make it easy to repeat. Keep a simple worksheet for each hostname: record type, target, owner, service status, verification method, last reviewed date, and action taken. That turns a one-time security exercise into a durable maintenance practice.

The core question to bring back each time is straightforward: Does this subdomain still point to an active resource that we intentionally control? If the answer is unclear, treat it as work to finish rather than risk to accept.