Methodology

Two clocks

This site runs on two independent data cycles, and conflating them is the easiest way to misread it.

Daily

Domain counts, adds and drops, DNSSEC and nameserver breakdowns. Derived from registry zone files, refreshed every 24 hours. How a domain is counted has the exact inclusion rule.

Monthly, ~3 months late

Everything attributed to a registrar: market share, transfers, deletes, renewals. Zone files contain no registrar information whatsoever, so this can only come from ICANN's monthly registry reports, which publish about a quarter in arrears. Every registrar figure on this site is stamped with the month it describes.

Three populations

Every page defaults to the new gTLDs — the strings delegated from ICANN's 2012 round onward. That is what this site is for, and it is what every figure means unless the page says otherwise. The toggle at the top of the main pages switches the whole page between three populations, and the URL carries it, so a scoped view can be linked and cited.

New gTLDs

Roughly 1,100 strings from the 2012 round onward, plus the 2026 round as it delegates. The default everywhere.

Legacy gTLDs

The 18 pre-2012 generics and sponsored strings — .com, .net, .org, .info, .biz, .asia and the rest. Their registrar data comes from the same ICANN monthly reports as the new gTLDs, which is why they can be covered at all: those reports need no CZDS approval, so a legacy TLD has full registrar history even where we hold no zone file for it. Daily domain counts exist only for the ones whose zones we are approved for.

All gTLDs

The two above added together, and deliberately nothing else. Useful for a total; misleading as a comparison, because .com alone is several times every new gTLD combined, so any combined ranking is a ranking of who sells .com.

The three are never mixed. A figure belongs to exactly one population, the API repeats the scope it used in every response, and the aggregates are computed separately per scope rather than filtered afterwards — so there is no path by which a legacy number can reach a page labelled new gTLDs.

How a domain is counted

A name is counted as a registered domain when it appears in the TLD's zone file as a direct child of the TLD with at least one NS record, or a DS record. That is the conventional definition for zone-derived counts and it has consequences worth stating:

• Registered names with no nameservers delegated are not counted — they are not in the zone.
• Premium and registry-reserved names appear only once they actually resolve.
• Names in a redemption or pending-delete state usually still resolve, so they still count until removed.
• Counts can therefore run slightly below a registry's own "domains under management" figure. Where both exist, the monthly reports are the registry's own number and the zone count is ours.

Adds and drops are the exact set difference between consecutive days' name lists, not an estimate. The first day a TLD is ingested has no previous day to compare against, so it reports no change rather than reporting the whole zone as additions.

How the registry backend is determined

ICANN publishes no mapping from TLD to technical backend, so this site infers it from three public signals, in order of strength:

1. Root nameserver hostnames. A TLD served by *.gmoregistry.net is on GMO's platform.
2. RDAP endpoint from IANA's bootstrap file, which often reveals a shared platform even when nameservers are per-TLD vanity names.
3. Reverse DNS of the nameserver addresses. Brand TLDs almost always use vanity hostnames like a.nic.example, which identify nothing — but the PTR record for those addresses usually names the real platform.

Where several TLDs share infrastructure that no curated fingerprint covers, a backend is created automatically and labelled inferred: the grouping is real evidence, but the name is the shared hostname rather than a company we have verified. TLDs whose infrastructure identifies nothing are left explicitly unattributed rather than guessed at, and counted on the backends page so the totals still add up.

Keep rate

Of the domains that reached a renewal decision in the last twelve reported months, the share that were renewed rather than deleted: renewals / (renewals + deletions). Both terms come from the same monthly registry report, so the ratio is bounded between 0% and 100% and needs no assumption about when a domain was first registered.

The obvious alternative does not work, and was built before being discarded. Comparing this month's renewals against the registrations of twelve months earlier gives .dev a rate above 300%, because monthly renewals include domains first registered years ago while the denominator is a single month's signups. A true cohort rate would need per-domain expiry dates, which no public source publishes.

What a keep rate is not:

• Not a survival rate. A domain registered for three years reaches a decision once, not annually, so a TLD sold on long terms reports fewer renewals and fewer deletions rather than a different ratio.
• Renewals include auto-renewals, which is how most registries report them.
• Deletions include names dropped during the grace period, so a deletion can lag its expiry by a month or two. Over twelve months that mostly washes out.
• Transfers are excluded. Moving registrar is not a renewal decision, though it often carries one with it.
• Brand TLDs are not comparable to open ones. Where the registry owns every name and renews them by default, a rate near 100% describes a filing habit rather than anyone's preference. The table can be filtered to open TLDs, though our brand classification has known false negatives — .stcgroup and .xn--vermgensberater-ctb are plainly brands and IANA's data calls them generic.

A TLD needs at least 1,000 renewal decisions in the window before a rate is shown. Below that the ratio is arithmetic on too little: nine renewals and one deletion is ten events, not "90% kept".

Impossible filings

Some monthly reports are wrong, and this site shows them anyway with a marker rather than quietly dropping them. A registry cannot delete or renew more domains than its TLD has ever held, and 683 filings across 61 TLDs do exactly that: .llp reported 9,304 deletions in one month while holding four domains, .sncf 155,448 against a peak of 1,274, and .firmdale filed the identical 191 renewals for seven consecutive months from a 48-domain zone. Each was checked against ICANN's published CSV before being called an anomaly — the files really do say that, so these are the registries' filings and not our reading of them.

Where a TLD's window contains such a month, its row is marked and shows what the rate would be with that month set aside. The figure itself remains as filed, because the filings are the data and correcting them silently would be an editorial act disguised as arithmetic.

What this site does not measure

• Registrant country. No public source contains it. Zone files have no registrant data and ICANN's monthly reports are per-registrar, not per-registrant. The country page shows where registrars are accredited, which is a different and much weaker claim.
• Prices or renewal rates. Not published by registries in any machine-readable form.
• Whether a domain is "in use". Parking detection is based on nameserver patterns only; nothing is resolved or fetched. The parking figure is a lower bound, since a domain parked on a registrar's ordinary nameservers is indistinguishable from one that is genuinely hosted.
• ccTLDs. Country-code registries hold no ICANN contract, so they file no monthly reports, and most publish no zone file. There is no source to build them from — this is a limit of what is public, not an editorial choice.

Sources

Every source is public and requires no credentials except CZDS. All are probed weekly and drift is alerted on.

Zone data is used under ICANN's CZDS terms, which permit analysis but prohibit redistributing zone data. This site therefore publishes aggregate statistics only — it holds no searchable index of domain names, and the name lists used to compute daily adds and drops are deleted after two days.

Live pipeline status

Freshness is not something you should have to take on trust. The status page shows the last successful run of every source, and a source that stops updating is reported there rather than silently serving old numbers as though they were current.