What Is a Subdomain Takeover? How to Check If Your Domain Is Vulnerable

CodexFuse Team · 2026-11-06T07:51:23.533Z · 27 min read min read

What Is a Subdomain Takeover? How to Check If Your Domain Is Vulnerable

If you are wondering what is a subdomain takeover, the short answer is that it happens when a DNS record on your domain still points at a cloud service or third-party resource you no longer use, and someone else claims that resource. Your domain still looks like yours, your DNS still resolves, and yet the content visitors see on that subdomain belongs to a stranger. Nothing was hacked in the usual sense: no password was stolen and no server was breached.

This guide is written for defenders auditing their own domains, and it follows the defender's self-audit angle that OWASP's testing guide recommends. You will learn the mental model in one paragraph, how attackers find these records, a five-step check you can run on your own domains today, and the fix order that closes the hole without opening a new one. Everything below was checked against the sources listed at the end on 6 November 2026.

A subdomain scanner is the fastest way to list the names hanging off your domain before you start checking them one by one. If any of the DNS terms here are new to you, our DNS beginner guide explains records, zones, and resolvers first. The rest of this guide assumes you can open your registrar or DNS dashboard and read a record list.

What Is a Subdomain Takeover?

A subdomain takeover is what happens when a subdomain's DNS record points to an external service that has been deleted or deprovisioned, and an attacker claims that service under their own account. OWASP's testing guide puts it plainly: a successful takeover lets an adversary claim and take control of the victim's subdomain. Microsoft's guidance calls it a common, high-severity threat for organisations that regularly create and delete resources, and the AWS security blog describes the same shape: you delete the underlying resource, and a threat actor creates a new resource with the same name to take advantage of the DNS records still pointing at it.

The whole attack is a three-step chain, and every step is an ordinary administrative event until the last one. The table below shows the chain with a concrete example, because the fix follows directly from seeing which link you control.

The name for the leftover record in step 2 is a dangling DNS record, and the next section explains it in detail. The key point is that the victim keeps their domain and their DNS the whole time. Only the resource the DNS points to changes hands, which is why this is also called subdomain hijacking in MITRE ATT&CK, where it is listed as technique T1584.001, Compromise Infrastructure: Domains.

What Is a Dangling DNS Record?

A dangling DNS record is a DNS entry that points to an external resource that no longer exists or has been deprovisioned. OWASP's wording is that the entry points to an external resource that no longer exists, for example a CNAME record pointing to a GitHub Pages site that the owner deleted, which still resolves even though the underlying resource is unclaimed.

Microsoft calls such records dangling DNS entries and notes that CNAME records are especially vulnerable. AWS describes the same moment: when a resource like an S3 bucket is deleted but the DNS record pointing to it is left behind, that record becomes dangling.

Dangling records are routine, not exotic. A marketing campaign ends, a proof of concept is torn down, a vendor contract lapses, a staging environment is deleted after launch, and the infrastructure disappears while the DNS entry stays.

Researchers at Silent Push reported finding 1.1 million CNAME records potentially vulnerable to takeover in May 2022, which gives a sense of scale, though that is their research figure and not a current vendor statistic. The record itself is harmless while the resource still exists; it becomes a hole the day the resource is gone and the record is not.

One more distinction matters before you start checking. A dangling record is the condition, and a takeover is the event: the record dangles first, and it is only taken over when someone claims the resource it points to. That is why the check in this guide has two halves, finding the dangling records and then confirming whether the resource behind each one is still yours.

Which DNS Records Can Be Taken Over?

A CNAME takeover is the most common form, and it is the one the examples in this guide use. A CNAME record aliases a subdomain to a cloud or SaaS hostname, the app or bucket is deleted, the CNAME stays, and anyone who creates a new resource with the same name on that platform receives the subdomain's traffic. OWASP's cheat sheet uses exactly this example: blog.example.com pointing at example-blog.herokuapp.com, the Heroku app decommissioned, the CNAME forgotten, and a new Heroku app named example-blog claiming the hostname.

CNAME records are not the only vector, and a serious check looks at the other three record types in the table below. NS records carry the highest impact, because a successful NS takeover can hand over control of the whole DNS zone for that subdomain. MX records matter for a different reason: an attacker who claims a retired mail service can receive mail for the subdomain, including password resets and email-based verification messages.

Wildcard records deserve a special mention, because a wildcard CNAME such as *.example.com pointing at a platform where you never registered the wildcard can let an attacker claim any subdomain they want. OWASP's cheat sheet advises restricting wildcard DNS, scoping it narrowly, and monitoring certificate transparency logs for unexpected certificates. If you use wildcards, treat them as a standing item on your check list rather than a one-time setup.

How Attackers Find Vulnerable Subdomains

Understanding the attacker's view is what makes your own check effective, and OWASP's testing guide describes it in three phases: subdomain enumeration, automated fingerprint-based detection, and manual validation. First they list subdomains, from zone inventories, wordlists, and certificate transparency logs.

Then they resolve each name and keep only the ones with CNAME, NS, or MX records, the types most commonly left dangling. Then they compare each subdomain's HTTP response against known unclaimed-resource error strings, maintained by the community project can-i-take-over-xyz, using tools OWASP names such as subzy and nuclei with takeover templates.

Certificate transparency logs are the part most domain owners underestimate. Every publicly trusted TLS certificate must be published to a certificate transparency log before browsers accept it, and the certificate lists every hostname it covers, so the logs are a public, permanent record of subdomains that ever had HTTPS.

The free search interface crt.sh, run by Sectigo, answers a query such as https://crt.sh/?q=%.example.com, where the percent sign is the wildcard, and a JSON endpoint serves the same data for scripting. The logs are append-only, so a query returns history rather than only what is live today, and a name that never had its own certificate will not appear.

The automated tools produce false positives, so the last phase is manual validation: dig the CNAME, curl the subdomain, and compare the response with the expected fingerprint. Brandefense's lab-tested playbook from 31 October 2026 runs the same idea from the outside in six steps: list every name, find the CNAMEs, resolve each target, read the page and match platform error strings, confirm the owner, and check NS and MX too. The AWS security blog adds that its incident-response team observes threat actors actively scanning public CNAME records, so this is not a theoretical exercise.

How to Check Subdomain Takeover in 5 Steps

How to check subdomain takeover risk on your own domains comes down to the five steps below, and a subdomain takeover check is worth running on a schedule, not once. The commands are read-only DNS lookups: they ask questions about your zone and never edit it.

CodexFuse does not offer a subdomain takeover checker, so this check is manual, and the tool links in this guide show you records rather than proving exploitability. Run the steps in order, because each one narrows the list for the next.

1. Inventory every subdomain. Export your DNS zone file, then cross-check it against certificate transparency logs at crt.sh for names nobody on your team remembers. Anything in the logs that is not in your zone file is a subdomain you have lost track of, and anything in your zone file that nobody can explain is a candidate for the next step.
2. Follow every CNAME chain. For each subdomain, run dig with the CNAME type and keep following the chain until no CNAME is left, then check the A record. Also run dig for the NS and MX records of the same name. A DNS lookup tool shows the same records in a browser if you prefer not to use the command line, but the dig output is what you will compare against fingerprints later.
3. Resolve each target and read the answer. When the target of a CNAME returns NXDOMAIN, SERVFAIL, or REFUSED, that is a lead: the resource the record points to does not answer. Then open the subdomain in a browser or curl it and match what you see against the known unclaimed-resource error strings in the next section.
4. Confirm ownership, and remember that a record that still resolves is not proof that it is safe. Check in the platform's own dashboard that the target resource is in your account. Once a resource has already been claimed by an attacker, DNS resolution succeeds, to the attacker's resource, so a record that resolves can still be taken over. Only the inventory comparison or the platform's error page reveals it.
5. Fix in the right order and verify. Remove the DNS record, or re-point it to something you control, wait out the TTL, and only then delete or reclaim the resource. Afterwards verify that the name no longer resolves to the old target and re-scan the whole zone, because one dangling record usually means there are more.

The commands for step 2 are the same on every system, and security.gov.uk publishes exactly this procedure for government domains: dig the CNAME with the +short flag, follow the chain, then dig the A record of the final host, where NXDOMAIN means the page does not exist on the third-party service. On Linux, dig is part of dnsutils on Debian and Ubuntu or bind-utils on Red Hat systems, and it is not installed by default on most systems. On Windows and macOS, nslookup is built in and answers the same questions, and the host command gives a minimal one-line answer on Linux and macOS.

# TTL wait times and the age of the best-known cases, computed 6 November 2026
# TTL seconds -> minutes: 300 -> 5.0, 600 -> 10.0, 1800 -> 30.0, 3600 -> 60.0
# Zenly dig TTL: 255 seconds -> 4.25 minutes
# Days from each case to 6 November 2026:
# Detectify 2014-10-21 -> 4399 days (12.0 years)
# Uber 2017-04-07 -> 3500 days (9.6 years)
# Roblox 2018-04-09 -> 3133 days (8.6 years)
# Starbucks 2019-08-01 -> 2654 days (7.3 years)
# Zenly 2022-02-08 -> 1732 days (4.7 years)
# GitLab 2024-05-28 -> 892 days (2.4 years)
for ttl in [300, 600, 1800, 3600]:
    print(ttl, 'seconds =', ttl / 60, 'minutes')
print('Zenly TTL 255 seconds =', 255 / 60, 'minutes')
from datetime import date
today = date(2026, 11, 6)
for label, d in [('Detectify', date(2014, 10, 21)), ('Uber', date(2017, 4, 7)),
                 ('Roblox', date(2018, 4, 9)), ('Starbucks', date(2019, 8, 1)),
                 ('Zenly', date(2022, 2, 8)), ('GitLab', date(2024, 5, 28))]:
    print(label, (today - d).days, 'days')
# Expected output:
# 300 seconds = 5.0 minutes
# 600 seconds = 10.0 minutes
# 1800 seconds = 30.0 minutes
# 3600 seconds = 60.0 minutes
# Zenly TTL 255 seconds = 4.25 minutes
# Detectify 4399 days
# Uber 3500 days
# Roblox 3133 days
# Starbucks 2654 days
# Zenly 1732 days
# GitLab 892 days

Running it prints 300 seconds = 5.0 minutes, 600 seconds = 10.0 minutes, 1800 seconds = 30.0 minutes, 3600 seconds = 60.0 minutes, Zenly TTL 255 seconds = 4.25 minutes, and the day counts 4399, 3500, 3133, 2654, 1732, and 892. The TTL figures matter because OWASP gives 300 to 3600 seconds as the typical TTL range, and AWS notes that a TTL of 3600 means cached resolvers may serve the old record for up to one hour. The day counts matter because they show how long this vulnerability class has been known, and the cases in the next sections are dated so you can judge which provider behaviours have since changed.

What the Error Pages Tell You

When a subdomain points at a service that no longer claims it, the service usually says so in its error page, and those error strings are the fingerprints that automated checkers match. The table below reproduces the eight fingerprints from OWASP's cheat sheet, which warns that the table is a snapshot and that providers change their behaviour, so always cross-check the current status against the can-i-take-over-xyz project before concluding anything. A matching fingerprint is strong evidence that the resource is unclaimed; a page that looks normal is not evidence of safety, because a claimed resource serves a live page.

Matching a fingerprint is only half the job, and the other half is the ownership check from step 4. The S3 fingerprint is a good example of why: NoSuchBucket means the bucket name is free, and on S3 the global namespace means anyone in the world can create a bucket with that exact name. AWS has since launched account regional namespaces for S3 in March 2026, which scope buckets to one account, but existing buckets cannot be migrated and the global namespace is still the default, so do not treat the launch as a fix for records that already dangle.

Real Subdomain Takeover Examples

The cases below are all disclosed bug-bounty reports or published research, dated so you can see what has changed since. The Uber and Roblox cases are historical, and the provider behaviour they describe has since changed, so do not present the same path as working today. The table gives the shape of each case; the paragraphs after it give the detail that matters for a defender.

Detectify's write-up of 21 October 2014 is the first widely reported wave, and it is still the clearest statement of the problem. The researchers identified at least 17 service providers that did not handle subdomain ownership verification properly, including Heroku, GitHub, Bitbucket, Squarespace, Shopify, Desk, and Tumblr, and at least 200 affected organisations, in many cases NASDAQ-listed companies with top-100 Alexa-ranked domains.

Their update of 20 February 2017 records that they had by then identified more than 100 different ways to be vulnerable to a domain takeover. That was 4,399 days before this article, and the vulnerability class is still among the most reported findings in bug bounty programs, according to OWASP's cheat sheet.

The Roblox case shows why the impact can be critical even when the takeover itself is simple. The subdomain devrel.roblox.com pointed at a HubSpot service that was no longer in use, and the researcher reported on 9 April 2018 that cookies were scoped to all subdomains of roblox.com, so stealing a cookie from the taken-over subdomain meant using it across the whole domain.

The report was rated Critical at 9.4, and the researcher also showed that the subdomain was whitelisted to make cross-origin requests to chat.roblox.com, which meant reading chats between other users. That was 3,133 days ago, and HubSpot has since closed the path, which is exactly why dates matter when you read old reports.

The Uber case is the same lesson on the CloudFront side. The subdomain saostatic.uber.com pointed at an unclaimed CloudFront distribution, and the researcher reported on 7 April 2017 that the setup leaked high-value session cookies to the taken-over subdomain, leading to a full authentication bypass.

The report was rated Critical at 9.3, and the bounty was not disclosed. AWS has since closed direct CNAME claims on CloudFront: a certificate is now required, so the 2017 path does not work the same way today. That was 3,500 days ago.

The Starbucks case is the most useful template for a defender's own check, because the researcher wrote down the method. The subdomain datacafe-cert.starbucks.com pointed at an unclaimed Azure web service, and the researcher reported on 1 August 2019 that the method was subdomain enumeration, then checking for CNAME records pointing at azurewebsites.net, then running dig on each CNAME, where an NXDOMAIN answer meant the subdomain could usually be taken over.

The report was rated High at 7.5, and the bounty was not disclosed. That was 2,654 days ago.

The Zenly case is the cleanest single subdomain takeover example in the public record, because the whole proof fits in a few lines. The researcher found that brand.zen.ly showed a Not Found error and that its CNAME pointed at brandpad.io, then registered at Brandpad and took the subdomain over.

The dig output in the disclosed report reads brand.zen.ly. 255 IN CNAME brandpad.io., and the TTL of 255 seconds is 4.25 minutes. The report was submitted on 8 February 2022, triaged the next day, and disclosed on 17 February 2022, and Zenly resolved it by removing the DNS entry and paying a bounty under its program. That was 1,732 days ago.

The GitLab case is the most recent of the six, and it shows the class is still alive. The subdomain docsdev.gitlab.com pointed at a dangling GitLab Pages custom domain, and the report of 28 May 2024 was rated Low at 3.5, patched in GitLab 17.1.2, and assigned CVE-2024-5528.

That was 892 days ago. The low severity is instructive too: not every dangling record carries the same impact, and severity follows what the subdomain can actually do, which cookies it can read, and which trust lists include it.

What Happens After a Takeover?

The first thing an attacker gains is a trusted address. Content served from your subdomain inherits your domain's reputation, so a phishing page on support.example.com looks far more convincing than the same page on a random domain, and email from the subdomain passes the sniff test for many recipients.

HTTPS does not protect you here, because the attacker can apply for and receive a valid TLS certificate for the subdomain they control, and the browser then shows the padlock with no warning. Microsoft's guidance states this directly: a threat actor can use the hijacked subdomain to apply for and receive a valid SSL certificate, and valid certificates grant them access to secure cookies.

The second thing at stake is the trust your own systems extend to the subdomain. Session cookies scoped to the parent domain, such as .example.com, are sent to every subdomain, including a taken-over one, which is how the Roblox case turned a simple takeover into a possible account takeover.

Content security policies and CORS rules that trust *.example.com suddenly trust the attacker's origin, and OAuth and single-sign-on flows that whitelist the subdomain as a redirect URI can leak authorisation codes. If an MX record is involved, the attacker can also receive mail for the subdomain, including password resets and email-based verification messages.

The third cost is the quiet one: you may not notice for months. The takeover leaves no trace in your own systems, because nothing inside your infrastructure changed, and the DNS record still resolves.

Detectify's original write-up warned that the domain owner will not notice and that the attacker leaves no traces for the owner to find, and that is still true. The practical consequence is that monitoring matters as much as the one-time check: watch certificate transparency logs for unexpected certificates on your subdomains, and re-run the five-step check whenever a service is retired.

How to Fix a Dangling DNS Record

The fix has a strict order, and getting the order wrong is the most common mistake in this whole topic. Delete the DNS record first, or re-point it to a resource you control, and wait for the TTL to expire before you delete the resource itself.

AWS states the principle plainly: always delete the DNS first, wait for the TTL to expire, then delete the resource. Deleting the resource first is what creates the takeover window in the first place, so reversing the order after you find a dangling record would repeat the original error.

The wait matters because DNS resolvers cache records for the TTL, and the table below converts the typical TTL values OWASP cites into waiting times. A TTL of 3600 seconds means cached resolvers may serve the old record for up to one hour, so verify after the wait rather than immediately after the delete. If the subdomain points at a server you still own and control, for example when you point a domain to a VPS, re-pointing the record at that server is safer than deleting it outright, because the name keeps resolving to something you control.

If the subdomain has already been taken over, deleting the DNS record still cuts off your visitors, because their browsers stop resolving the name to the attacker's resource. Report the attacker's account to the platform's abuse team, then check certificate transparency logs for certificates issued during the takeover window and request revocation, assess whether parent-scoped cookies, OAuth redirect URIs, or email were exposed, and scan every zone you own for other dangling records. OWASP's cheat sheet and the AWS blog both treat the incident response as part of the fix, not an afterthought.

How to Prevent Subdomain Takeover

Prevention is mostly process, and the single most effective control is a decommissioning checklist that includes removing the DNS entry as a required step. Microsoft's guidance and OWASP's cheat sheet both say the same thing: put DNS removal on the checklist for every service retirement, add delete locks to resources that have custom DNS entries, and keep a documented mapping of every DNS record to its resource, its owning team, and its expected retirement date. The Zenly fix shows the pattern in miniature: the team removed the DNS entry as soon as the report arrived.

Automation catches what checklists miss. OWASP names scheduled scans, CI/CD teardown checks that verify DNS removal when a deployment is destroyed, and alerts on new CNAME records and on provider error pages.

The tools it names are dnsReaper, with more than 40 service fingerprints, nuclei with takeover templates, and the can-i-take-over-xyz fingerprint list. AWS offers its own detection path through a Config custom rule that monitors Route 53 CNAMEs against the account's inventory and flags non-compliant records, with findings routed to Security Hub or SNS, and it has published an open-source reference implementation for dangling DNS detection.

Provider verification features close specific paths, and they are worth turning on where they exist. Azure App Service supports a TXT record of the form asuid.{subdomain} carrying the domain verification ID, so no other Azure subscription can validate and take over the custom domain, though it does not stop someone creating an app with the same name.

GitHub Pages supports domain verification through a _github-pages-challenge TXT record, which stops other users publishing to the verified domain and its immediate subdomains. Azure also offers DNS alias records that couple the record's lifecycle to the resource, so deleting the resource empties the record set, and Microsoft Defender for App Service includes dangling DNS detection when a site is decommissioned without removing its custom domain. If the subdomain points at a server you still run, the same inventory discipline applies: our VPS hosting guide explains the hosting side, and the DNS side is the same record-to-resource mapping.

The last control is limiting the blast radius, so that a takeover that does happen costs less. Do not scope session cookies to the parent domain unless you must, and prefer the __Host- prefix where you can.

Do not put *.example.com in content security policies, CORS allowlists, or OAuth redirect URIs; use exact-match redirect URIs instead. Restrict wildcard DNS, and combine it with an allowlisting reverse proxy where the architecture allows it. None of these controls stops a takeover, and all of them reduce what a takeover can do.

Subdomain Takeover vs Domain Takeover vs Account Takeover

A subdomain takeover is not a domain takeover, and it is not an account takeover, and the three get confused constantly in search results and in incident reports. In a subdomain takeover, you keep your domain registration and your DNS, and only the resource the DNS points to changes hands.

In a domain takeover, you lose the registration itself, usually because the domain expired and someone else registered it, and then they control the whole domain including its DNS. In an account takeover, someone gains access to one of your accounts, such as your registrar or cloud account, and acts as you.

The confusion is understandable, because one can lead to another. The Roblox case is the clearest example: a subdomain takeover let the researcher steal cookies scoped to the parent domain, which could then be used to take over accounts on other subdomains.

That is a consequence of the takeover, not the same thing, and the fix is different for each: a subdomain takeover is fixed by removing the DNS record, a domain takeover is fixed by renewing and reclaiming the registration, and an account takeover is fixed by rotating credentials and sessions. Naming the right problem is what gets you the right fix.

What the Cloud Providers Say About It

Microsoft publishes a dedicated Learn page on preventing dangling DNS entries, with a creation-to-deprovisioning-to-takeover walkthrough using greatapp.contoso.com, a Get-DanglingDnsRecords PowerShell tool, and guidance on DNS alias records, verification TXT records, and Defender for App Service detection. AWS published a security blog post in which its incident-response team says it observes threat actors actively scanning public CNAME records, and the post names S3, CloudFront, and Elastic Beanstalk as claimable namespaces while noting that VPC, EC2, and private zones are not subject to the same risk. GitHub's position is the domain verification TXT record described above, and Cloudflare's is custom-hostname verification through Cloudflare for SaaS, which validates ownership before a hostname can be claimed.

Two gaps are worth stating plainly, because a guide that pretends every provider has a page on this would be inventing coverage. No official Google Cloud documentation page on subdomain takeover or dangling DNS was found in the research for this article, and no dedicated Cloudflare documentation page on dangling DNS was found either.

Third-party material exists for both, including a demonstrated Cloud DNS NS-delegation takeover, but the article does not cite provider documentation that does not exist. The OWASP cheat sheet and testing guide remain the provider-neutral references, and they are the sources the prevention checklist above is built on.

Sources

All sources were fetched on 6 November 2026.

• OWASP Web Security Testing Guide, Test Subdomain Takeover (WSTG-CONF-10) — https://owasp.github.io/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management/10-Subdomain_Takeover — the defender self-audit angle, the three-phase detection method, and the NS-takeover impact
• OWASP Cheat Sheet Series, Subdomain Takeover Prevention — https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html — the service fingerprint table, the fix order, and the prevention checklist
• Microsoft Learn, Prevent dangling DNS entries and avoid subdomain takeover — https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover — the dangling DNS definition, the valid-certificate warning, and Azure mitigation features
• AWS Security Blog, Threat tactic spotlight: Subdomain takeover — https://aws.amazon.com/blogs/security/threat-tactic-spotlight-subdomain-takeover/ — the takeover definition, the DNS-first fix order, AWS Config detection, and S3 regional namespaces of March 2026
• Brandefense, Subdomain Takeover: How to Find and Fix It — https://brandefense.io/blog/subdomain-takeover-detection/ — the lab-tested outside-in check of 31 October 2026
• security.gov.uk, Potential subdomain takeover — https://www.security.gov.uk/services-resources/cyber-and-domains-protection/domain-and-vulnerability-knowledge-base/potential-subdomain-takeover/ — the dig chain-following procedure
• Detectify Labs, Hostile subdomain takeover using Heroku/Github/Desk — https://labs.detectify.com/writeups/hostile-subdomain-takeover-using-heroku-github-desk-more/ — 21 October 2014, at least 17 providers and 200 organisations, updated 20 February 2017 to more than 100 takeover methods
• HackerOne report 1474784, Subdomain Takeover of brand.zen.ly — https://hackerone.com/reports/1474784 — submitted 8 February 2022, disclosed 17 February 2022, the dig output brand.zen.ly. 255 IN CNAME brandpad.io.
• Top 3 subdomain takeover reports, ranked by HackerOne upvotes — https://readmedium.com/top-3-subdomain-takeovers-ea51ecd911fd — the Roblox, Starbucks, and Uber cases with severities 9.4, 7.5, and 9.3
• MITRE ATT&CK, technique T1584.001 Compromise Infrastructure: Domains — cited via the AWS Security Blog and the Brandefense playbook
• crt.sh certificate transparency search — https://crt.sh/ — the %.example.com wildcard query and the JSON endpoint, corroborated across three explainers and the Brandefense and dev.to guides
• Silent Push research on dangling CNAME records, May 2022 — the 1.1 million potentially vulnerable CNAMEs figure, via the Infocon mirror

Frequently Asked Questions

Is a dangling CNAME always exploitable?

No. A dangling record is only exploitable if the platform lets another account claim the name or domain the record points to.

AWS closed direct CNAME claims on CloudFront in 2022 by requiring a certificate, and a Vercel authorisation check blocked a claim in a disclosed 2022 report. Check the current behaviour against can-i-take-over-xyz before concluding anything.

Does HTTPS protect you from a subdomain takeover?

No. HTTPS proves that the connection to the subdomain is encrypted, not that the right person controls the subdomain. An attacker who takes over a subdomain can obtain their own valid TLS certificate for it, and the browser shows the padlock with no warning.

What should I do first if I find a dangling record?

Remove the record, or re-point it to a resource you control. Then wait out the TTL, which is typically 300 to 3600 seconds, and only then delete the resource. After that, verify the name no longer resolves to the old target and re-scan the whole zone.

What is the difference between a subdomain takeover and a domain takeover?

In a subdomain takeover you keep your domain and your DNS, and only the resource the DNS points to changes hands. In a domain takeover you lose the registration itself, usually because the domain expired and someone else registered it, and then they control the whole domain including its DNS.

How often should I check my subdomains?

Run the five-step check whenever a service is retired, and re-run it on a schedule, at least quarterly for a small domain and more often if you create and delete resources frequently. Also monitor certificate transparency logs for unexpected certificates on your subdomains, because an unexpected certificate is a strong sign a takeover already happened.