The Phantom TLD Problem: The Domains That Don't Exist
Published
Figures as of 17 August 2026 (wildcard probe) · domain counts from the July 2026 census round. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.
The headline: .ph counted at 14.6 million, real base about 57,874
We probed all 1,386 top-level domains and found 8 that answer for any name you can invent. One of them, the Philippines’ .ph, has been carried in passive-DNS-derived inventories at more than 14.6 million “domains” when its true registration base is roughly 57,874 — an inflation factor of about 250×.
For every real .ph domain, resolution-derived datasets have been counting roughly 250 that were never registered by anyone.
The mechanism is old, mundane and easy to miss. These 8 TLDs are DNS-wildcarded: their nameservers resolve every possible name under the TLD, registered or not. Type any random string, add the ending, and you get an answer. Measurement systems that infer “this domain exists” from “this name resolved” swallow the wildcard whole, and the phantom domains flow downstream into registration league tables, “fastest-growing ccTLD” headlines, and academic studies.
Two of the eight carry a stranger signal. The brand TLD .merck and the Arab League’s .عرب were, as of our 17 August 2026 probe, still answering every query with 127.0.53.53 — ICANN’s reserved name-collision warning address, explained in its own section below.
Key findings
- 8 of 1,386 TLDs are DNS-wildcarded: they resolve every name under the TLD, whether or not it is registered.
- .ph is the whale: 14.6M+ claimed “domains” in passive-DNS-derived inventories versus a true base of about 57,874 — a ~250× inflation.
- Two TLDs (.merck and .عرب) were still broadcasting 127.0.53.53, ICANN’s name-collision mitigation address, when we probed on 17 August 2026.
- Any statistic built on passive DNS inherits the phantoms. Zone-file-based counts (the CZDS-covered gTLDs) are immune; passive-DNS-style ccTLD counts are not.
- Wildcarding itself is a registry policy choice, not misconduct — the counting error happens downstream, on the measurement side.
What a wildcarded TLD actually does
A normal TLD is honest about what exists. Ask its nameservers for a domain nobody registered and you get NXDOMAIN: no such name. Every count, crawler and security scanner on the internet leans on that honesty.
A wildcarded TLD never says no. Ask it for a name that was registered yesterday, a name that lapsed a decade ago, or a name you generated by mashing the keyboard, and it answers with an IP address. Usually the same IP address, every time, for everything.
That is exactly how we caught them. Our probe generated two random 12-character labels per TLD — strings essentially guaranteed never to have been registered — and looked them up under all 1,386 TLDs in the census. A TLD was flagged as wildcarded only when both random names resolved and resolved to the same A record. Eight TLDs met that bar.
The test is deliberately conservative. A wildcard that rotates its answer IPs, or that only wildcards certain patterns, would slip past it. So 8 is a floor, not a ceiling.
The whale: how .ph grew 250 times larger than reality
The .ph case is where the abstract problem turns into a concrete, quantifiable data-quality failure.
First, the numerator, stated as precisely as we can state it. The 14.6M+ figure is what our own census source-inventory ingest carried for .ph: an aggregation of passive-DNS-derived domain lists, OpenINTEL-derived data among the inputs. We are not claiming any single named dataset publishes “14.6 million .ph domains” as a headline figure; we are reporting what the passive-DNS-derived supply chain, as we ingested it for the July 2026 census round, delivered when asked for .ph. Anyone building on similar inputs — and much of the domain-measurement world does — starts from a similarly inflated base.
The denominator is ours too, and the method is simple enough to say in one sentence: we counted every .ph name that shows the evidence a registered, living domain actually shows — nameserver delegation, address records, mail configuration — and got approximately 57,874. That is not a registry press release. dotPH, the .ph registry operator, does not to our knowledge publish a routinely updated public registration count, and we did not seek comment from dotPH before this edition; if the registry publishes or supplies an authoritative figure, it supersedes our reconciliation, and we will print it.
Here is why the phantom mass accumulates. Passive DNS records names that were looked up, not names that were registered. Every typo, every piece of malware probing random hostnames, every misconfigured internal system that leaks a lookup ending in .ph — each one resolves, thanks to the wildcard at 45.79.222.138, and each one gets logged as evidence that a domain exists. A registered domain and a keyboard-mash produce the same artifact in the corpus: a name, an answer, a timestamp. Over years, that noise compounds into millions of entries that no human ever registered, and nothing in the data marks them as different.
Our census caught the discrepancy because it refuses to take a bare DNS answer as proof of life. The census disposition logic demands converging evidence — nameserver delegation, address records, mail configuration — before treating a domain as real, and under that standard the .ph phantom mass grades out as effectively empty. Source inventories said 14.6 million; live scanning found about 58 thousand. Roughly 99.6% of the ingested .ph names were phantoms — names that resolved only because the TLD’s wildcard answers for everything.
The eight: every wildcarded TLD, and where the phantom traffic goes
| TLD | Operator context | Wildcard answer (A record) |
|---|---|---|
| .ph | Philippines ccTLD | 45.79.222.138 |
| .ws | Samoa, marketed as “website” | 64.70.19.203 |
| .vg | British Virgin Islands | 88.198.29.97 |
| .xn—fiqs8s (.中国, simplified) | China IDN ccTLD (CNNIC) | 218.241.105.10 |
| .xn—fiqz9s (.中国, traditional) | China IDN ccTLD (CNNIC) | 218.241.105.10 |
| .xn—node (.გე, Georgia IDN) | Georgia IDN ccTLD | 188.93.95.11 |
| .merck | Brand TLD | 127.0.53.53 |
| .xn—ngbrx (.عرب) | Arab League TLD | 127.0.53.53 |
The list is not a rogues’ gallery of obscure operators. It includes two national IDN TLDs run by CNNIC, China’s national registry, both parking every unregistered .中国 name on the same address (218.241.105.10, a CNNIC holding page). It includes .ws, which has openly operated a wildcard for years and markets “any name resolves” as a product feature. Wildcarding a TLD you operate is, in these cases, a deliberate policy choice.
Wildcarding is not misconduct. Counting wildcards as registrations is the mistake, and it belongs to the measurement industry, not the registries.
The hazard beacon still live in 2026
127.0.53.53 is not a normal address. It is ICANN’s designated “controlled interruption” IP, introduced during the new-gTLD programme as a name-collision safety mechanism. The idea: before a new TLD goes fully live, its nameservers answer every query with this deliberately loud, deliberately broken loopback address. Any company whose internal network had been quietly using that TLD as a private suffix would see connections fail in a distinctive, searchable way (the “53” twice is a nod to DNS’s port number), find the ICANN advisory, and fix their network before real registrations created genuine conflicts.
Controlled interruption was designed as a temporary phase — a transition measure applied at delegation.
Our probe found it live on two TLDs on 17 August 2026: .merck, a corporate brand TLD, and .عرب, the Arab League’s Arabic-script TLD. Every random name we invented under both resolved to 127.0.53.53.
We should be precise about what one probe can and cannot establish. It shows the beacon was answering on the day we looked; it cannot show whether it has been on continuously since delegation or was re-enabled at some point — distinguishing those would take historical passive-DNS data or repeated probes across days and vantage points, which we have not yet done. We also did not seek comment from Merck, the .عرب registry operator, or ICANN before this edition; this is a measurement report, not an investigation of those operators, and no inattention on their part should be inferred.
Two top-level domains were still broadcasting ICANN’s “this domain is a hazard” beacon in August 2026, years after delegation.
The likeliest explanation is inertia: a TLD with little or no third-party registration activity, parked on the one address guaranteed to route nowhere, and nobody with a reason to touch it. But a safety mechanism designed as a short transition phase answering queries years later says the name-collision era of the new-gTLD programme never actually closed — and for measurement systems, a beacon TLD is one more namespace where every invented name “exists.”
Who inherits the phantoms
This would be a curiosity if DNS answers stayed in DNS. They don’t. They flow into the league tables, growth narratives and research corpora already named in the opening — and wherever the underlying count came from resolution data rather than a registration record, the phantoms travel with it. A “fastest-growing ccTLD” trend line built on phantom accumulation is measuring lookup noise, not economic activity: phantom counts grow whenever queries happen, which is always.
The immunity boundary is clean and worth stating precisely:
| Counting method | Coverage | Phantom exposure |
|---|---|---|
| Zone files (CZDS) | Most gTLDs (.com, .net, new gTLDs) | Immune — a zone file lists actual registrations |
| Passive DNS / resolution-based inventories | The main window into many ccTLDs | Exposed — a wildcard makes every lookup “exist” |
That boundary explains why the problem hides so well. The best-audited part of the namespace, the CZDS-covered gTLDs, is exactly the part where wildcards can’t distort the numbers, so the industry’s intuition (“our counts are basically right”) is formed where the failure mode can’t occur. The failure lives in the ccTLD long tail, where zone files are mostly unavailable and resolution-based counting is often the only option.
The parts of the internet we can audit are fine. The parts we can’t audit are where the phantoms live.
What honest counting looks like
The fix is not exotic. It is three habits, and we hold our own census to them.
First, probe for wildcards before you count. The wildcard probe took one run to classify all 1,386 TLDs — any measurement pipeline can afford it. Every TLD should be wildcard-checked before its resolution data is trusted.
Second, demand converging evidence. A domain should be graded as live only on combined nameserver, address and mail-record evidence, never on a single resolution. That disposition standard is the reason the .ph discrepancy surfaced at all.
Third, publish the caveats with the numbers. Our probe’s blind spots — rotating-IP wildcards, partial wildcards, the single vantage point — are listed in full in the methodology section below. We say so, because the alternative is becoming a source of the same false confidence this report is about.
None of this requires inside access. It requires refusing to let one DNS packet stand in for a registration record.
A 60-second check before you quote a domain statistic
If you write about the domain industry, here is how to avoid inheriting a phantom count, in the time it takes to read a press release.
Ask where the number came from. If the answer is a registry’s own figure or a zone file, you are on solid ground: those enumerate actual registrations. If the answer is a passive-DNS corpus, a resolution-based crawl, or “an industry dataset” that won’t say, the number can contain phantoms, and for a wildcarded TLD it can be almost nothing but phantoms.
Check the TLD against the table above. Any count for .ph, .ws, .vg, .中国 (either script), .გე, .merck or .عرب that came from resolution data should be treated as unverified until the source explains its wildcard filtering. A story built on an unfiltered resolution count for a wildcarded TLD is not slightly off; it can be off by orders of magnitude.
Do the trick yourself. The wildcard test needs no special tooling: look up a long random string under the TLD. If gibberish resolves, everything resolves, and any resolution-based count for that TLD is measuring the wildcard, not the market.
If a name you invented ten seconds ago resolves, that TLD cannot be counted by counting what resolves.
The same discipline applies to us. Every figure in this report is either a direct probe result from 17 August 2026 or a July 2026 census reconciliation, with the method and its blind spots stated below. Where our probe can undercount, we say it can undercount.
How we measured it
- Population: all 1,386 TLDs in our census.
- Probe: for each TLD, two random 12-character labels were generated and resolved. A TLD was classified as wildcarded only when both random names resolved and returned the same A record. Probe run 17 August 2026 from our EU measurement infrastructure.
- Conservatism: the both-resolve-same-IP rule undercounts wildcards that rotate answer IPs or apply per-label rules. Treat 8 as a floor.
- Single vantage, single day: the probe was a one-shot run from one vantage point, testing one wildcard pattern. In particular, it establishes that the 127.0.53.53 answers on .merck and .عرب were live on the probe date; it cannot establish continuity since delegation.
- The .ph claimed figure (14.6M+) is what our census source-inventory ingest — an aggregation of passive-DNS-derived domain lists, OpenINTEL-derived data among the inputs — carried for .ph in the July 2026 round. It is a property of the resolution-derived supply chain, not a figure any registry published.
- The .ph true-registration figure (~57,874) comes from our own reconciliation: counting the .ph names that show live delegation, addressing and mail evidence in census scanning. dotPH was not approached for comment for this edition; an authoritative registry figure, if published or supplied, supersedes ours.
- No comment sought (this edition): Merck, the .عرب registry operator and ICANN were not approached about the 127.0.53.53 findings. We report the measurement only.
- No causal claims. We report that wildcards and inflated inventories co-occur and describe the mechanism that links them; we do not claim any operator wildcarded a TLD in order to inflate statistics. In at least one case (.ws) wildcarding is an openly marketed feature, and .中国’s wildcard resolves to a registry holding page.
- Aggregate only. We name TLDs and registry-level infrastructure. We never name, grade or publish data about an individual registrant’s domain.
- Data is stored and processed within the EU.
FAQ
Is a wildcarded TLD dangerous to use? Not inherently. Wildcarding changes what unregistered names do, not what registered ones do. The risk is statistical, not operational: any system that infers existence from resolution will miscount that TLD. If your measurement or security tooling treats “it resolved” as “it exists,” a wildcarded TLD will quietly poison your data.
Does this mean the Philippines’ internet is smaller than reported? It means .ph’s domain count is smaller than resolution-based inventories implied: roughly 57,874 real registrations versus the 14.6M+ carried in passive-DNS-derived datasets, as of our July 2026 census round. That says nothing about Philippine internet usage or the quality of .ph domains that do exist. The phantoms were never real, so nothing real has shrunk.
Why is 127.0.53.53 special? It is ICANN’s reserved controlled-interruption address for name-collision mitigation, described in full above. In short: a signature loopback IP that new TLDs answer with at delegation, designed as a temporary phase. Our probe found it live on .merck and .عرب on 17 August 2026.
Could there be more than 8 wildcarded TLDs? Yes. Our detection rule — two random labels, both resolving to the same A record — is deliberately strict, so wildcards that rotate IPs or only match certain patterns would evade it. Eight is the conservative floor from a single probe run on 17 August 2026.
Which domain statistics can I still trust? Counts built from zone files (the CZDS-covered gTLDs, including .com) are immune, because a zone file lists actual registrations. Be sceptical of resolution-derived counts for ccTLDs, especially any headline number for a TLD in the table above, unless the source describes how it filtered wildcard responses.
What This Means
For IT security teams, the phantom TLD finding has a direct implication for any security tool that uses domain-count data to assess risk or prioritise investigation. If your threat intelligence platform draws on passive-DNS-derived inventories and does not wildcard-filter before counting, its coverage statistics for wildcarded TLDs are wrong by orders of magnitude. A tool that claims “we monitor 14.6 million .ph domains” is monitoring the wildcard, not the market. The eight TLDs in this report are the ones we confirmed; the eight may be a floor.
For anyone who cites internet domain statistics in press, research, or board reporting, the immunity-boundary table in this article is the critical reference. Counts built from zone files — which cover .com, .net, .org, and most new gTLDs through ICANN’s CZDS — are based on actual registrations and are reliable. Counts built from passive DNS or resolution-based crawls for ccTLDs are potentially exposed to wildcard inflation. The correct question to ask of any domain statistic is not “how many domains are there” but “how was this count produced, and was wildcard filtering applied.”
For organisations with internal network infrastructure that uses custom TLD suffixes — a common pattern in enterprise environments — the 127.0.53.53 finding is a concrete reminder to check your split-DNS configuration. If your internal systems use a TLD suffix that corresponds to a delegated TLD now answering with the controlled-interruption address, your internal DNS may be interacting with that beacon in unexpected ways. The ICANN advisory on name-collision mitigation describes the diagnostic approach.
Data to Cite
- “8 of 1,386 TLDs probed in August 2026 are DNS-wildcarded — they resolve every possible name under the TLD whether or not it was ever registered.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “.ph’s passive-DNS-derived count of 14.6 million ‘domains’ overstates the true registration base by approximately 250×: live scanning found roughly 57,874 real domains.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Roughly 99.6% of ingested .ph names were phantoms — names that resolved only because the TLD’s wildcard answers for everything, never registered by anyone.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Two TLDs — .merck and .عرب — were still broadcasting 127.0.53.53, ICANN’s name-collision hazard beacon, when probed on 17 August 2026, years after their delegation.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Zone-file-based counts (CZDS-covered gTLDs including .com) are immune to wildcard inflation; passive-DNS-derived counts for ccTLDs are directly exposed to it.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “The wildcard test requires no special tooling: look up a random string under the TLD — if gibberish resolves, any resolution-based count for that TLD is measuring the wildcard, not the market.” — defaults.exposed August 2026 Domain Security Census (432M domains)
See where your own domain stands
Phantom domains can’t be secured, but yours can. Our census grades real, live domains across 34 externally observable security checks, and most of what a failing domain is missing is free and quick to fix — the barrier is almost never cost, it’s that nobody told the owner it mattered. You can check your domain privately and free, and see exactly which checks you pass.
Read the flagship census report: The State of Domain Security 2026 →
Aggregate data only. Data stored and processed in the EU.
Check your domain free at defaults.exposed — see whether your domain passes the same convergent-evidence tests that separate real registrations from phantom DNS noise, and get your full security grade across 34 checks. Takes 30 seconds. No account needed.
How to cite this report
Press / blog: defaults.exposed (2026). The Phantom TLD Problem: The Domains That Don’t Exist. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/phantom-tld-problem-wildcarded-domains-2026
Academic: defaults.exposed. (2026, August 18). The Phantom TLD Problem: The Domains That Don’t Exist. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/phantom-tld-problem-wildcarded-domains-2026
In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=1,386 TLDs probed)
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