▸ How to get newly registered domains

There is no single feed of “every domain registered in the last hour”. Registries do not publish one, and ICANN does not require them to. What exists instead are observations, and you build a list of recently registered domains by picking the observation that matches your tolerance for delay and your need for coverage:

• ▸ Need authority and completeness for gTLDs? Diff registry zone files. 24-hour floor, free, real work.
• ▸ Need speed and every TLD? Certificate Transparency. Seconds behind issuance, but blind to domains without certificates.
• ▸ Need it working this afternoon? Download a prepared list - ours is below, and so are the alternatives.

Three different timestamps get called the same thing, and conflating them is the single most common reason a newly registered domains list disagrees with somebody else’s:

• 1. Registration date - when the registry created the record. Authoritative, exposed per domain via RDAP/WHOIS, not published in bulk by anyone.
• 2. Zone appearance - when the domain first got name servers in the TLD zone. Usually minutes to hours after registration, but a domain registered and never pointed anywhere never appears at all.
• 3. First observation - when a certificate log, a resolver, or a crawler first saw it. This is what every downloadable feed really contains, including ours.

The closest thing to ground truth. gTLD registries are contractually required to make their zone files available through ICANN’s Centralized Zone Data Service (CZDS). You register an account, submit a request per TLD stating your purpose, and each registry approves or denies it - approvals are typically granted for a year and then need renewing. Roughly 1,150 gTLDs are reachable this way, including .com and .net. Most ccTLDs are not: a handful (Sweden’s .se and .nu, Switzerland’s .ch) publish openly, the rest publish nothing.

A zone file lists delegations, not registrations. So the recipe is: normalise today’s delegated names, and subtract yesterday’s.

# 1. Fetch today's zone (CZDS gives you a per-TLD download URL + API token)
curl -s -H "Authorization: Bearer $CZDS_TOKEN" \
     -o com.txt.gz "https://czds-api.icann.org/czds/downloads/com.zone"

# 2. Reduce the zone to a sorted list of delegated second-level names
zcat com.txt.gz \
  | awk '$4=="NS" {print tolower($1)}' \
  | sed 's/\.$//' \
  | sort -u > zone.today

# 3. Everything present today and absent yesterday is a new delegation
comm -13 zone.yesterday zone.today > new-domains-$(date +%F).txt
wc -l new-domains-$(date +%F).txt

# 4. Roll the window
mv zone.today zone.yesterday

Note the $4=="NS" rather than $3: zone lines carry an optional TTL, so the column index shifts. Check a few lines of your actual file before trusting the field number - this is the bug that silently empties your list.

Storage reality check: the .com zone alone is in the region of 160 million delegated names, so each day’s sorted copy is several gigabytes uncompressed. Keeping two days plus a permanent seen-set is the minimum viable footprint.

Every publicly trusted TLS certificate is submitted to append-only Certificate Transparency logs, and those logs are public. Because a newly registered domain that is actually being set up almost always gets a certificate within minutes - the hosting panel or the reverse proxy requests one automatically - CT is the fastest broad discovery channel available for free, and unlike zone files it covers every TLD, ccTLDs included.

The two practical ways in:

# A. Consume an aggregated CT firehose (easiest)
#    e.g. CertStream-compatible websocket endpoints
websocat wss://certstream.calidog.io \
  | jq -r '.data.leaf_cert.all_domains[]?' \
  | sed 's/^\*\.//' \
  | sort -u

# B. Read the logs directly (RFC 6962) - no third party in the path
#    Each log exposes its tree head and a paged entries endpoint:
curl -s https://ct.googleapis.com/logs/us/argon2026h2/ct/v1/get-sth | jq .tree_size
curl -s "https://ct.googleapis.com/logs/us/argon2026h2/ct/v1/get-entries?start=0&end=9"

Option B is what DNSniffer runs. It is more work - you maintain a per-log offset, parse the leaf structures, and deal with logs that rate-limit or cap entries per request - but you are not dependent on somebody else’s aggregator staying up.

This is the site you are on, so treat this section as what it is - but the reason it belongs on the list is that it is the combination of the previous two methods, already running. DNSniffer ingests gTLD zone files and reads the Certificate Transparency logs directly, merges both into one domain table - currently 361,852,573 active domains across 9,920 TLDs, and publishes the newly-detected slice as plain CSV.

daily export last rebuilt September 1, 2026 · regenerated every day

Three ways to consume it, none of which need an account:

# 1. List the newly-detected exports and grab the current download URL
curl -s 'https://dnsniffer.com/api/v1/datasets?category=newly_detected' \
  | jq -r '.data[] | "\(.periodicity)\t\(.row_count)\t\(.download_url)"'

# 2. Download and read the daily file (zipped CSV)
URL=$(curl -s 'https://dnsniffer.com/api/v1/datasets?category=newly_detected' \
      | jq -r '.data[] | select(.periodicity=="daily") | .download_url')
curl -sL "https://dnsniffer.com$URL" -o nrd-daily.zip
unzip -p nrd-daily.zip | head

# 3. Filter to one TLD without downloading everything
unzip -p nrd-daily.zip | awk -F, 'NR==1 || $1 ~ /\.com$/'

If you only care about names matching your brand or a keyword, the monitor feature does the filtering server-side and keeps a match history you can pull over the API - that is a free account rather than an anonymous download, but it is a lot cheaper than pulling 300k rows a day to grep for one string. The newest domains page shows the same stream in the browser, and the MCP server exposes it to Claude, ChatGPT and other agents directly.

Several security vendors and hobbyists publish a daily new domains list as a plain text or zipped file - typically yesterday’s registrations, gTLD-heavy, published on a fixed schedule. They are genuinely useful as a zero-effort baseline, and they share three weaknesses worth knowing before you build on one: the publisher rarely documents which TLDs are covered, the file appears 24–48 hours after the fact, and free tiers disappear or move behind a signup with no notice.

If a free list is your primary source, mirror it daily into your own storage. The value is in the accumulated history, and you cannot backfill a feed that vanishes.

Vendors including WhoisXML API, DomainTools and various threat-intelligence platforms sell newly registered domain feeds, usually delivered daily with WHOIS fields attached - registrar, registration date, name servers, sometimes contact data where it is not redacted. What you are paying for is threefold: ccTLD coverage you cannot obtain yourself, the registration date as a field rather than something you have to look up per domain, and someone else operating the collection.

Questions worth asking before you sign anything:

• ▸ Exactly which TLDs, and is the list published or “representative”?
• ▸ Is the date the registry’s registration date, or their first observation?
• ▸ What is the cut-off time and the delivery delay, in hours?
• ▸ Are you allowed to redistribute derived data, or only to consume it internally?

Passive DNS providers record resolutions observed by cooperating recursive resolvers, giving you a first-seen timestamp per name. It catches things zone files miss - subdomains, ccTLDs, and domains that are resolving before they ever get a certificate - and it is biased by construction: you only see what the provider’s sensor network sees, so a domain used by a hundred people in one country may not register at all. Treat it as a strong complement to CT rather than a standalone discovery source, and expect to pay for anything with real volume.

RDAP is the structured replacement for WHOIS, and it is the only place the actual registration date lives. It cannot enumerate - there is no “list all domains registered today” query, by design - but it settles the question for any specific name:

# rdap.org follows the IANA bootstrap, so you need not know the registry
curl -s https://rdap.org/domain/example.com \
  | jq -r '.events[] | select(.eventAction=="registration") | .eventDate'

# Filter a candidate list down to genuinely new registrations
while read -r d; do
  created=$(curl -s "https://rdap.org/domain/$d" \
            | jq -r '.events[]? | select(.eventAction=="registration") | .eventDate')
  [ -n "$created" ] && echo "$d,$created"
  sleep 1        # be polite: registry RDAP endpoints rate-limit aggressively
done < new-domains.txt > verified.csv

Whichever sources you pick, the same five steps separate a list that stays useful from one that quietly rots:

1. 1. Normalise. Lower-case, strip the trailing dot, convert IDNs to punycode (xn--), and collapse every name to its registrable form via the Public Suffix List. Example.CO.UK., www.example.co.uk and example.co.uk are one domain.
2. 2. Keep a permanent seen-set. “New” is defined against everything you have ever recorded, not against yesterday’s file. Without this you re-report old domains every time a source changes shape.
3. 3. Store first-seen and source separately. A domain seen in CT at 09:00 and in the zone diff at 03:00 the next day is one row with two observations. Overwriting loses the earliest signal, which is the one you care about.
4. 4. Score before you act. Raw NRD volume is far too high to review. Filter to what you need - brand-adjacent strings, edit-distance lookalikes, suspicious TLDs, keyword combinations - then verify that shortlist with RDAP.
5. 5. Expect churn. A large share of newly registered domains lapse within days, and drop-catching means the same name reappears repeatedly. Re-check liveness before treating an entry as an active asset.

• ▸ Counting dots to find the registrable domain. foo.co.uk and foo.uk both have a two-label registrable form under different rules. Use the Public Suffix List.
• ▸ Treating zone absence as non-existence. A registered, undelegated domain is invisible to every zone-based method.
• ▸ Ignoring timezone and cut-off. Zone files are snapshots at a registry-defined moment; “yesterday” in your pipeline and in the file are not the same window.
• ▸ Assuming CT first-seen equals registration. It is a good proxy and a bad fact.
• ▸ Blocking a whole NRD feed. Hundreds of thousands of legitimate domains are registered every day; blanket blocking generates far more false positives than it prevents incidents. Score, then act.

Zone-file access through CZDS is granted under terms you accept per registry, and they restrict redistribution - you can generally use the data, not republish the zone. WHOIS and RDAP contact data is personal data under GDPR and is redacted by default for most registrations; the registration date is not personal data, but the registrant fields are. If you are building a product on top of any feed, read the redistribution clause before you design the export.