Data & API Reference

nTLD.zone aggregates data from three canonical sources in the domain name industry:

• ICANN CZDS (Centralized Zone Data Service) — Daily zone files for gTLDs. This is the primary source for live domain counts, additions, and deletions. We ingest zone files every 24 hours for all participating registries.
• ICANN Monthly Registry Reports — Registrar-level market share and domains under management (DUM) figures published by registries each month. Used for registrar breakdowns and monthly trend validation.
• IANA Root Zone Database — The authoritative source for TLD delegation dates, technical operators (backend providers), and registry assignments.

Live zone data is fetched from CZDS once every 24 hours. The ingestion pipeline runs automatically and processes zone files for all participating TLDs in parallel.

Monthly reports are ingested as soon as ICANN publishes them — typically within 1–3 days of the monthly deadline.

Launch phases (Sunrise, Landrush, GA dates) are updated weekly by monitoring IANA and registry announcements.

The dashboard shows a real-time ingestion status badge — if you see "running" or a recent timestamp, the latest data is live. TLDs marked "awaiting first refresh" are tracked in the database but have not yet had a successful zone file download (this usually resolves within 48 hours of being added).

We track all new gTLDs delegated since 2012 — generic, brand, geographic, and community extensions. This includes:

• All ICANN-contracted gTLDs participating in CZDS
• Brand TLDs with public zone data
• Geographic and community extensions

live data source means the TLD has at least one successfully ingested zone file and shows daily counts. none means the TLD is in our database but awaiting its first zone snapshot.

Domain counts reflect live, delegated domains in the DNS root zone — not registrations, not reserved names, not sunrise-blocked labels. This is the most accurate count of actually resolving domains.

The renewal rate is an ICANN-reported transaction metric, not an estimate from short-term changes in the live zone. It measures the share of registrations that reached an expiry cohort and were renewed. Domain registrations can run from one to twenty years; the ICANN term-split fields currently ingested by nTLD.zone cover the published one-to-ten-year buckets.

Two rates: trailing-year vs blended

We publish two distinct figures, because they answer different questions and normally differ by a wide margin:

• Trailing-year renewal rate — renewals reported over the last twelve months divided by domains created in the twelve months before that. This is the first-renewal signal: how much of last year's new registration intake came back. Promotional or speculative registration drives push it down.
• Blended renewal rate — renewals over the last twelve months divided by every one-to-ten-year term cohort actually reaching its anniversary in that window. This measures the whole book, including mature multi-year registrations, and is normally the higher of the two.

first_year_renewal_rate(m) = renewals(trailing 12 months ending m)
                             / creates(12 months ending m-12)
blended_renewal_rate(m)    = renewals(trailing 12 months ending m)
                             / sum over terms N of (creates_N + renewals_N) at m - 12N

Both require at least ten of the twelve months in each window to be present before a figure is published, and each carries its own denominator (base) so the size of the cohort behind the percentage is visible.

ICANN reports a single renewal total covering every cohort, not a renewal count split by registration year. The trailing-year rate is therefore only published where last year's creates make up at least 60% of the domains reaching expiry and the cohort is at least 100 domains; otherwise older multi-year cohorts would inflate it well past 100%, so we show nothing rather than an artefact.

The blended rate is bounded by the same honesty rule. Term-split reports only reach back to early 2024, so for most TLDs we can observe the one- and two-year cohorts reaching expiry but not the three- to ten-year ones. Where those longer terms are a meaningful share of registrations, the denominator is incomplete and the ratio drifts upward — occasionally past 100%, which is impossible and signals missing cohorts rather than perfect retention. We therefore record blended_coverage_pct, the share of recent creates whose expiry cohort we can actually see, and publish the blended rate only when coverage is at least 90% and the result is at or below 100%. Otherwise the figure is withheld, never clamped, and the card explains why.

Expiry-cohort detail (icann_cohort)

We use per-registry monthly transaction reports published by ICANN, which typically arrive two to three months after the reporting period. These reports provide term-split creates and renewals. For each report month, we match the available term buckets to the month in which those registrations reach their anniversary; terms not represented in the source data are not invented or silently counted as one-year registrations.

The calculation for report month m is:

expiring_base(m) = sum over available term buckets N of registrations reaching expiry in m
renewal_rate_ttm(m) = renewals over the trailing 12 months / expiring_base over the same period
monthly_renewal_ratio(m) = renewals(m) / expiring_base(m)

A registration that has not reached its anniversary contributes nothing to the denominator yet. This prevents recent registrations from being incorrectly treated as failed renewals. Multi-year renewals are counted in the month they occur and can re-enter a later expiry cohort at the appropriate term interval.

Approximate fallback (icann_approx)

If term-split history is not available, we estimate the expiry base from domains under management twelve months earlier, spread across the year. This is explicitly labelled approximate because it cannot fully account for multi-year registrations. A rate is only published when sufficient ICANN history exists; otherwise the site shows that the metric is unavailable rather than substituting a short-term proxy.

Portfolio aggregation

Registry-group and backend-operator pages pool each rate on its own denominator: renewals implied across the portfolio divided by the summed base (prior-year creates for the trailing-year rate, expiry cohorts for the blended rate). That is a true portfolio rate rather than an average of averages, and a small TLD cannot swing it. Only TLDs with a valid figure for that specific rate contribute, so missing coverage is not silently treated as zero.

Stored fields

Each monthly row in tld_renewal_metrics carries:

• first_year_renewal_rate / first_year_base — trailing-year rate and the prior-year create cohort behind it.
• blended_renewal_rate / blended_base — blended rate and the annualised expiry cohort behind it.
• blended_coverage_pct — share of creates whose term cohort is observable; below 90% the blended rate is withheld.
• cohort_years_covered — how many distinct term buckets (1–10 years) contributed to that expiry cohort.
• renewal_rate_ttm — headline rate: the blended figure where cohorts exist, otherwise the approximate DUM-based estimate.
• method — icann_cohort or icann_approx, plus months_of_history for transparency.

Refresh cadence and coverage

• ICANN reports are ingested hourly in small batches across a rolling 30-month window.
• Renewal metrics are recomputed after report ingestion and stored in tld_renewal_metrics; a nightly recompute catches late filings.
• Transfers between registrars are not renewals and are excluded from the numerator.
• Term-split history currently reaches back to early 2024, so blended cohorts are available for far more TLDs than the stricter trailing-year rate.
• ICANN reporting coverage varies by registry and may exclude brands, ccTLDs, or months not yet filed.
• Both rates, their bases, the method, report month, and coverage are surfaced on TLD, registry, and operator pages, plus machine-readable endpoints.

Reading the two numbers together

A high blended rate with a low trailing-year rate means an established book renewing well while new intake churns out — typical of registries running aggressive first-year promotions. The reverse is rare and usually signals a shrinking legacy base. Where only one figure is shown, the other did not meet its publishing threshold; the card states which method produced the number rather than mixing them.

nTLD.zone exposes a Model Context Protocol (MCP) server at:

https://ntld.zone/api/mcp

The endpoint uses Streamable HTTP (POST JSON-RPC). It is public, read-only, and requires no authentication.

Available Tools

Connecting

{
  "mcpServers": {
    "ntld-zone": {
      "url": "https://ntld.zone/api/mcp"
    }
  }
}

curl -X POST https://ntld.zone/api/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "list_tlds",
      "arguments": { "limit": 5 }
    }
  }'

All nTLD.zone data is published under CC-BY-4.0 (Creative Commons Attribution 4.0 International).

You are free to use, share, adapt, and build upon the data for any purpose — including commercial use and AI training — provided you give appropriate credit.

When republishing or referencing in academic work, please link to the source. For bulk data access or research collaborations, get in touch.

What is a new top-level domain (nTLD)?

New TLDs are the domain extensions ICANN delegated as part of the 2012 New gTLD Program — for example .app, .xyz, .online, .shop, and several hundred others. nTLD.zone tracks daily registration counts and operator data for every one of them.

Where does nTLD.zone get its data?

Daily zone files come from ICANN's Centralized Zone Data Service (CZDS), monthly domains-under-management figures from ICANN's monthly registry reports, and delegation/operator metadata from the IANA Root Zone Database.

How often is the data updated?

Zone snapshots are fetched once every 24 hours. Monthly registry reports are ingested within 1–3 days of ICANN publication. Launch phases are reviewed weekly.

Can I use this data in my own product or AI model?

Yes. All data is published under CC-BY-4.0 and is free to use commercially, including for AI training and retrieval, provided you credit nTLD.zone with a link to https://ntld.zone.

Is there a programmatic API?

Yes. nTLD.zone exposes a Model Context Protocol (MCP) server at https://ntld.zone/api/mcp, plus markdown snapshots at /llms.txt and /llms-full.txt.

What does 'domains live' mean versus 'registered'?

'Domains live' is the count of names actually delegated in the DNS root zone on a given day. 'Registered (official)' is the domains-under-management figure published by each registry's ICANN monthly report and is usually higher because it includes names registered but not yet resolving.