The Ghost Subdomain Problem: 77,000+ Forgotten DNS Records Across the Cloudflare Radar Top 100 Domains

Subdomains are easy to create. A developer needs staging for a sprint, marketing launches a short campaign microsite, and QA mirrors production to reproduce a bug. The problem is not creation. It's the cleanup that often doesn't happen.

Many of these environments are never formally decommissioned and remain in DNS, continuing to resolve publicly beyond their intended use.

As part of our ongoing DNS security research at DNSAudit, we wanted to measure how much of this externally resolving non-production infrastructure exists across major global brands.

We performed a structured scan of domains listed in the Cloudflare Radar Top 100 domains using our experimental DNS Security API, focusing specifically on subdomains that actively resolve to public IP addresses.

We intentionally looked beyond standard records like www and mail.

Data was collected during the first days of February 2026 as a single measurement window to ensure consistency across domains. As a point-in-time measurement, results may vary as DNS configurations change.

To move beyond assumptions, we needed a structured way to measure what is actually exposed.

How We Conducted the Research

We used a structured two-step approach to avoid inflated or speculative numbers.

1. Massive Enumeration

We tested 3,649,938 potential subdomains across 100 major domains using our subdomain enumeration engine to actively enumerate publicly resolvable records.

These were not random guesses. The list combined wordlists, naming patterns, and real-world infrastructure conventions commonly seen in enterprise environments.

2. A-Record Validation

We only counted subdomains that resolved to a public IP address.

If a subdomain did not have a live A record pointing to public infrastructure, it was excluded.

We were not analyzing private DNS zones. We were not inferring risk from passive data. We were measuring subdomains that resolve to publicly reachable IP addresses.

Important Methodology Note

This research does not imply that the identified subdomains are vulnerable or compromised.

"Forgotten" in this context refers to likely non-production environments based on naming indicators such as dev, staging, qa, test, old, or sandbox. The classification is naming-pattern-based and does not imply vulnerability.

All data was collected exclusively through publicly accessible DNS resolution, without authentication, application interaction, or attempts to access underlying services.

With that scope defined, here's how the dataset narrowed once we applied those filters.

The Numbers

Here is how the funnel narrowed:

Total Checked: 3,649,938 subdomains.

Resolved Publicly: 2,585,395 (70.8% resolution rate).

Currently Live: 1,365,643.

Identified "Ghost" Records: 77,053 (~3% of resolved subdomains).

Note: "Currently Live" refers to subdomains that resolved publicly and returned responsive endpoints during validation.

Roughly 3% of all resolved subdomains contained non-production naming indicators. The distribution was not uniform. Some domains exposed only a small number of non-production records, while others exposed several thousand.

In simple terms, for every 33 publicly visible subdomains at a major company, at least one appears to be a development, testing, or legacy environment.

At scale, that becomes meaningful.

The percentages help, but the progression becomes easier to understand when viewed as a funnel.

A Simple Visualization of the Funnel

The dataset narrows quickly once you move from raw enumeration to what is actually live and exposed. Out of millions of potential subdomains tested, over two million resolve publicly. More than a million are currently live. And within that live surface, tens of thousands appear to be legacy or non-production environments.

Here's what that progression looks like visually:

That progression reflects something specific about how the data was collected.

Why Enumeration Matters More Than Passive Data

A lot of teams rely on passive DNS feeds, certificate transparency logs, or internal asset inventories to understand what's exposed. Those sources are valuable, but they only tell part of the story.

Certificate transparency will only show you subdomains that have had certificates issued. Passive DNS depends on what has been observed historically. And internal inventories assume that everything has been properly documented in the first place.

In large organizations, that assumption rarely holds up. Active enumeration asks a much simpler question: what is actually resolving right now?

If a subdomain returns a live A record pointing to a public IP, that infrastructure is reachable. It does not matter whether it is documented, remembered, or intended to be there.

That gap between "what should exist" and "what currently resolves" is often where undocumented infrastructure is discovered.

This distinction matters operationally.

Why This Is a Blue Team Headache

Security teams usually have decent visibility into their core assets. The main domains, production APIs, and customer-facing apps are monitored, logged, and reviewed regularly.

The problem is everything around the edges.

Attackers rarely go straight for the flagship property. They look for the older staging site that never got hardened, the QA endpoint that still resolves, or the forgotten microsite sitting behind a weak configuration.

That is what these 77,000+ subdomains represent. Not guaranteed vulnerabilities, but infrastructure that is far less likely to receive the same scrutiny as production systems.

In practice, this tends to fall into three recurring categories:

1. Staging Is Not Production

We observed thousands of records like:

dev-business.*

qa-bedrock.dev.*

dev-app.corp.*

api.qa-kroger.*

In many organizations, staging mirrors application logic but not security hardening. WAF rules, rate limits, logging standards, and patch cycles often differ.

Even if the environment itself is not business-critical, it may expose:

• Internal APIs
• Authentication flows
• Debug endpoints
• Misconfigured services

All of which expands the attack surface.

2. The Long-Lived Ghost

Some developer-labeled subdomains have been resolving since 2014 and 2015.

Longevity does not automatically equal vulnerability. But a public-facing endpoint that persists for nearly a decade increases the probability of configuration drift, forgotten credentials, or outdated software stacks.

Aging infrastructure tends to escape modernization efforts.

3. The Dangling Record Risk

When a third-party SaaS platform is decommissioned, but DNS entries remain, organizations create dangling records.

In certain cases, an attacker can claim the abandoned resource and serve content under the company's trusted subdomain.

Subdomain takeover remains a recurring issue across large enterprises. Dangling DNS entries are often the root cause.

Stepping back, these patterns point to a broader visibility issue.

Wrapping Up

Most of the 77,000+ subdomains we identified are not the result of an active breach, but of incomplete asset visibility.

In modern cloud environments, subdomains are created faster than documentation processes can track. Without continuous enumeration and validation of resolving records, your external attack surface map will always lag behind reality.

70.8% of the tested subdomains resolved publicly. 77,053 of those match non-production naming indicators.

If you have not audited your DNS zones for active A records and non-production indicators recently, there is a strong chance your inventory is incomplete.

The starting point is knowing which subdomains currently resolve in your own zones. Continuous DNS enumeration makes that visibility measurable.

If you want to see how your own DNS footprint compares, you can run a free scan at DNSAudit.io and review which subdomains currently resolve publicly.