The Flaky Internet: 20 Million Domains That Only Sometimes Answer

Published 2026-08-20

The Flaky Internet: 20 Million Domains That Only Sometimes Answer

Most internet measurement studies treat reachability as binary. A domain either responds or it does not. That binary model is clean, publishable, and wrong for roughly one in twenty domains on the internet.

Our August 2026 census scanned 432,127,908 domains. Of those, 19,814,020 (4.6% of the total) produced results that were inconsistent across repeated attempts. They are not dead. They are not reliably alive. They are intermittent, and that distinction matters for any claim about internet security posture at scale.

This article explains how we handle that population, what the retry data reveals, and why collapsing the middle into either “pass” or “fail” produces measurement artefacts that propagate through every downstream conclusion.

The Measurement Problem

When you scan a domain, you are not measuring a static property. You are measuring a conversation: a DNS query, a TCP handshake, an HTTP exchange. Each step can fail independently, transiently, and for reasons entirely unrelated to the domain owner’s intentions. A resolver load spike, a BGP route flap, a CDN edge node restarting — none of these mean the domain is dead. None of them mean it is healthy either.

RFC 1034 and RFC 1035, the foundational DNS specifications, describe a system explicitly designed around retry and fallback. RFC 7230, the HTTP/1.1 specification, similarly acknowledges that connections may fail and be retried. The retry model is not a workaround: it is the intended behaviour of both protocol families. Any census that fires a single probe per domain and treats the result as definitive is not measuring the internet. It is measuring a single moment in a conversation that the internet’s own protocols expect to be retried.

ICANN’s domain lifecycle documentation further complicates the picture. Domains move through active, expired, redemption-period, and pending-delete states. A domain in redemption may resolve intermittently as registrar systems update. A recently reactivated domain may serve DNS before its HTTP stack is restored. The lifecycle produces natural intermittency that is neither a failure of the domain nor of the scanner.

Academic measurement literature from IMC proceedings has documented this for years. Scanning the internet is not like reading a database. It is like asking questions of a distributed system under continuous load, churn, and partial failure. The answer you get depends on when you ask, which resolver you use, which network path your probe takes, and whether the target’s infrastructure is having a quiet moment or a noisy one.

What “Indeterminate” Means: The Three-Scan Methodology

In the August 2026 census, methodology v9, every domain that fails its first scan is not immediately discarded. It enters a retry queue. If it fails again, it enters a second retry queue. Only after failing all three independent scan attempts, separated in time and using fresh connection state, does a domain receive a terminal classification.

This produces four outcome categories:

Graded: 284,598,752 domains (65.9%) passed active scanning on at least one attempt and received a security grade under methodology v9.
Dead: 92,330,029 domains (21.4%) showed no active service and graded as F across all attempts.
Unreachable: 35,385,107 domains (8.2%) failed all connection attempts without producing any gradable signal.
Indeterminate: 19,814,020 domains (4.6%) produced inconsistent results across attempts. They are neither reliably graded nor reliably dead.

The indeterminate category is the honest answer to a hard question. These domains produced at least one successful probe and at least one failed probe across their three scans, without a pattern that allows a confident classification. Forcing them into either “graded” or “dead” would require choosing a threshold that cannot be defended with the available signal.

At 19.8 million domains, this cohort is larger than most national ccTLD registries. It is not a rounding error in the measurement sense. It is a structured population with its own properties.

The 14.64% Recovery Finding

The retry architecture produces an operationally important measurement: 14.64% of domains that failed their first-pass scan recovered on a later retry pass.

That figure is an internal operational measurement across the August 2026 census run. It is not a theoretical projection. It is the count of domains that failed pass one, then produced gradable signal on pass two or pass three.

Nearly one in seven apparently failed domains came back. That is not randomness. Random failure at the protocol level would produce a much lower recovery rate, because truly dead infrastructure does not spontaneously revive between scan passes separated by hours. A 14.64% recovery rate is the signature of intermittency: infrastructure that is present but unstable, or recovering from a transient event at the moment of first contact.

If a single-pass census had run instead, those 14.64% would have been classified as unreachable or dead. Their security posture would have been unknown. Their owners would have been invisible to any downstream analysis. The three-pass methodology converts a substantial fraction of apparent failures into actual data.

The corollary is harder. The 4.6% that remain indeterminate after three passes are genuinely inconsistent. They are not recoverable with more passes in the short term. Something structural produces their intermittency: geographic routing asymmetry, rate-limiting behaviour, infrastructure that is partially decommissioned, or registrar-side state that makes DNS resolution inconsistent without making it impossible.

What Lives in the Indeterminate Cohort

The 19.8 million indeterminate domains are not uniformly distributed across the domain namespace.

Intermittency is not evenly distributed across TLDs. ccTLDs with smaller registrar ecosystems, thinner DNS infrastructure, and higher proportions of domains registered by individual operators rather than enterprise registrars show elevated indeterminate rates compared to the .com baseline. This is consistent with what you would expect: larger registrars operate more resilient infrastructure, handle DNS secondary zones with more redundancy, and maintain tighter lifecycle discipline. Smaller operators and regional registrars produce more intermittency, not because their domains are less legitimate, but because their supporting infrastructure is more variable.

A meaningful fraction of the indeterminate cohort sits in domains that recently changed state: newly registered, recently expired, recently transferred. These are the exact conditions under which DNS propagation is incomplete and HTTP stacks may not yet be fully operational. They are not dead. They are in transition.

A smaller fraction shows rate-limiting behaviour: the first probe succeeds, the second is blocked, the third succeeds again. This is active infrastructure making a deliberate choice about probe frequency. It is a measurement obstacle, not a signal of poor security posture.

Why This Matters for Security Posture Claims

Any report that claims “X% of domains have no SPF record” or “Y% of domains lack DMARC” is implicitly making a claim about a denominator. What domains are in scope? What does “in scope” mean for a domain that sometimes responds and sometimes does not?

If you include indeterminate domains in your denominator and assume they have no security controls (because you could not measure them), you inflate the negative findings. If you exclude them from your denominator entirely, you narrow the universe to the most reliably reachable domains, which are systematically better maintained than the full population, and you understate the problem.

Neither approach is wrong in isolation. Both are wrong if undisclosed.

methodology v9 counts the indeterminate population separately and does not include it in the graded totals used for security posture statistics. The 284,598,752 graded domains represent the measurable internet for this census round. The 19,814,020 indeterminate domains are reported as a distinct category because that is what they are: a distinct category.

The practical implication for anyone consuming census-derived security statistics: ask whether the study reports its indeterminate population. If it does not, either the study ran a single-pass scan (and is misclassifying 14.64% of its failures), or it collapsed the indeterminate population into one of the binary bins (and is distorting its denominator), or it had no indeterminate population to report (which, at internet scale, would be a surprising operational claim).

Twenty million domains that only sometimes answer is a signal worth tracking. If that number grows in the September 2026 census, it suggests increasing infrastructure fragility at the margins of the registered namespace. If it shrinks, it suggests either better infrastructure or tighter registry lifecycle management. Either way, it tells you something real about the internet that a binary pass/fail model discards.

Check your domain’s security posture against the same methodology v9 used in this census.

Census date: 2026-08-16. Methodology: v8, three-pass scan, 432,127,908 domains total. Indeterminate count: 19,814,020. Retry recovery rate: 14.64% (internal operational measurement). References: RFC 1034, RFC 1035, RFC 7230, ICANN domain lifecycle documentation, IMC measurement proceedings.

What This Means

For IT managers and security teams relying on third-party domain intelligence, the 14.64% retry recovery rate is a direct warning about single-pass scanning tools. Any security product or domain reputation service that probes a domain once and classifies the result as definitive is misclassifying roughly one in seven of its “dead” or “unreachable” findings. If your threat intelligence workflow flags domains as inactive based on a single probe, you may be dismissing live infrastructure — or, conversely, treating genuinely intermittent infrastructure as healthier than it is. The three-pass methodology exists to reduce both errors.

For security researchers and anyone publishing domain security statistics, the denominator question is the most important methodological point in this article. A study that includes 20 million indeterminate domains in the “no DMARC” bucket is using a denominator that inflates the failure rate. A study that excludes them entirely is using a denominator that selects for the most reliably-maintained domains, understating the problem. The honest approach — the one methodology v9 uses — is to report the indeterminate population as its own category and build security statistics only on the graded cohort, with both numbers clearly stated.

For domain operators whose own domains appear intermittent to external scanners, the practical risk is real: security reputation systems, email filtering, and automated threat intelligence tools may be making unreliable assessments of your domain because your infrastructure is inconsistent from an external vantage. DNS secondary zone redundancy, web server uptime, and consistent TLS certificate presentation are the basic operational properties that move a domain from the indeterminate bucket into the graded one. The cost of intermittency is not just downtime — it is unpredictable treatment by security tooling you do not control.

Data to Cite

“19,814,020 domains — 4.6% of 432,127,908 scanned — produced inconsistent results across three independent scan attempts in the August 2026 census, too inconsistent to classify as either reliably alive or dead.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“14.64% of domains that failed their first-pass scan recovered on a later retry pass — nearly one in seven apparent failures came back, the signature of intermittent rather than dead infrastructure.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“284,598,752 domains — 65.9% of 432,127,908 scanned — passed active scanning on at least one attempt and received a full security grade under methodology v9.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“A single-pass census would have misclassified the 14.64% retry-recovery population as unreachable or dead, leaving their security posture unknown and their owners invisible to downstream analysis.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“The 19.8 million indeterminate domains are larger than most national ccTLD registries — this is a structured population with its own properties, not a rounding error.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Any domain security study that does not report its indeterminate population is either misclassifying a 14.64% failure-recovery rate or distorting its denominator — the disclosed methodology is the critical data point.” — defaults.exposed August 2026 Domain Security Census (432M domains)

FAQ

What is an indeterminate domain? A domain that produced inconsistent results across three independent scan attempts — at least one successful probe and at least one failed probe — without a pattern that allows confident classification as either alive or dead. In the August 2026 census, 19,814,020 domains fell into this category: 4.6% of the 432,127,908 total scanned.

Why does the census use three scan passes instead of one? Because the internet’s own protocols — DNS and HTTP — are explicitly designed around retry and fallback. A single probe measures a single moment in a conversation the protocol expects to be retried. The three-pass methodology converts the 14.64% of first-pass failures that recover on retry into actual graded data rather than false unreachable classifications.

How does this compare to July 2026? The indeterminate population and retry recovery rate are recurring measurements that will be tracked across census rounds. The August 2026 figure of 19,814,020 indeterminate domains establishes the baseline; the September 2026 census will provide the first trend comparison. Growth in this number suggests increasing infrastructure fragility at the margins of the registered namespace; a decline suggests either improved infrastructure or tighter registry lifecycle management.

What causes a domain to be intermittent? Several structural causes: geographic routing asymmetry (the domain responds from some network paths but not others), rate-limiting behaviour (the second probe is blocked, the third succeeds), recently-changed lifecycle state (newly registered, recently expired, or in transfer — conditions where DNS propagation is incomplete and HTTP stacks may not be fully operational), and partially decommissioned infrastructure where some components still answer.

Does an indeterminate result affect my domain’s security reputation? Potentially yes. Security reputation systems, email filtering tools, and automated threat intelligence products that probe domains may be making unreliable assessments of your domain if your infrastructure is inconsistent from an external vantage. The practical fix is the same as good operations practice: redundant DNS secondaries, reliable web server uptime, and consistent TLS certificate presentation.

Check your domain free at defaults.exposed — see whether your domain returns consistent, gradable results and what your full security posture looks like across all 34 methodology v9 checks. Takes 30 seconds. No account needed.

How to cite this report

Press / blog: defaults.exposed (2026). The Flaky Internet: 20 Million Domains That Only Sometimes Answer. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/flaky-internet-20-million-indeterminate-domains-2026

Academic: defaults.exposed. (2026, August 18). The Flaky Internet: 20 Million Domains That Only Sometimes Answer. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/flaky-internet-20-million-indeterminate-domains-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026