DEV Community: WhoisFreaks

How I Built a Subdomain Takeover Scanner in Python (The Dangerous Ones Don't Resolve)

Sameer Sheikh — Thu, 17 Sep 2026 13:15:27 +0000

Every subdomain takeover scanner I've used starts from the same place: enumerate what resolves, then check what it points at. That ordering is backwards. The subdomain you need to worry about is the one that stopped resolving eight months ago, when somebody deleted a Heroku app and left the CNAME behind.

A live scanner never sees it. It's not in your wordlist hits, it's not in your cert transparency pull, and it doesn't answer DNS. It sits there until someone re-registers checkout-staging-v2 on Heroku and starts serving whatever they want from checkout-staging.yourbank.com.

So I built the scanner the other way round. Pull the historical subdomain set first, including records that went dark. Then resolve.

The key insight

Subdomain takeover has two halves, and most tooling only does one well. The DNS half is easy: follow the CNAME, see if the target is gone. The discovery half is where everything falls apart, because brute-force and passive DNS both bias hard toward what's alive right now. Certificate transparency helps, but only for names somebody bothered to issue a cert for, and plenty of internal staging hosts never got one.

What I wanted was a list of every hostname that has ever existed under a domain, with dates attached, so I could sort by "last seen" and start at the bottom. That's exactly what the WhoisFreaks Subdomains API returns. Each record carries first_seen, last_seen, and inactive_from, plus a status filter you can set to inactive to get only the dead ones. Full details in the WhoisFreaks Subdomains API docs.

The dates are the part that matters. A subdomain last seen in March that still has a CNAME in your zone file is a strong lead, not a curiosity.

Setup

git clone https://github.com/WhoisFreaks/wf-subdomain-takeover.git
cd wf-subdomain-takeover
pip install -r requirements.txt          # requests, dnspython
export WHOISFREAKS_API_KEY="your_key"
python takeover_scan.py example.com --csv results.csv

Free tier is 500 credits, which is plenty for a few domains. Two dependencies, no Docker, no config file.

Step 1: Pull the full subdomain history

The endpoint is GET /v1.0/subdomains and it pages. total_pages comes back on the first response, so you loop until you've drained it. I added a rate limiter because the free tier caps requests per minute and I'd rather sleep 6 seconds than eat a 429.

API_BASE = "https://api.whoisfreaks.com/v1.0/subdomains"

def fetch_subdomains(domain, api_key, status=None, max_pages=50, rpm=10):
    """Page through /v1.0/subdomains and return every record."""
    session = build_session()
    limiter = RateLimiter(rpm)
    records, page = [], 1

    while page <= max_pages:
        params = {"apiKey": api_key, "domain": domain, "page": page}
        if status:
            params["status"] = status

        limiter.wait()
        resp = session.get(API_BASE, params=params, timeout=25)
        if resp.status_code != 200:
            sys.stderr.write(f"[!] page {page} returned HTTP {resp.status_code}\n")
            break

        payload = resp.json()
        batch = payload.get("subdomains") or []
        records.extend(batch)

        total_pages = int(payload.get("total_pages") or 1)
        if page >= total_pages or not batch:
            break
        page += 1

    return records

Each record looks like this:

{
  "subdomain": "staging-api.example.com",
  "first_seen": "2021-08-04",
  "last_seen": "2025-11-19",
  "inactive_from": "2025-11-20"
}

Pass --status inactive and you get only the records the index has marked decommissioned. On the domain I tested that filter was exactly right, so it's a reasonable shortlist. I'd still pull everything and resolve it yourself, partly because DNS is cheap and mostly because you want the live hosts in the same table to compare against.

Step 2: Walk the CNAME chain properly

This is where I lost the most time. A single resolve(host, "CNAME") isn't enough, because chains nest. blog.example.com → example.netlify.app → apex-loadbalancer.netlify.com is three hops, and the interesting answer lives at the end.

You also have to separate outcomes that look identical from the outside: no CNAME at all, a CNAME pointing somewhere alive, a CNAME pointing at a name that NXDOMAINs, and a lookup that simply failed. Only the third is a dangling record.

def resolve_chain(resolver, host, depth=6):
    """Walk CNAMEs until an A record, NXDOMAIN, or the depth cap.

    Returns (chain, resolves_to_address, final_target_nxdomain, state) where
    state is live / nxdomain / no_records / error.
    """
    chain, current = [], host

    for _ in range(depth):
        try:
            answer = resolver.resolve(current, "CNAME")
            target = str(answer[0].target).rstrip(".")
            chain.append(target)
            current = target
            continue
        except dns.resolver.NoAnswer:
            pass                      # no CNAME here, try A below
        except dns.resolver.NXDOMAIN:
            return chain, False, bool(chain), "nxdomain"
        except (dns.resolver.NoNameservers, dns.exception.Timeout):
            return chain, False, False, "error"

        try:
            resolver.resolve(current, "A")
            return chain, True, False, "live"
        except dns.resolver.NXDOMAIN:
            return chain, False, bool(chain), "nxdomain"
        except dns.resolver.NoAnswer:
            return chain, False, False, "no_records"
        except (dns.resolver.NoNameservers, dns.exception.Timeout):
            return chain, False, False, "error"

    return chain, False, False, "error"

bool(chain) is doing real work in those NXDOMAIN branches. If the chain is empty, the host itself just doesn't exist and that's boring. If the chain has entries, something in your zone is pointing at a name that no longer exists, and that's the whole game.

That fourth return value isn't how I wrote it the first time. The original collapsed no_records and error into the same "didn't resolve" boolean, which seemed fine until I counted results on a real domain. More on that below.

Step 3: Fingerprint the service

A dangling CNAME only matters if the service on the other end lets a stranger claim the hostname. So I keep a table modelled on the classifications in can-i-take-over-xyz, with three values instead of a boolean.

FINGERPRINTS = [
    {
        "service": "AWS S3",
        "cnames": ["s3.amazonaws.com", "s3-website"],
        "bodies": ["NoSuchBucket", "The specified bucket does not exist"],
        "vulnerable": "yes",
        "note": "bucket name must still be free in the same region",
    },
    {
        "service": "GitHub Pages",
        "cnames": ["github.io", "githubusercontent.com"],
        "bodies": ["There isn't a GitHub Pages site here"],
        "vulnerable": "edge",
        "note": "GitHub has required domain verification since 2021; older orgs can still be exposed",
    },
    {
        "service": "Zendesk",
        "cnames": ["zendesk.com"],
        "bodies": ["Help Center Closed", "this help center no longer exists"],
        "vulnerable": "no",
        "note": "Zendesk blocks re-registration of released subdomains",
    },
    # ...17 services total in the repo
]

That "no" on Zendesk is the reason for the three-way split. help.figma.com CNAMEs to figma.zendesk.com, and a naive scanner that treats every known-service CNAME as a hit will flag it. Nobody's taking that over. Flagging it trains people to ignore your tool, which is worse than not having one.

Step 4: Confirm over HTTP

DNS gets you a lead. The HTTP body gets you proof. Wildcards are why: *.github.io resolves, so a deleted GitHub Pages site never NXDOMAINs and the DNS layer tells you nothing. You have to ask the service.

I checked both of these against live endpoints while writing this:

wf-takeover-demo-9xk22.s3.amazonaws.com  -> HTTP 404, "NoSuchBucket"
wf-takeover-demo-9xk22.github.io         -> HTTP 404, "There isn't a GitHub Pages site here"

def probe_http(session, host, fp, timeout=12):
    for scheme in ("https", "http"):
        try:
            resp = session.get(f"{scheme}://{host}", timeout=timeout, allow_redirects=True)
        except requests.RequestException:
            continue

        body = resp.text[:20000]
        if fp:
            for needle in fp["bodies"]:
                if needle.lower() in body.lower():
                    return resp.status_code, needle
        return resp.status_code, ""
    return None, ""

Note it tries HTTPS first and falls back to HTTP. A lot of abandoned hosts have a dead cert, and if you only speak HTTPS you'll miss them entirely.

Step 5: Score it

Four verdicts, ordered by how much of your evening they deserve:

def classify(finding, fp):
    if fp:
        finding.service, finding.note = fp["service"], fp["note"]

    if finding.target_nxdomain:
        finding.verdict = "DANGLING"
    elif finding.matched_body:
        finding.verdict = "FINGERPRINT" if fp and fp["vulnerable"] != "no" else "REVIEW"
    elif fp and not finding.resolves:
        finding.verdict = "REVIEW"
    else:
        finding.verdict = "OK"

    if fp and fp["vulnerable"] == "no" and finding.verdict in ("DANGLING", "FINGERPRINT"):
        finding.verdict = "REVIEW"
        finding.note += " (service blocks third-party claims)"
    return finding

DANGLING means the CNAME target is gone. FINGERPRINT means the service is serving its "nothing here" page and the service is claimable. REVIEW is everything suspicious that I'm not willing to call. The exit code follows suit: 2 for dangling, 1 for fingerprint, 0 for clean, so you can drop it straight into CI.

Step 6: Prove it actually fires

A detector nobody has seen fire is just a script that prints OK. So there's a --selftest mode that points the whole pipeline at two hostnames where nothing is registered, on services anyone can check:

python takeover_scan.py --selftest

[*] self-test: probing unclaimed hostnames on live services

  PASS  wf-takeover-demo-9xk22.s3.amazonaws.com
        service  AWS S3  (expected AWS S3)
        verdict  FINGERPRINT  (expected FINGERPRINT)
        dns      state=live  resolves=True  target_nxdomain=False
        http     404  matched=NoSuchBucket

  PASS  wf-takeover-demo-9xk22.github.io
        service  GitHub Pages  (expected GitHub Pages)
        verdict  FINGERPRINT  (expected FINGERPRINT)
        dns      state=live  resolves=True  target_nxdomain=False
        http     404  matched=There isn't a GitHub Pages site here

[*] 2/2 passed.
    Both hosts resolve through a service wildcard, so DNS alone says nothing.
    The response body is what flags them.

Look at the dns line on both. state=live, target_nxdomain=False. If you only walked CNAMEs you'd call both of these clean and move on. That's the wildcard problem in two lines of output, and it's why the HTTP stage isn't optional.

It needs no API key, which also makes it the fastest way to tell whether a fingerprint has gone stale. Services rewrite their error pages without announcing it.

Real results

I pointed it at python.org. Public infrastructure, over a decade of history, and a surface wide enough to be interesting without being someone's private estate.

The first thing it prints is the part I nearly got wrong:

[*] python.org: 113 subdomain records across 2 page(s)

Two pages. My first run used --max-pages 1 and cheerfully scanned 100 of the 113 hostnames without complaining about the other 13. Page size is 100. Drain the pages or you're auditing a prefix of your attack surface and calling it a scan.

The full run:

[*] python.org: 113 subdomain records across 2 page(s)
[*] scanning 113 hostnames with 12 workers
    100/113

HOST                       VERDICT   SERVICE         CNAME TARGET
------------------------------------------------------------------------------
blog.python.org            OK        GitHub Pages    python.github.io
blog-ja.python.org         OK        -               ghs46.google.com
devguide.python.org        OK        Read the Docs   readthedocs.io
discuss.python.org         OK        -               python1.hosted-by-discourse.com
docs.python.org            OK        Fastly          dualstack.python.map.fastly.net
education.python.org       OK        Heroku          desolate-laurel-pfbo73zva...herokudns.com
hg.python.org              OK        -               map-lb.nyc1.psf.io
peps.python.org            OK        Fastly          python.map.fastly.net
status.python.org          OK        -               2p66nmmycsj3.stspg-customer.com
translations.python.org    OK        GitHub Pages    python-docs-translations.github.io
ukpatl.uk.python.org       OK        Netlify         glistening-kashata-2a8d56.netlify.app
wwww.python.org            OK        -               -
...

OK=113
[*] wrote python-results.csv

Clean. All 113.

The CSV is where the shape shows up. 54 of the 113 records carry a CNAME, 59 are bare A records. Sixty-seven resolve, and 46 don't. The index spans 2025-09-28 to 2026-09-13, about a year of history for a page and a bit of API calls.

Then I checked that 46 against what the index itself claims:

python takeover_scan.py python.org --status inactive --show-all

[*] python.org: 43 subdomain records across 1 page(s)
OK=43

Forty-three flagged inactive, and all 43 are in my non-resolving set. Zero false positives. The three my scan counted as dead but the index didn't were my bug, not its: _dmarc.python.org is a TXT-only record that was never going to answer an A query, and es.python.org and comunidad.es.python.org both resolved fine when I retried them. I'd been counting "my lookup failed" as "this host is gone."

That's the bug I flagged back in Step 2. One overloaded boolean was hiding three different situations, and it only showed up because a number I could check disagreed with a number someone else had computed. The scanner reports dns_state now.

Twenty-five of those hosts matched a service in the fingerprint table: 11 Fastly, 7 GitHub Pages, 5 Read the Docs, 1 Heroku, 1 Netlify. Every one came back OK, because in every case the service is actively serving the site. That's the table doing its actual job, which is filtering rather than finding.

Look at education.python.org for a second. It CNAMEs to desolate-laurel-pfbo73zvavjs5gdidi59tus8.herokudns.com, and it's live and healthy right now. If that Heroku app were ever deleted without removing the DNS record, that single row is the entire premise of this post, sitting there in a live scan. Nothing is wrong with it today. It's just the shape of the thing you're looking for.

What I noticed

Paging is not optional and the tool won't warn you. --max-pages 1 returned 100 of 113 hosts and printed no complaint. Thirteen hostnames silently outside the scan is exactly the kind of gap that makes a clean result meaningless.
Forty-three of the 113 records are genuinely decommissioned, and the index's own inactive flag matched all 43 exactly. I'd expected that flag to lag reality and it didn't. Good remediation is invisible from the outside, and it's a third of what a historical index contains.
"My DNS lookup failed" and "this host is gone" are different claims, and I'd been conflating them. A TXT-only record like _dmarc never answers an A query. A timeout is a timeout. Three hosts landed in my dead pile that didn't belong there, which on a bigger estate would be a steady trickle of noise nobody chases.
Only 54 of 113 carry a CNAME at all. The rest are bare A records and structurally can't be taken over this way. Your real exposure is usually a fraction of your subdomain count, worth knowing before a long list sends anyone into a panic.
Twenty-five hosts matched a fingerprinted service and every single one came back OK, because the service is actively serving them. The table earns its place by filtering, not by finding. A scanner that flagged all 25 would be useless by Tuesday.
Ten hostnames CNAME to ghs46.google.com, the Blogger custom-domain host, and my table doesn't cover it. Seven more targets are also unrecognized, including python1.hosted-by-discourse.com and the Statuspage and PSF load-balancer names. I've left them out rather than guess at body strings I haven't verified, which is the honest failure mode: the scanner tells you it doesn't know, instead of pretending.
Wildcard DNS is why the HTTP check isn't optional. *.github.io answers for names that were never registered, so the DNS signal is flat and only the response body tells you anything.
education.python.org points at a live Heroku app. Nothing's wrong with it. But that one row is the whole vulnerability class in miniature, and the only difference between it and a finding is whether somebody deletes the app and forgets the DNS.
Every record came back OK, and I'll admit I wanted one embarrassing finding to write up. Does a scanner that finds nothing still earn its keep? Only in the sense a smoke alarm does on the days it stays quiet, which is most of them.

Going further

A few directions I'd take this next.

Run it on a schedule against your own zones and diff the CSV, because the useful signal is a host moving from OK to DANGLING, not the state on any single day. GitHub Actions on a weekly cron does the job in about fifteen lines.

Widen the fingerprint table. Seventeen services covers the common ground, and the can-i-take-over-xyz list is longer than that. The table is plain dicts specifically so adding one is a two-minute pull request.

Feed the DANGLING rows into whatever you use for tickets. A finding that sits in a CSV nobody opens isn't a finding.

And if you'd rather not run the enumeration side yourself, the WhoisFreaks Subdomains API keeps the historical index with first-seen and last-seen dates so you only maintain the DNS logic.

Full source code

Everything's on GitHub: github.com/WhoisFreaks/wf-subdomain-takeover. MIT, one file, two dependencies. The repo includes the full seventeen-service fingerprint table, a sample domains.txt, and the GitHub Actions workflow for the scheduled diff.

If you find a fingerprint that's wrong or missing, open an issue. Service error pages change more often than you'd think, and a stale fingerprint is a false negative.

Monthly Insights Radar: Newly Registered Domain Analytics for August 2026

Sameer Sheikh — Thu, 10 Sep 2026 11:04:47 +0000

Quick Answer

August 2026 recorded 11,640,735 newly registered domains, up 19.5% from July and the first month above eleven million in this series. Germany's .de extension supplied roughly 30% of that growth, but 66% of .de volume landed inside a single five-day batch window. Adjusted for that batch, underlying market growth was closer to 11%. Two other events shape the month: a market-wide ingestion gap on August 8, and a two-window registration campaign visible in .xyz, GMO Internet and Japan.

Executive Summary

The Newly Registered Domain (NRD) landscape in August 2026 recorded 11,640,735 total registrations, a +19.5% expansion month over month from July's 9,742,358, and the first reading the series has posted above eleven million. Roughly 30% of that growth traces to a single extension.

The .de Deluge lifted Germany's country-code namespace from 119,703 registrations to 690,812 (+571,109, +477.1%) and from rank #16 to rank #3. The daily chart makes clear what kind of event this was. A baseline running ~3.3k to ~31.7k/day and averaging ~9,000/day was broken by a flat ~90k/day plateau across August 13 to 17, five days that on their own carry 66% of the extension's monthly volume, with four German registrars entering the Top-20 simultaneously to process it. Strip the plateau out and .de lands near 234,000, a ~9,000/day run rate: still more than double July's, but nowhere near the podium. Every dependent statistic in this report, from the ccTLD split to the TLD pie, should be read with that qualification attached.

The rest of the month was genuinely strong, and two further patterns shape it. The August 8 Blackout cut aggregate volume to a month-low ~126,000 on a Saturday, roughly one-third of the daily average, with .com at ~17.5k, the United States at ~16.9k, GoDaddy at ~7.0k and Namecheap at ~5.8k, all month lows. An August 9 rebound then carried the market to ~551,000 and .com to its monthly high of ~189.4k.

Separately, the Twin-Window Campaign shows up identically in three places. .xyz (+26.0% to 946,600), GMO Internet Group (+30.4% to 933,005, reclaiming rank #3) and Japan all ran hot from August 5 to 10 and again from August 18 to 22, then collapsed to near nothing for the final nine days.

On the competitive board, Namecheap closed to within 50,204 registrations of GoDaddy, the narrowest top-two gap the series has recorded and tighter than July's 79,432, while Iceland faded -25.7% to 550,237. Data integrity held where it matters most: registrar coverage stayed at 97.0% "Cleaned" and address coverage slipped to 50.6%, while usable contact data nearly doubled to 14.8% of records. That last move is an artifact of the .de cohort arriving with contact fields intact, not a change in redaction policy.

Key Highlights

TLD and Market Dynamics

The .de Deluge: .de rose +477.1% from 119,703 to 690,812 registrations and from rank #16 to #3, the largest single-month move in the history of this series. It is not organic demand. Roughly 456,700 registrations landed across the flat August 13 to 17 plateau, 66% of the monthly total in five days, against a surrounding baseline averaging ~9k/day.
The August 8 Blackout: Aggregate "Newly" volume fell to ~126,000 on August 8 against a monthly average of ~375,500. Month lows were recorded simultaneously by .com, .top, the United States, Iceland, China, Germany, GoDaddy, Namecheap, Dynadot and Spaceship: ten of the fifteen category charts. Only the five batch-driven or campaign-driven series (.de, .cn, .xyz, Japan and GMO Internet) show no month low on that date, making this the broadest single-day data event the series has seen.
The Twin-Window Campaign: .xyz advanced +26.0% to 946,600 registrations on two discrete bursts, August 5 to 10 and August 18 to 22, together 72% of its monthly volume. After the second window the extension fell to a ~0.5k to 14k floor for the final nine days. Its registrar and country mirrors, GMO Internet Group and Japan, trace the same two windows almost day for day.
.cn's One-Day Jump: .cn gained +64.4% to 348,187 registrations and rose from rank #8 to #5. Roughly 83,700 of that, 24% of the month, arrived on August 18 alone against a ~3k to 17k baseline. .cn is one of three Top-5 extensions that did not dip on August 8, alongside .de and .xyz.
ccTLD Rebalance: Country-code space expanded to 27.4% of all NRDs (3,188,479, +72.4%) while gTLDs eased to 72.6% (8,452,256, +7.1%), an 8.4-point swing and the largest in the series. The move is led by .de's advance and by .cn +64.4%, so the headline shift is concentrated in a handful of extensions rather than a broad regional adoption signal.

Geographic and Registrar Trends

The Tightest Top-Two Yet: GoDaddy added just +0.3% to 1,192,684 while Namecheap rose +3.0% to 1,142,480, compressing the leader's margin to 50,204 registrations, under 4.3% of GoDaddy's volume and the narrowest gap the series has recorded. Their combined share of Top-20 registrar volume fell to 29.0% from July's 32.0%.
The German Registrar Cohort: Four registrars entered the Top-20 at once: Domainers Registrar AG (199,755, rank #11), EliteDomains GmbH (132,790, #17), Nomino GmbH (124,856, #19) and InternetX GmbH (116,865, #20). Their combined 574,266 registrations are 7.1% of Top-20 registrar volume. All four are German-market names and all four appear in the same month as the .de Deluge, which is the clearest available evidence that the event ran through a coordinated registrar channel.
GMO Reclaims the Podium: GMO Internet Group (onamae.com) rose +30.4% to 933,005 registrations and moved from rank #4 to #3, with 75% of its volume inside the two Twin-Window blocks and a month-end floor near ~1.8k/day. Its country mirror diverged: Japan eased -5.5% to 509,410, so a growing share of GMO's registrations is no longer resolving to a Japanese registrant address.
The Iceland Fade: Iceland fell -25.7% from 740,960 to 550,237 registrations, its weakest reading in months, and its pie share compressed from 16.1% to 10.7%. The daily chart shows a clean downward drift, roughly 22k to 28k/day in the first week against 13k to 16k in the last, rather than a single break. That makes this the most orderly decline of any large geography this month.
Germany's Arrival and Broad Asian Recovery: Germany climbed +186.2% to 247,133 registrations and rank #5, entering the Top-5 country pie for the first time in the series. Alongside it, China rebounded +34.0% to 403,409, Hong Kong rose +46.9% and South Korea +12.8%, reversing July's Asian correction, while Portugal (67,688), Russia (43,809) and Indonesia (31,951) entered the Top-20 as Poland, Australia and Italy dropped out.

Data Quality and Intelligence

Contact Coverage Nearly Doubles: Usable contact details jumped to 14.8% of records (1,717,788) from July's 7.6%, a +980,160 absolute increase and by far the largest single-month move this dimension has recorded. The "Newly_Cleaned" daily line locates the cause precisely: it spikes to ~213k on August 4 and holds ~106k to 120k across August 13 to 17, exactly the .de Deluge windows. This is a composition effect from one cohort, not a change in redaction behavior.
Registrar Coverage Holds: Registrar metadata registered 97.0% "Cleaned" (11,296,406 of 11,640,735 records) against July's 97.1%, a 0.1-point change that leaves registrar-based segmentation the most reliable analytical lens in the dataset. That matters more than usual in a month whose headline number depends on correctly attributing a batch event.
Address Coverage Slips Below the Coin Flip Margin: Usable address data eased to 50.6% of records (5,886,108 cleaned, 5,754,627 redacted) from July's 53.4%, a 2.8-point decline that continues the give-back begun last month and leaves geo-segmentation with almost no margin above an even split.

Top 20 TLDs - Full Period

The TLD market in August 2026 grew hard and unevenly. The Top-20 aggregate expanded +19.5% to 8,733,934 registrations, but the distribution of that growth is lopsided in a way no previous month matches. .de supplies 571,109 of the 1,425,635 increase, or 40%, from a standing start at rank #16. Beneath the anomaly the board is healthier than July's: .com returned to growth, .xyz recovered most of its June peak, .cn and .vip advanced, and the bottom of the roster turned over toward country-code and regional extensions.

Comparison with July 2026

Newly added in August (entered Top-20)

.co to 139,743 (re-entry after a one-month absence, ranked #14)
.in to 106,027 (re-entry after a one-month absence, ranked #19)
.asia to 101,623 (new entry, ranked #20)

Removed in August (dropped out of Top-20)

.icu was 95,353 in July (ranked #18), not in August Top-20
.br was 94,868 in July (ranked #19), not in August Top-20
.click was 91,157 in July (ranked #20), not in August Top-20

Biggest UPs (July to August)

.de: 119,703 to 690,812 (+571,109, +477.1%) | rank 16 to 3
.cn: 211,764 to 348,187 (+136,423, +64.4%) | rank 8 to 5
.vip: 108,138 to 137,209 (+29,071, +26.9%) | rank 17 to 15
.xyz: 751,496 to 946,600 (+195,104, +26.0%) | rank 2 to 2
.site: 157,060 to 185,346 (+28,286, +18.0%) | rank 9 to 10
.ru: 147,654 to 170,151 (+22,497, +15.2%) | rank 11 to 11
.com: 3,379,656 to 3,780,477 (+400,821, +11.9%) | rank 1 to 1
.net: 213,811 to 233,700 (+19,889, +9.3%) | rank 7 to 9

Biggest DOWNs (July to August)

.shop: 374,120 to 293,099 (-81,021, -21.7%) | rank 4 to 6
.info: 139,141 to 129,274 (-9,867, -7.1%) | rank 12 to 17
.app: 122,459 to 118,324 (-4,135, -3.4%) | rank 15 to 18
.cc: 149,392 to 147,272 (-2,120, -1.4%) | rank 10 to 12
.online: 242,883 to 242,838 (-45, -0.0%) | rank 6 to 8

Leaderboard (absolute counts)

What this says:

.com recovered +11.9% to 3,780,477 registrations, reversing July's softening and setting a new high for the series. The recovery is broad-based rather than event-driven. The second half of the month ran a visibly higher floor (~140k to 160k/day) than the first (~85k to 131k/day), with the only anomalous readings being the August 8 trough and the August 9 rebound.
The .de Deluge is the month's dominant fact and its largest interpretive risk. At 690,812 registrations .de arrives at rank #3 from outside the top fifteen. But 66% of that volume landed on five days, the surrounding baseline averages ~9k/day, and four German registrars appeared in the Top-20 in the same month. Treat the placement as the product of a batch or promotional event. Model September from the ~6k to 9k post-plateau floor, not from the monthly total.
.xyz regained +26.0% to 946,600 registrations and holds rank #2, retaining the runner-up slot it has occupied since June. Its own shape is the Twin-Window Campaign: roughly 72% of volume inside August 5 to 10 and August 18 to 22, then a ~0.5k to 14k floor from August 23 onward. This is the second consecutive month in which .xyz has posted a large headline number on top of a collapsing exit run rate.
.top held its ground at 427,684 (+9.2%), keeping a place in the Top-5 pie. Its daily chart is the choppiest in the set: three separate one-day peaks near ~29k (August 9, August 21, August 26) against a ~6k to 17k baseline, and two collapses to ~3.6k and ~1.5k.
The bottom of the roster rotated toward country-code and regional space. .icu, .br and .click exited while .co, .in and .asia entered. The only meaningful decliner among established extensions was .shop, whose -21.7% retreat to 293,099 ends the two-month .shop Ascent that defined June and July.

Share of Top 5 TLDs - Pie View

The top five TLDs together contribute 70.9% of all newly registered domains in August 2026 within the Top-20 cohort. "Others" (ranks #6 to #20) make up the remaining 29.1%.

.com captures 43.3% of Top-20 TLD volume, down from July's 46.2% despite growing +11.9% in absolute terms, because the cohort around it expanded faster. It remains roughly 4.0 times the size of the next extension.
.xyz holds 10.8%, up slightly from July's 10.3%, confirming that the extension's structural gain since June has held even as its month-end run rate has not.
.de takes 7.9%, up from 1.6% in July. This is the single most dramatic share movement the series has recorded, and also the least durable. On the post-plateau daily floor .de would occupy roughly 3% of the cohort.
.top follows at 4.9%, down from 5.4%, a share loss produced entirely by cohort growth rather than by any weakness in its own +9.2% advance.
.cn rounds out the top five at 4.0%, up from 2.9%, entering the pie for the first time since the spring on the strength of a single August 18 event.
Long-tail market presence: The "Others" bucket at 29.1% was effectively flat against July's 29.5%, and .shop, which held 5.1% of the pie last month, fell out of the Top-5 entirely. Concentration therefore rose this month, but it rose because of one anomalous extension. On an event-adjusted basis the long tail is broadly where July left it.

Daily Dynamics - Top 5 TLDs

.com

High-floor operating band (~85k to 160k): .com traded coherently all month, with first-half weekdays clustered between ~108k and ~131k and second-half weekdays stepping up to ~140k to 160k.
Monthly high on August 9 (~189.4k): The peak is the rebound day immediately after the blackout, roughly 1.2 times the extension's normal ceiling. The strongest non-anomalous reading came in at ~160.0k on August 26.
The August 8 Blackout (~17.5k): .com's month low is roughly one-fifth of its weekend floor and one-seventh of a normal weekday, a break no demand pattern produces and the deepest relative shortfall .com has recorded in the series.
Clean weekly cyclical troughs on days 2 to 3, 16 to 17, 23 to 24 and 30 to 31: Setting the blackout aside, each Sunday and Monday pair dropped into the ~85k to 107k band before recovering. The month closed near ~106k with a materially higher weekday run rate than it opened.

.xyz

Two elevated windows and a collapse (~0.5k to 98.7k): .xyz ran ~55k to 98.7k/day across August 5 to 10, cooled to a ~15k to 29k middle band, ran hot again at ~56k to 66.6k across August 18 to 22, then fell to ~0.5k to 14k for the final nine days.
Monthly high on August 9 (~98.7k): The peak sits inside the first window rather than standing alone, with ~79.6k on August 7 and ~72.4k on August 5 beside it. This is a sustained campaign block, not a one-day burst.
Concentration: The two windows together carry roughly 72% of .xyz's 946,600 registrations across 11 of 31 days, which is how the extension posts +26.0% growth while exiting the month below 5k/day.
Month low on August 25 (~0.5k): The floor after the second window is lower than anything .xyz recorded in July, and the final week held ~4.0k to 8.2k. If sustained, that run rate implies a very large September decline.

.de

One batch plateau against a flat baseline (~3.3k to 95.1k): Across the 26 non-plateau days .de traded between ~3.3k and ~31.7k, averaging ~9,000/day. The five plateau days are the entire story of its rank #3 placement.
Monthly high on August 13 (~95.1k): The plateau opens at its peak, roughly ten times the surrounding baseline, and no reading outside August 13 to 17 exceeds ~31.7k.
The August 13 to 17 plateau (~89.7k to 95.1k): Five consecutive days within a ~5.4k range. That flatness is itself diagnostic, since organic daily demand does not hold within 6% for five days at ten times its own baseline. These five days contribute roughly 456,700 registrations, or 66% of the monthly total.
Complete reversion at the close: From August 25 onward .de held ~5.6k to 8.7k, closing the month at ~6.6k, below its own August 1 reading. Setting the plateau aside, the extension's underlying run rate is ~9,000/day against July's ~3,900/day: real growth, but a fraction of the headline.

.top

Choppy mid-volume profile with no weekly cadence (~1.5k to 29.3k): .top alternated between a ~6k to 17k baseline and repeated isolated jumps, with no seven-day rhythm visible anywhere in the series.
Three near-equal peaks (~26.5k to 29.3k): The monthly high came on August 26 (~29.3k), effectively tied with August 9 (~29.1k) and followed by August 21 (~26.5k), a roughly weekly cadence of one-day bursts rather than a sustained elevation.
Two separate collapses: .top hit ~3.6k on August 8 with the rest of the market, then ~1.5k on August 25, a Tuesday on which no other chart in the set shows a shortfall. That extension-specific gap was immediately followed by its monthly high.
Mid-month soft patch: August 11 to 17 held a subdued ~6.1k to 8.5k, the weakest sustained stretch of the period. The month closed near ~11.0k, roughly in line with its own baseline.

.cn

Low, spiky baseline (~3.0k to 16.9k, excluding one day): For thirty of thirty-one days .cn traded in a narrow low band, with typical readings between ~4k and ~13k and no weekly pattern.
The August 18 spike (~83.7k): The monthly high sits at roughly six times the surrounding baseline and delivers 24% of .cn's monthly volume in a single day, collapsing to ~10.4k the next day. This is the same date on which .xyz, GMO Internet and Japan all opened their second window, but at a far greater relative amplitude.
No August 8 shortfall: Along with .de and .xyz, .cn read ~12.3k on August 8, above its own monthly baseline, placing it outside the blackout entirely and pointing to a separate ingestion path for the extension.
Firmer second half: After August 19 .cn held ~7.2k to 16.9k against a first-half range nearer ~3k to 12k, a modest step-up that underpins perhaps a third of its +64.4% monthly gain on non-anomalous volume.

Top 20 Countries - Full Period

The country landscape in August 2026 expanded +11.3% to 5,133,486 registrations, the mildest cohort growth of the three dimensions and a useful check on the TLD numbers. If the .de Deluge had been driven by identifiable German registrants, the country cohort would have grown far faster. Instead Germany added 160,782 registrations against .de's +571,109, meaning roughly 72% of the .de event did not resolve to a German registrant address. Beneath the leaders, Asian markets reversed July's correction almost across the board and three new geographies entered the table.

Comparison with July 2026

Newly added in August (entered Top-20)

Portugal to 67,688 (new entry, ranked #13)
Russia to 43,809 (new entry, ranked #16)
Indonesia to 31,951 (re-entry after a one-month absence, ranked #20)

Removed in August (dropped out of Top-20)

Poland was 29,449 in July (ranked #17), not in August Top-20
Australia was 27,615 in July (ranked #18), not in August Top-20
Italy was 26,252 in July (ranked #19), not in August Top-20

Biggest UPs (July to August)

Germany: 86,351 to 247,133 (+160,782, +186.2%) | rank 10 to 5
Albania: 52,932 to 96,773 (+43,841, +82.8%) | rank 12 to 11
Hong Kong: 26,175 to 38,442 (+12,267, +46.9%) | rank 20 to 18
China: 301,047 to 403,409 (+102,362, +34.0%) | rank 4 to 4
Netherlands: 46,071 to 61,730 (+15,659, +34.0%) | rank 13 to 14
Canada: 110,242 to 129,428 (+19,186, +17.4%) | rank 8 to 8
Turkey: 40,357 to 46,911 (+6,554, +16.2%) | rank 14 to 15
United States: 1,949,448 to 2,233,030 (+283,582, +14.5%) | rank 1 to 1

Biggest DOWNs (July to August)

Iceland: 740,960 to 550,237 (-190,723, -25.7%) | rank 2 to 2
France: 114,319 to 103,431 (-10,888, -9.5%) | rank 7 to 10
Japan: 538,930 to 509,410 (-29,520, -5.5%) | rank 3 to 3

Leaderboard (absolute counts)

What this says:

Total (Top-20) rose from 4,613,954 in July to 5,133,486 in August, +519,532 (+11.3%), with only three geographies declining. The breadth is notable: fourteen of the seventeen carry-over countries grew, the widest simultaneous advance the country table has posted this year.
The United States added +14.5% to 2,233,030 registrations and lifted its pie share to 43.5% from 42.3%, growing faster than the cohort for the first time in three months. Its daily chart is the market's cleanest weekly rhythm, with Sunday and Monday troughs near ~50k to 56k against midweek readings of ~70k to 98k, interrupted only by the August 8 low of ~16.9k.
The Iceland Fade is the month's largest genuine decline: -25.7% to 550,237 registrations and a pie share down 5.4 points to 10.7%. Unlike the Japanese moves of recent months there is no window structure here, just a steady week-on-week drift from a ~22k to 28k opening band to ~13k to 16k at the close.
Germany's arrival at #5 with 247,133 registrations is the country-side signature of the .de Deluge, and its daily chart carries the same plateau: ~20.3k to 24.5k across August 13 to 17 against a ~2.3k to 7.5k baseline, plus an earlier bump to ~19.6k on August 4. That the country total captures only 28% of the .de increase is itself the most useful finding. The batch registrants were overwhelmingly not identifiable as German.
Asian markets reversed July's correction: China +34.0%, Hong Kong +46.9%, South Korea +12.8% and Indonesia back in the table, while Japan slipped only -5.5% despite its Twin-Window profile. Set against France -9.5% and the exits of Poland, Australia and Italy, the month's regional story is a clear rotation from Western Europe toward East and Southeast Asia.

Share of Top 5 Countries - Pie View

The top five countries together contribute 76.8% of all newly registered domains in August 2026 within the Top-20 cohort. "Others" (ranks #6 to #20) make up the remaining 23.2%.

United States leads at 43.5% of Top-20 registrations, up from July's 42.3%, and this time on genuine volume growth of +14.5% rather than on the cohort shrinking around it.
Iceland holds 10.7%, down sharply from 16.1%, the largest share loss of any geography this month and the direct expression of the Iceland Fade.
Japan takes 9.9%, easing from 11.7%, a third consecutive month of compression, though the underlying -5.5% volume decline is far shallower than the share move suggests.
China captures 7.9%, up from 6.5%, recovering the ground it lost in July and restoring the geography to its spring weight.
Germany rounds out the top five at 4.8%, up from 1.9%, entering the Top-5 country pie for the first time in the series, a placement that will not survive September unless the .de channel reopens.
Implication: August returns to a four-market geography with a batch-driven fifth. The interpretive question for September is whether Iceland's fade continues toward the 400k range, whether China's recovery holds, and whether Germany reverts to its 1.9% baseline share. Albania, which debuted at #12 last month and grew a further +82.8% to 96,773, has now delivered the second month of confirmation that July's report called for, and should be treated as a real market rather than a provisional entry.

Daily Dynamics - Top 5 Countries

United States

Wide but coherent band (~50k to 108k): US daily registrations ran ~70k to 98k on typical weekdays with Sunday and Monday softening into the ~50k to 56k range, the most regular seven-day cadence in the entire chart set.
Monthly high on August 9 (~108.3k): The peak is the post-blackout rebound. The strongest organic readings came at ~98.3k on August 13, ~96.9k on August 29 and ~94.8k on August 28.
The August 8 Blackout (~16.9k): The month low sits at roughly one-third of a normal weekend reading and one-fifth of a weekday, matching the aggregate market's shortfall almost exactly.
Firm close: After the August 23 and 24 trough the series ran ~63k to 96.9k through August 29 before the routine month-end weekend dip to ~56k, exiting August with a weekday floor visibly above July's.

Iceland

A steadily declining band (~4.4k to 31.9k): Iceland opened the month at ~22k to 28.6k/day and closed it at ~12.7k to 16.2k, with the intervening weeks stepping down in sequence, the clearest monotone drift of any large geography in the set.
Monthly high on August 9 (~31.9k): As elsewhere, the peak is the rebound day. The strongest pre-blackout reading was ~28.6k on August 4.
The August 8 Blackout (~4.4k): Iceland's month low is roughly one-fifth of its opening-week average, confirming the geography sits squarely inside the affected ingestion path.
Orderly close: The final week held ~9.5k to 16.2k with a single soft reading on August 28, ending August near ~12.7k. There is no window structure and no single break. This is a genuine demand decline, and the -25.7% monthly figure should be taken at face value.

Japan

Two windows and a low floor (~2.3k to 65.6k): Japan ran ~27.2k to 65.6k/day across August 5 to 10, dropped to a ~2.3k to 4.3k floor from August 11 to 17, ran ~14.5k to 52.0k across August 18 to 23, then returned to ~3.2k to 6.2k for the final eight days.
Monthly high on August 9 (~65.6k): The peak sits inside the first window with ~52.0k on August 5 and ~44.7k on August 7 beside it. The second window peaked at an almost identical ~52.0k on August 18.
Concentration: The two windows together carry roughly 82% of Japan's 509,410 registrations across 12 of 31 days, a tighter concentration than either of the two prior months, even though the monthly total barely moved.
Interpretation: Japan's volume is now almost entirely episodic. A geography that spends nineteen days of the month near ~3k/day and produces four-fifths of its total in two blocks is not showing organic demand at the 500k level. September should be modelled from the ~3k to 6k floor with any window volume treated as a separate event.

China

Spiky mid-volume profile (~1.8k to 24.7k): China traded without a stable floor, alternating between ~7k to 12k readings and repeated jumps to roughly double that, with no weekly cadence.
Monthly high on August 29 (~24.7k): Unusually for this month, China's peak is not the rebound day. August 29 edged past ~23.4k on August 5 and ~23.2k on August 9, with a fourth distinct spike at ~21.3k on August 21.
The August 8 Blackout (~1.8k): China's month low is the deepest relative shortfall of any Top-5 country, roughly one-fifth of its own baseline, and the only reading below 5k in the series.
Rising floor: The inter-spike floor sat near ~9k to 18k across the second half against ~6.5k to 13k in the first, which is what produces the +34.0% monthly recovery and moves China's pie share back to 7.9%.

Germany

Baseline plus two batch windows (~1.8k to 24.5k): For twenty-four of thirty-one days Germany traded between ~1.8k and ~7.5k. The remaining seven days produce its rank #5 placement.
Monthly high on August 17 (~24.5k): The peak closes the August 13 to 17 plateau, which held a remarkably flat ~20.3k to 24.5k, the same five-day block and the same flatness visible in the .de chart.
The August 4 and 5 window (~19.6k, ~14.5k): Germany's first burst is a two-day event at roughly seven times its own baseline, well ahead of the mid-month plateau and unmatched by any comparable move in the neighbouring Western European markets.
Complete reversion at the close: From August 18 onward Germany held ~3.4k to 6.7k, closing the month at ~3.4k, below its own August 1 reading. On that floor the geography reverts to roughly its July rank.

Top 20 Registrars - Full Period

The registrar landscape in August 2026 is where the month's two structural stories are easiest to separate. The Top-20 aggregate rose +11.9% to 8,041,860 registrations, but the composition changed more than the total. Four German registrars entered simultaneously with a combined 574,266 registrations, GMO Internet Group reclaimed #3 on the Twin-Window Campaign, and at the very top Namecheap closed to within 50,204 registrations of GoDaddy, the narrowest margin the series has recorded. Neither leader grew meaningfully. The entire cohort expansion came from behind them.

Comparison with July 2026

Newly added in August (entered Top-20)

Domainers Registrar AG: 199,755 (new entry, ranked #11)
EliteDomains GmbH: 132,790 (new entry, ranked #17)
Nomino GmbH: 124,856 (new entry, ranked #19)
InternetX GmbH: 116,865 (new entry, ranked #20)

Removed in August (dropped out of Top-20)

Wix.com Ltd was 78,894 in July (ranked #16), not in August Top-20
Gransy, s.r.o was 78,327 in July (ranked #17), not in August Top-20
Gname.com Pte. Ltd was 73,542 in July (ranked #19), not in August Top-20
Realtime Register B.V. was 62,690 in July (ranked #20), not in August Top-20

Biggest UPs (July to August)

Beijing Xinnet Digital Information Technology: 88,343 to 199,969 (+111,626, +126.4%) | rank 15 to 10
Dominet (HK) Limited: 76,238 to 139,797 (+63,559, +83.4%) | rank 18 to 15
GMO Internet Group (onamae.com): 715,662 to 933,005 (+217,343, +30.4%) | rank 4 to 3
Cloudflare, Inc: 401,409 to 453,406 (+51,997, +13.0%) | rank 7 to 7
Hostinger Operations, UAB: 430,472 to 478,304 (+47,832, +11.1%) | rank 6 to 6
Tucows, Inc: 158,014 to 172,187 (+14,173, +9.0%) | rank 12 to 14
NameSilo, LLC: 290,995 to 315,338 (+24,343, +8.4%) | rank 8 to 8
Porkbun, LLC: 183,222 to 195,487 (+12,265, +6.7%) | rank 10 to 12

Biggest DOWNs (July to August)

PDR Ltd. (PublicDomainRegistry.com): 136,755 to 128,328 (-8,427, -6.2%) | rank 13 to 18
Dynadot Inc: 915,698 to 886,583 (-29,115, -3.2%) | rank 3 to 4
Squarespace Domains LLC: 271,201 to 262,791 (-8,410, -3.1%) | rank 9 to 9

Leaderboard (absolute counts)

What this says:

Total volume (Top-20) rose from 7,187,836 in July to 8,041,860 in August, +854,024 (+11.9%). Accounting for the four July registrars that dropped out (a combined 293,453 registrations) and the four German registrars that replaced them (574,266), the carry-over registrars grew by roughly +573,211. GMO Internet supplies 217,343 of that, leaving about +355,868 spread across the remaining sixteen carry-over names.
The tightest top-two in the series: GoDaddy added only +0.3% to 1,192,684 and Namecheap +3.0% to 1,142,480, leaving a gap of 50,204 registrations. Their combined share of Top-20 volume fell to 29.0% from 32.0%, the lowest duopoly concentration the series has recorded. On current trajectories the top two could swap positions in September.
The German Registrar Cohort is the registrar-side proof of the .de Deluge. Domainers Registrar AG arriving directly at #11 with 199,755 registrations, alongside EliteDomains GmbH, Nomino GmbH and InternetX GmbH, is not organic competitive growth. Four previously absent registrars from one national market do not enter a Top-20 in the same month by coincidence. Their combined 574,266 registrations, plus Ionos SE's 137,801, come to 712,067, comfortably enough to account for .de's 690,812, and the clearest indication that the extension's surge was processed through a small, identifiable set of channels.
GMO reclaims the podium with +30.4% to 933,005 registrations, and its chart is the Twin-Window Campaign in its purest form: ~71k to 97k/day across August 5 to 10, ~57k to 70k across August 18 to 22, and a collapse to ~1.8k to 15.2k afterwards, closing the month at ~1.8k. Roughly 75% of its volume sits inside those eleven days.
Asian mid-tier registrars advanced hard while European resellers churned out. Beijing Xinnet rose +126.4% to 199,969 and Dominet (HK) +83.4% to 139,797, against the exits of Wix.com, Gransy, Gname.com and Realtime Register. Cloudflare +13.0% and Hostinger +11.1% continued their steady infrastructure-channel growth, the most consistent trend line in the registrar table across the last four months.

Share of Top 5 Registrars - Pie View

Within the top five registrars, with "Others" representing ranks #6 to #20, the August mix is:

GoDaddy.com, LLC: 14.8%
Namecheap, Inc: 14.2%
GMO Internet Group (onamae.com): 11.6%
Dynadot Inc: 11.0%
Spaceship, Inc: 8.1%
Others: 40.2%

Implication: The top five together hold 59.8% of Top-20 registrar volume, down from July's 63.4%, and the "Others" bucket at 40.2% is the largest it has been in the series, a direct consequence of four new entrants arriving at once in the #11 to #20 range. At the top, 0.6 points now separate GoDaddy from Namecheap and only 3.8 points separate #1 from #4, the flattest podium the series has recorded. Read carefully, this is two different stories in one chart: genuine competitive compression among the leaders, and an artificial dispersion into the long tail created by the German cohort. On an event-adjusted basis the "Others" share would sit closer to 36%.

Daily Dynamics - Top 5 Registrars

GoDaddy.com, LLC

Stable operating band (~24k to 57k): GoDaddy held the steadiest profile in the Top-5, with most weekdays between ~32k and ~43k and Sunday and Monday softening into the ~24k to 27k range every week.
Monthly high on August 29 (~57.1k): Unusually, GoDaddy's peak is not the rebound day. August 29 edged out ~52.5k on August 9, and no other reading exceeded ~43k.
The August 8 Blackout (~7.0k): The month low is roughly one-quarter of a normal weekend reading, the deepest single-day break in GoDaddy's chart history and the clearest registrar-level fingerprint of the event.
Weekly cyclical troughs on days 2 to 3, 10, 16 to 17, 23 to 24 and 30 to 31: GoDaddy displays the seven-day cadence as cleanly as .com does, and the month closed near ~26.9k, a flat exit consistent with its near-zero +0.3% monthly change.

Namecheap, Inc

Broad operating band (~23k to 54k): Namecheap ran wider than GoDaddy, with typical weekdays between ~32k and ~42k and a pronounced weekend softening into the ~23k to 29k range.
Monthly high on August 9 (~54.4k): The rebound day produced the largest single reading, with three near-equal secondary highs at ~47.8k on August 18, ~47.5k on August 4 and ~47.4k on August 26, all outside the anomaly and all substantially above GoDaddy's non-peak ceiling.
The August 8 Blackout (~5.8k): Namecheap's month low is the deepest of any registrar in the set relative to its weekday baseline, roughly one-quarter of a normal weekend day.
Softer close: The final two days eased to ~26.5k and ~25.4k, slightly below the monthly average, which tempers the read on Namecheap's approach to the #1 slot without undermining the +3.0% monthly gain.

GMO Internet Group (onamae.com)

Two windows and a collapse (~1.8k to 97.4k): GMO ran ~54k to 97.4k/day across August 5 to 10, cooled to ~11.3k to 31.5k across August 11 to 17, ran ~57k to 70.1k across August 18 to 22, then fell to ~1.8k to 15.2k for the final nine days.
Monthly high on August 9 (~97.4k): The peak sits inside the first window, with ~86.8k on August 7 and ~71.2k on August 5 immediately around it. The second window peaked at ~70.1k on August 18.
Concentration: Roughly 75% of GMO's 933,005 registrations landed inside the two windows, spanning 11 of 31 days. The registrar's own baseline, the days outside both windows, averages under ~12k/day.
Interpretation: GMO closed August at ~1.8k, its lowest daily reading of the month and below its post-unwind July floor. Its +30.4% monthly gain and return to rank #3 therefore describe campaign throughput rather than a recovered book of business, and September volume should be modelled from the post-August-23 floor.

Dynadot Inc

Rhythmic mid-range band (~8.8k to 39.1k): Dynadot traded between roughly ~20k and ~35k on most days, with the swings driven by the weekly cycle rather than by campaign activity, the most conventional profile in the Top-5.
Monthly high on August 9 (~39.1k): The rebound day narrowly beat ~38.2k on August 28, with ~35.3k on August 5 as the third-highest reading.
The August 8 Blackout (~8.8k): The month low is roughly one-half of a normal weekend reading, a real shortfall but the shallowest of the four affected registrars, suggesting Dynadot sits only partly inside the affected path.
Measured close: The final week eased into a ~16.9k to 28.4k range, ending August near ~16.9k, an exit rate below the monthly average and consistent with the -3.2% monthly decline that cost Dynadot the #3 slot.

Spaceship, Inc

Mid-range operating band (~4.8k to 37.6k): Spaceship held a ~15k to 27k range on most days, punctuated by one-day bursts consistent with its established pattern of concentrated activity.
Monthly high on August 9 (~37.6k): The rebound day produced the peak, with ~30.8k on August 4, ~30.7k on August 18 and ~26.9k on August 13 as secondary highs, each a single-day event against a surrounding baseline near ~20k.
The August 8 Blackout (~4.8k): Spaceship's month low sits at roughly one-quarter of its baseline, placing it firmly inside the affected group alongside GoDaddy, Namecheap and Dynadot.
Softening close: The final three days ran ~19.8k, ~16.2k and ~13.6k, a visible step down from the monthly average and the weakest month-end of the Top-5. Worth watching, since Spaceship's +4.1% monthly gain rests on a mid-month plateau it did not hold.

Cleaned vs Redacted - Data Quality Snapshot

Coverage rates describe how much of each WHOIS field arrives usable rather than redacted. They set the ceiling on what any analysis of this dataset can support, so they are reported here alongside the volume figures rather than as an appendix. Full field-level definitions are available in the WHOIS database documentation.

Registrar Details

Total records: 11,640,735
Cleaned: 11,296,406 (97.0%). Registrar data held within 0.1 points of July's 97.1%, extending a multi-month run above 97% and absorbing a +19.5% volume increase without any degradation.
Redacted: 344,329 (3.0%)
Takeaway: Registrar metadata remains functionally near-complete and continues to provide the strongest analytical backbone in the dataset. That is what makes it possible to attribute the .de Deluge to a specific registrar cohort rather than merely observing an unexplained TLD spike.

Holding a 97% clean rate through a nineteen-percent volume expansion, including a single 742,000-record day, indicates that the ingestion pipeline scaled cleanly even where daily counts did not. The 0.1-point change is well inside ordinary month-to-month variation in registrant mix. Registrar-based segmentation, event attribution and share analysis therefore remain reliable at the highest confidence tier. In a month where the headline number is inflated by one batch event, cross-dimensional pivots anchored on registrar data are the only sound way to size the underlying market. With redaction at 3.0%, the gap between raw and cleaned counts stays narrow enough that month-over-month trend comparisons need no adjustment.

Address Details

Total records: 11,640,735
Cleaned: 5,886,108 (50.6%). A 2.8-point decline from July's 53.4%, a second consecutive give-back that leaves usable address coverage at its lowest level in several months.
Redacted: 5,754,627 (49.4%)
Takeaway: Address data now sits barely above an even split, so geo-segmentation based on registrant addresses remains viable but has lost all of the margin it briefly held in June.

The decline is composition-driven and directly traceable. The .de batch cohort added 571,109 records while Germany's country attribution grew by only 160,782, meaning the large majority of those registrations carried no usable address. A single event of that size is enough to move the aggregate coverage rate by more than two points. Cross-reference address-based geo-segmentation with registrar and TLD signals for the 49.4% of records that remain redacted, and be especially careful this month not to read the country table as a complete picture, since roughly 72% of the .de increase is invisible in it. The practical consequence is that coverage metrics are sensitive to registrant mix, which argues for reading them alongside the volume story rather than as an independent quality signal.

Contact Details

Total records: 11,640,735 evaluated for contact fields
Redacted: 9,922,947 (85.2%). Contact redaction fell 7.2 points from July's 92.4%, by far the largest single-month improvement this dimension has recorded.
Cleaned: 1,717,788 (14.8%) carry usable contact details, up from 7.6% in July, an absolute increase of +980,160 records.
Takeaway: Direct contact information is still the most privacy-protected segment of the dataset, but for the first time in the series roughly one record in seven carries usable contact data.

This is a composition effect, not a policy change. The "Newly_Cleaned" daily line spikes to ~213k on August 4 and holds ~106k to 120k across August 13 to 17, precisely the .de Deluge windows, against a ~19k to 48k baseline on every other day. The batch cohort arrived with contact fields intact. The underlying redaction rate for ordinary registrations is essentially unchanged. Do not revise owner-attribution workflows on the strength of one month. Contact-based intelligence should continue to rely on registrar patterns, infrastructure metadata and TLD behavioral signals, with the August contact records treated as a bounded, identifiable cohort rather than as evidence of a new baseline.

Newly and Newly Cleaned - Daily Trend

A higher, more volatile aggregate: "Newly" registered domains fluctuated between approximately ~126k and ~742k/day against a monthly average of ~375,500, a wider band than July's, while "Newly_Cleaned" ran near the chart floor at ~19k to 48k on most days. The weekly Sunday and Monday rhythm remains visible, with troughs at ~237k and ~231k (August 2 and 3), ~312k (August 10), ~355k (August 16), ~320k and ~309k (August 23 and 24) and ~273k and ~257k (August 30 and 31), but three single-day events dominate the chart.
The August 8 Blackout: "Newly" fell to a month-low ~126k on August 8, roughly one-third of the daily average and less than half the weakest ordinary weekend reading. Month lows landed on the same date for .com (~17.5k), .top (~3.6k), the United States (~16.9k), Iceland (~4.4k), China (~1.8k), Germany (~1.8k), GoDaddy (~7.0k), Namecheap (~5.8k), Dynadot (~8.8k) and Spaceship (~4.8k): ten of the fifteen category charts simultaneously. .de, .cn, .xyz, Japan and GMO Internet show no shortfall at all, so this was a broad but not universal ingestion failure. The August 9 rebound to ~551k carried .com, the United States, Iceland, Japan, Namecheap, Dynadot, Spaceship, GMO and .xyz to their monthly highs, consistent with next-day reprocessing.
The August 4 peak: The month's highest reading came at ~742k on August 4, nearly double the daily average and the largest single-day count the series has recorded. August 18 produced the second-highest reading at ~582k, driven by the ~83.7k .cn spike and the opening of the second Twin-Window block, with August 9's ~551k rebound third.
"Newly_Cleaned" traces the .de Deluge exactly: The cleaned series shows one spike to ~213k on August 4, a sustained ~106k to 120k block across August 13 to 17, and a final ~173k reading on August 18, against a baseline near ~30k. Total "Newly_Cleaned" volume for the month tracks the 1,717,788 cleaned-contact figure closely, and the alignment of its August 13 to 17 block with the .de plateau is the single most useful diagnostic in the August chart set. It identifies the batch cohort by its data-completeness signature, not merely by its volume.

gTLDs vs ccTLDs

gTLDs dominate: 8,452,256 (72.6%) are generic Top-Level Domain registrations.
ccTLDs are sizable: 3,188,479 (27.4%) are country-code registrations, representing roughly 1 in 3.6 new domains.

The 72.6% and 27.4% split moved 8.4 points toward ccTLDs from July's 81.0% and 19.0%, the largest single-month shift the series has recorded. The mechanics are concentrated in a few extensions. ccTLD volume grew +1,338,913 (+72.4%), led by .de's climb to 690,812 and .cn +136,423, with .ru +22,497 and the Top-20 re-entries of .co (139,743) and .in (106,027) pointing to further country-code strength, while gTLD volume grew a more modest +559,464 (+7.1%) on .com's +400,821.

Maintain separate baselines for gTLDs and ccTLDs, and this month maintain an event-adjusted third baseline. Strip the August 13 to 17 .de plateau out and the split lands nearer 76% and 24%: still a genuine move toward country-code space, but a fraction of the headline. August is the cleanest case study the series has produced in why a single registry event can rewrite a top-level market statistic. Analysts modelling September should treat the gTLD trend as the more durable of the two, and should not carry the 27.4% ccTLD share forward as a baseline.

Key Takeaways

August 2026 recorded 11,640,735 newly registered domains, up 19.5% month over month and the first reading above eleven million.
Roughly 30% of that growth came from .de, and two-thirds of .de volume landed inside a five-day batch window. Underlying growth was closer to 11%.
A market-wide ingestion gap on August 8 produced month lows in ten of the fifteen tracked series, followed by an August 9 rebound that produced monthly highs in nine of them.
.xyz, GMO Internet and Japan share an identical two-window profile and all three exited the month at a small fraction of their monthly average.
Namecheap closed to within 50,204 registrations of GoDaddy, the narrowest top-two gap the series has recorded.
Registrar coverage held at 97.0%, address coverage slipped to 50.6%, and contact coverage nearly doubled to 14.8% as a one-cohort composition effect.

What to Watch in September 2026

Four questions decide whether August's numbers describe a market or an event.

The first is .de. On its post-plateau floor of ~6k to 9k per day, .de lands near 200,000 for September and returns to the low teens by rank. A second plateau would confirm a recurring registry or promotional channel rather than a one-off.

The second is the Twin-Window trio. .xyz, GMO Internet and Japan all exited August at 1% to 5% of their peak-window run rates. If no third window opens, all three post large September declines that say nothing about underlying demand.

The third is the top of the registrar table. A 50,204 gap is roughly one and a half average days for either firm. Namecheap has grown faster than GoDaddy for three consecutive months, and a swap at #1 in September is a live possibility.

The fourth is Iceland. The fade is orderly and shows no window structure, which makes it the most likely of this month's moves to continue. A third consecutive decline would take the geography toward the 400,000 range and reshape the country pie more durably than Germany's arrival did.

Teams tracking these cohorts day by day can pull the same records this report is built on from the Newly Registered Domains feed, or query them programmatically through the NRD API documentation. For month-over-month context, the July 2026 edition covers the Japanese unwind and the .shop ascent that this month partly reverses, and every prior report is collected in the Monthly Insights Radar archive. Analysts building a first NRD workflow will find the practical options compared in our guide to how to find newly registered domains. For scoring batch cohorts like August's German registrar channel against risk signals at ingestion time, the Domain Reputation API applies the same attribution logic used throughout this report.

Frequently Asked Questions

How many domains were registered in August 2026?

August 2026 recorded 11,640,735 newly registered domains, a 19.5% increase over July's 9,742,358 and the first month above eleven million in this series. Roughly 30% of the increase came from a single extension, .de, which arrived through a concentrated five-day batch event rather than through steady daily demand.

Which TLD grew fastest in August 2026?

.de grew fastest, rising 477.1% from 119,703 to 690,812 registrations and moving from rank #16 to rank #3. .cn placed second at 64.4% growth, and .vip third at 26.9%. .de's increase is the largest single-month move any extension has posted in this series.

Why did .de registrations jump 477% in August 2026?

Roughly 456,700 .de registrations, about 66% of the monthly total, landed across five consecutive days from August 13 to 17 at a near-flat rate of about 90,000 per day. Four German registrars entered the Top-20 in the same month. The pattern indicates a batch or promotional registration event processed through a small set of channels.

What caused the August 8 drop in newly registered domains?

Aggregate volume fell to about 126,000 on August 8, roughly one-third of the daily average, and ten of the fifteen tracked series recorded their month low on that date. Volume rebounded to about 551,000 on August 9 with nine series posting monthly highs, a pattern consistent with a one-day ingestion gap followed by next-day reprocessing.

Which registrar registered the most new domains in August 2026?

GoDaddy led with 1,192,684 registrations, ahead of Namecheap at 1,142,480. The 50,204 gap between them is the narrowest the series has recorded, down from 79,432 in July. GMO Internet Group placed third with 933,005 after growing 30.4%, reclaiming the position it lost to Dynadot in July.

Why did usable WHOIS contact data double in August 2026?

Usable contact details rose to 14.8% of records from 7.6% in July, an increase of 980,160 records. The daily cleaned series spikes on exactly the .de batch dates, which identifies the cause as one cohort arriving with contact fields intact. Redaction rates for ordinary registrations did not change.

How can I access the underlying newly registered domain data?

The figures in this report come from the WhoisFreaks Newly Registered Domains dataset, available as a daily feed, a bulk database download, or a REST API. Each record carries the domain, registration date, registrar, WHOIS fields where they are not redacted, and DNS records. Coverage and field definitions are documented alongside the product.

Data and Methodology

These figures come from the WhoisFreaks global WHOIS and registry ingestion pipeline, the same dataset behind the Newly Registered Domains feed. A newly registered domain is counted on the first calendar day (UTC) its registration record appears in a monitored registry or zone file. "Cleaned" means a field arrived populated and parseable; "Redacted" means it arrived withheld, masked, or replaced with a privacy-service placeholder. Top-20 cohort totals cover only the twenty highest-volume entries in each dimension and are smaller than the all-domain total, so shares quoted as a percentage of a Top-20 cohort are not comparable to shares of the full month.

Two limitations apply to August 2026 specifically. First, aggregate volume on August 8 fell to roughly one-third of the daily average across ten of the fifteen tracked series, with a corresponding rebound on August 9; readings on both dates reflect ingestion timing rather than registration demand, and daily concentration figures in this report exclude neither date but flag both. Second, the daily charts for GoDaddy, Namecheap and Dynadot sum to between 6% and 11% below their full-period totals, while every other series reconciles within 1%. All volume and month-over-month figures in this report use the full-period totals. Those three daily charts are described only in terms of bands, peaks and dates, and no concentration percentage is derived from them.

Originally published at whoisfreaks.com.

SSL Certificate Monitoring in Python: Get Alerted Before Certs Expire

Sameer Sheikh — Fri, 21 Aug 2026 11:24:04 +0000

Certbot had been renewing that certificate for two years without anyone touching it. Then someone moved the webroot during a Nginx cleanup, the HTTP-01 challenge started failing, and the renewal cron kept exiting quietly with a non-zero status nobody was reading. We found out when the cert expired.

That's the shape of almost every certificate outage I've seen. Not "we forgot to buy a certificate." More like "the automation was running and we assumed running meant working."

So I wrote a script that checks the certificate that's actually being served, from outside my own network, and shouts before anything breaks. It's about 400 lines and it caught something on the first real run that I wasn't expecting.

The part most expiry checks get wrong

Search for how to check certificate expiry in Python and you'll get this, more or less:

import ssl, socket
from datetime import datetime, timezone

ctx = ssl.create_default_context()
with socket.create_connection(("github.com", 443), timeout=5) as sock:
    with ctx.wrap_socket(sock, server_hostname="github.com") as tls:
        cert = tls.getpeercert()

not_after = datetime.strptime(cert["notAfter"], "%b %d %H:%M:%S %Y %Z")
print((not_after.replace(tzinfo=timezone.utc) - datetime.now(timezone.utc)).days)

This works. No dependencies, five seconds to write, and for a handful of hosts you can reach directly it's the right answer. I keep a copy in the repo as check_expiry_stdlib.py because sometimes that's all you need.

But getpeercert() gives you the leaf certificate and nothing else. Your leaf can have 60 comfortable days left while the intermediate that signs it expires next week, and when that intermediate goes, every client gets a handshake failure. The leaf's date told you nothing.

This isn't hypothetical. LogDNA published a postmortem in May 2020 about exactly this: a root certificate expiry that broke TLS for their customers while the leaf certificates were all perfectly valid.

There's a second problem, and it's the one that bit me. getpeercert() reports on the TLS connection that your script made. If anything sits between your script and the internet doing TLS inspection, a corporate proxy, a security appliance, a container platform with an egress gateway, then you are reading that middlebox's re-signed certificate. Not the real one. Your monitoring reports healthy and the outside world sees an expired cert.

I hit this while testing. Running the stdlib script inside a sandboxed environment, every host came back valid with 29 to 30 days left, including expired.badssl.com, which is a host whose entire purpose is to serve an expired certificate. The issuer field said the proxy's name. My checker was confidently monitoring the wrong thing.

So: query from somewhere else, and get the whole chain.

What I built

wf-ssl-monitor reads a list of domains, pulls the full certificate chain for each one through the WhoisFreaks SSL Certificate API, finds whichever certificate in the chain expires first, and exits with a Nagios-style status code so cron or CI can act on it. Optionally it posts to Slack.

Full source: github.com/WhoisFreaks/wf-ssl-monitor

Setup

git clone https://github.com/WhoisFreaks/wf-ssl-monitor.git
cd wf-ssl-monitor
pip install -r requirements.txt
export WHOISFREAKS_API_KEY="your_key"

Signup gives you 500 credits without a card, which is plenty to get this running. The only dependency is requests.

Step 1: One call, whole chain

The endpoint is a single GET. The chain=true parameter is the important one, since without it you get the leaf and you're back to the problem above.

curl "https://api.whoisfreaks.com/v1.0/ssl/live?apiKey=$WHOISFREAKS_API_KEY&domainName=github.com&chain=true"

You get back sslCertificates, an array ordered from end-user to root. Each entry carries chainOrder, validityStartDate, validityEndDate, subject, issuer, signatureAlgorithm, publicKey, and the SANs under extensions.subjectAlternativeNames.dnsNames.

One detail worth flagging because it cost me a debugging round. The dates come back like this:

2026-09-1 07:47:19 UTC

The day isn't zero-padded. strptime with %d handles it, but a naive dateutil guess or a hand-rolled slice will not, and the failure mode is silent wrong numbers rather than an exception. That's the worst kind. So the parser is explicit and tries several shapes:

def parse_wf_datetime(raw: str) -> datetime:
    s = raw.strip()
    for suffix in (" UTC", "UTC", " GMT", "Z"):
        if s.endswith(suffix):
            s = s[: -len(suffix)].strip()
            break

    for fmt in ("%Y-%m-%d %H:%M:%S", "%Y-%m-%dT%H:%M:%S",
                "%Y-%m-%d %H:%M", "%Y-%m-%d", "%b %d %H:%M:%S %Y"):
        try:
            return datetime.strptime(s, fmt).replace(tzinfo=timezone.utc)
        except ValueError:
            continue

    raise ValueError(f"unrecognised date format: {raw!r}")

Note datetime.now(timezone.utc) rather than datetime.utcnow() everywhere in this script. utcnow() is deprecated as of Python 3.12 and returns a naive datetime, which means subtracting it from an aware one raises. If you're copying older tutorials, that's a trap.

Step 2: Alert on the weakest link, not the leaf

This is the whole point of the tool, and it's about eight lines. Parse every certificate in the chain, then sort by expiry and take the earliest:

@property
def weakest(self) -> CertInfo | None:
    """The cert in the chain that expires first. This is what we alert on."""
    scored = [c for c in self.certs if c.days_left is not None]
    return min(scored, key=lambda c: c.days_left) if scored else None

Classification runs off min_days across the chain rather than the leaf's date:

def classify(result: DomainResult, warn: int, crit: int) -> str:
    if result.error:
        return STATUS_ERROR
    days = result.min_days
    if days is None:
        return STATUS_ERROR
    if days < 0:
        return STATUS_EXPIRED
    if days <= crit:
        return STATUS_CRIT
    if days <= warn:
        return STATUS_WARN
    return STATUS_OK

Defaults are 30 days for warning and 7 for critical. Both are flags, and I'd tighten them as certificate lifetimes shrink.

Step 3: Respect the rate limit before it bites

The free tier allows 10 requests per minute on live endpoints. Firing a thread pool at that gets you a wall of 429s, so requests get paced through a small limiter that holds the lock while it sleeps:

class RateLimiter:
    """Spaces requests out so we stay under the plan's requests-per-minute cap."""

    def __init__(self, rpm: int):
        self.min_interval = 60.0 / rpm if rpm > 0 else 0.0
        self._lock = threading.Lock()
        self._next_slot = 0.0

    def acquire(self) -> None:
        if self.min_interval <= 0:
            return
        with self._lock:
            now = time.monotonic()
            wait = self._next_slot - now
            if wait > 0:
                time.sleep(wait)
                now = time.monotonic()
            self._next_slot = max(now, self._next_slot) + self.min_interval

If a 429 does come back, the API tells you exactly how long to wait in the x-ratelimit-remaining-time header. The value is in nanoseconds, which surprised me:

if resp.status_code == 429:
    raw_wait = resp.headers.get("x-ratelimit-remaining-time")
    try:
        pause = min(int(raw_wait) / 1_000_000_000, 90)
    except (TypeError, ValueError):
        pause = 15.0
    if attempt < 2:
        time.sleep(max(pause, 1.0))
        continue

On a paid plan, --rpm 60 --workers 8 moves considerably faster.

Step 4: Don't trust the documented response shape

I built the parser against the response structure in the docs, which shows a top-level JSON array. First real run against the live API, every domain came back as an error while the HTTP status was 200. The data was fine. My assumption about the wrapper was wrong, and because I'd written if isinstance(payload, dict): return error, a perfectly good response got thrown away.

Lesson I keep relearning: match on field names, not on payload structure. The parser now accepts an array, a bare object, a single certificate with no wrapper, or data nested under an envelope key:

def find_cert_entries(payload: Any) -> list[dict]:
    if isinstance(payload, list):
        out = []
        for item in payload:
            if isinstance(item, dict):
                out.extend(find_cert_entries(item))
        return out

    if not isinstance(payload, dict):
        return []

    if payload.get("sslCertificates"):
        certs = payload["sslCertificates"]
        if isinstance(certs, dict):
            payload = {**payload, "sslCertificates": [certs]}
        return [payload]

    for key in ("data", "result", "results", "response", "ssl", "sslData"):
        nested = payload.get(key)
        if isinstance(nested, (dict, list)):
            found = find_cert_entries(nested)
            if found:
                return found

    if payload.get("validityEndDate") or payload.get("subject"):
        return [{"domainName": payload.get("domainName"),
                 "sslCertificates": [payload]}]

    return []

And when it still can't find certificates, it says what it did receive instead of failing generically:

error=f"no certificate data found ({shape})"
# -> no certificate data found (object with keys: domainName, queryTime, someNewKey)

It keeps the raw payload and prints it automatically. Telling someone to rerun with a debug flag is a wasted scheduled run, and if that run was at 3 AM you've lost a day.

Real results

Running against the production list:

$ python ssl_monitor.py domains.txt --warn 30 --crit 7

DOMAIN             DAYS   EXPIRES     ISSUER                                  STATUS
------------------------------------------------------------------------------------
whoisfreaks.com      70   2026-10-30  WE1                                     OK
github.com           41   2026-09-30  Sectigo Public Server Authentication C  OK
cloudflare.com       47   2026-10-06  WE1                                     OK
python.org          178   2027-02-14  GlobalSign Atlas R3 DV TLS CA 2025 Q4   OK
letsencrypt.org      45   2026-10-04  YE2                                     OK

5 domains in 26.4s - 5 ok, 0 warning, 0 critical, 0 expired, 0 errors

Then the deliberately broken list, which is how I check the checker:

$ python ssl_monitor.py domains.test.txt

DOMAIN                  DAYS   EXPIRES     ISSUER                                  STATUS
------------------------------------------------------------------------------------------
expired.badssl.com      -4148  2015-04-12  COMODO RSA Domain Validation Secure Se  EXPIRED
self-signed.badssl.com    728  2028-08-17  *.badssl.com                            OK (self-signed)

2 domains in 12.1s - 1 ok, 0 warning, 0 critical, 1 expired, 0 errors

Negative 4,148 days. That certificate expired in April 2015 and the API reported it accurately, which is exactly what I wanted to confirm. Remember the sandbox where every host including this one came back with 30 healthy days? That's the difference between checking the certificate and checking whatever your network hands you.

What I noticed

A valid expiry date is not a valid certificate. self-signed.badssl.com came back with 728 days left and my first version called that OK. It's self-signed. Every browser rejects it. I added a check comparing the leaf's subject against its issuer, and now it prints OK (self-signed), because reporting green on a cert nothing trusts is worse than not checking at all.
The intermediate is the one nobody watches. Every dashboard I've used reports the leaf date.
Errors deserve their own status, separate from expiry. A lookup that fails is not a healthy certificate, and folding those together is how you end up with a green dashboard and a broken site. Hence exit code 3.
Two of the five production hosts are on Google Trust Services (WE1) and one on YE2. Short-lived certs from large issuers cluster in the 40 to 70 day range, which is a useful baseline. python.org at 178 days stood out immediately as the outlier running a longer GlobalSign cert.
Five domains took 26 seconds. That's the rate limiter doing its job at 10 requests a minute, not the API being slow.
Keep your broken test hosts in a separate file from the list your scheduled job reads. I didn't, and my first green-field cron run went red at 8 AM because a host that expired in 2015 was still expired. A monitor that cries wolf every morning gets muted by Thursday.

Why this is getting more urgent

Certificate lifetimes are dropping fast. CA/Browser Forum ballot SC-081v3 passed in April 2025 and steps the maximum down on a fixed schedule.

Let's Encrypt is moving in parallel, from 90 days now to 64 in February 2027 and 45 in February 2028.

Here's the thing about going from roughly one renewal a year to nearly eight: the per-renewal failure rate doesn't have to change for your annual odds of an outage to get much worse. Manual renewal stops being viable, automation becomes mandatory, and automation that fails silently becomes the main risk. Which is the argument for monitoring the served certificate rather than trusting that the renewal job did its job.

Scheduling it

The repo has a GitHub Actions workflow that runs daily at 08:00 UTC:

on:
  schedule:
    - cron: '0 8 * * *'
  workflow_dispatch:

concurrency:
  group: ssl-check
  cancel-in-progress: false

workflow_dispatch is there so you can trigger it by hand while testing instead of editing the cron and waiting. concurrency stops a slow run overlapping the next one and double-alerting. Store WHOISFREAKS_API_KEY and SLACK_WEBHOOK_URL under Settings, Secrets and variables, Actions.

For a plain cron box:

0 8 * * * cd /opt/wf-ssl-monitor && /usr/bin/python3 ssl_monitor.py domains.txt --slack

Going further

A few directions I'd take this next:

Validate trust, not just dates. The self-signed catch above is a string comparison. Real validation means checking the chain actually links up and terminates at a trusted root, which is a bigger job and probably the most valuable thing to add next.
Pull the domain list from your actual infrastructure instead of a text file. Terraform state, a DNS zone export, or your ingress definitions all beat a hand-maintained list that drifts.
Alert on SAN changes, not just expiry. A certificate that quietly stops covering a hostname is its own outage.
Write results to a time series database so you can see renewals happening rather than just current state. A cert stuck at the same expiry date across three weeks is a renewal that stopped working.
If you'd rather not run and maintain this yourself, WhoisFreaks SSL Certificate API covers the lookup side as a managed service.

Full source

Everything is in github.com/WhoisFreaks/wf-ssl-monitor, MIT licensed. That includes ssl_monitor.py, the stdlib version for comparison, the Actions workflow, a production domains.txt, and a domains.test.txt of deliberately broken hosts for verifying the checker.

If you run it and hit a response shape the parser doesn't handle, open an issue with the payload it printed. That's the part most likely to need adjusting.

Block Bots Before They Hit Your API; IP Reputation in Node.js

Sameer Sheikh — Fri, 24 Jul 2026 15:51:58 +0000

Most API abuse gets caught after it lands. A rate limiter trips, an alert fires, someone checks the logs the next morning and finds a Tor exit node hammered /login four thousand times overnight. Reactive. I wanted to catch the traffic at the door instead, before it touches a single route handler.

The idea is simple. Every request arrives with an IP. That IP already has a reputation — it's a residential broadband line, or it's a datacenter, or it's a known VPN, or it's an address that's been throwing credential-stuffing attempts at half the internet for a week. If you know which one you're looking at before your handler runs, you can decide what to do with it. Block the obvious attackers. Challenge the suspicious ones. Wave the clean ones through without friction.

That last part matters. Most tutorials I've read on this treat it as a binary: VPN detected, block. But a corporate user on a datacenter IP and a bot running out of a bulletproof host are not the same threat, and slamming the door on both is how you lose real customers. So this middleware grades on a curve.

Here's the whole path a request takes before it ever reaches your handler:

The piece everyone skips

Here's the thing that took me longer than it should have: getting the real client IP.

Behind a load balancer, a CDN, or basically any modern deploy, req.socket.remoteAddress is the proxy in front of you, not the visitor. The real address sits in the X-Forwarded-For header. Express won't read it unless you tell it to trust the proxy, and if you trust it wrong, you've handed attackers a header they can spoof to look like 127.0.0.1. More on that later. For now, know that this one line does a lot of quiet work:

app.set("trust proxy", true);

Setup

Node 18+ (we're using the built-in fetch, no HTTP client dependency), Express, and a free WhoisFreaks key.

git clone https://github.com/WhoisFreaks/ip-reputation-middleware
cd ip-reputation-middleware
npm install
cp .env.example .env   # paste your API key

The key is free — 500 credits, no card. Each IP lookup costs one credit. That's enough to build and test the whole thing with credits to spare.

Step 1: One lookup

Start with the smallest possible thing that works. Given an IP, ask what its reputation is.

The endpoint is a plain GET. Auth is a query parameter called apiKey, and you pass the address in ip. The full request and response schema is documented in the WhoisFreaks IP Reputation API reference. The response comes back as an array with one object per IP, and the part we care about lives under security:

const BASE_URL = "https://api.whoisfreaks.com/v1.0/security";

export async function lookupIp(ip, { apiKey = process.env.WHOISFREAKS_API_KEY } = {}) {
  const url = `${BASE_URL}?apiKey=${apiKey}&ip=${encodeURIComponent(ip)}`;
  const res = await fetch(url);
  if (!res.ok) throw new Error(`whoisfreaks_http_${res.status}`);
  const body = await res.json();
  return Array.isArray(body) ? body[0] : body;
}

The security object is richer than the single boolean most APIs hand you. You get threat_score (0–100), plus is_vpn, is_proxy, is_residential_proxy, is_tor, is_bot, is_known_attacker, is_spam, and is_cloud_provider, along with confidence scores and provider names for the VPN and proxy hits. That granularity is what makes graded responses possible instead of a flat block.

Step 2: Decide, don't just detect

This is the core of the whole thing, and it's ten lines. The composite threat_score does the heavy lifting. I mapped it to four actions using the score bands WhoisFreaks documents:

export function decide(security) {
  const score = security?.threat_score ?? 0;
  if (score >= 76) return "block";      // known-bad: reject
  if (score >= 51) return "step_up";    // high: require extra auth
  if (score >= 26) return "challenge";  // elevated: CAPTCHA / rate limit
  return "allow";                       // low: let it through
}

Why four tiers and not two? Because a score of 40 usually means "datacenter or commercial VPN" — plenty of legitimate people browse from those. A score of 90 means the address is actively bad. You want the first group to see a CAPTCHA at worst and the second group to see nothing but a 403. One threshold can't express that.

Step 3: Wrap it in middleware

Now make it an Express middleware factory so each route or app can plug in its own responses per tier.

export function ipReputation(options = {}) {
  const { failOpen = true, onBlock, onChallenge, onStepUp } = options;

  return async function (req, res, next) {
    const ip = clientIp(req);
    if (isPrivate(ip)) return next();   // skip localhost / internal traffic

    let record;
    try {
      record = await lookupIp(ip);
    } catch (err) {
      if (failOpen) return next();      // API down? don't take the app down with it
      return res.status(503).json({ error: "reputation_unavailable" });
    }

    const security = record?.security ?? {};
    req.ipReputation = security;

    switch (decide(security)) {
      case "block":     return onBlock ? onBlock(req, res, next) : res.status(403).json({ error: "forbidden" });
      case "step_up":   return onStepUp ? onStepUp(req, res, next) : next();
      case "challenge": return onChallenge ? onChallenge(req, res, next) : next();
      default:          return next();
    }
  };
}

Two decisions in there are worth calling out.

Fail open. If the reputation API times out or returns a 500, the request goes through. I went back and forth on this. But think about what fail-closed means: your threat provider has one bad minute and your login page returns 503 to every real customer on earth. That's a self-inflicted outage in exchange for maybe blocking one risky request. Not worth it. Fail open, log the miss, move on.

Skip private IPs. Health checks, internal service calls, and your own localhost testing shouldn't burn credits or get scored. The isPrivate check short-circuits them.

Step 4: Get the client IP right

The helper the whole thing leans on:

export function clientIp(req) {
  return (req.ip || "").replace(/^::ffff:/, "");  // strip IPv4-mapped IPv6 prefix
}

That ::ffff: strip bit me the first time. Express hands you IPv4 addresses wrapped as IPv6 (::ffff:8.8.8.8), and if you pass that straight to the API you'll get nonsense back. Small detail, real bug.

On trust proxy: setting it to true is fine when every request genuinely passes through a proxy you control. If your app is also reachable directly, a client can send their own X-Forwarded-For and impersonate any IP they like, including a clean one. In that case set it to the exact number of proxy hops instead. Know your deploy.

Step 5: Cache, because credits and latency

Adding a network call to every request is a great way to make every request slower and drain 500 credits by lunch. The reputation data refreshes about once a day, so caching a result for a few hours costs nothing in accuracy:

const CACHE_TTL_MS = 12 * 60 * 60 * 1000;
const cache = new Map();
// check cache.get(ip) before fetch; cache.set(ip, { record, expires }) after

An in-memory Map is fine for one process. Swap in Redis the moment you run more than one. The free tier caps you at 10 requests per minute, so on a real site the cache isn't an optimization — it's the thing that keeps you under the limit at all.

Step 6: Test the part that matters

You don't need to hit the live API to test the logic that decides someone's fate. The tiering is pure and deterministic, so test the boundaries directly:

test("elevated scores get challenged", () => {
  assert.equal(decide({ threat_score: 26 }), "challenge");
  assert.equal(decide({ threat_score: 50 }), "challenge");
});

test("malicious scores are blocked", () => {
  assert.equal(decide({ threat_score: 76 }), "block");
  assert.equal(decide({ threat_score: 100 }), "block");
});

Off-by-one errors here are the whole ballgame. Get >= 76 wrong and you either block clean users at 75 or let attackers through at 76.

Real results

Running the suite:

▶ node --test

ok 1 - low scores are allowed
ok 2 - elevated scores get challenged
ok 3 - high scores require step-up auth
ok 4 - malicious scores are blocked
ok 5 - missing score defaults to allow (fail open)

# tests 5
# pass 5
# fail 0

Then I pointed the batch script at 20 IPs pulled from a day of access logs — a mix of hosting ranges, commercial VPN exit points, and a couple of addresses I already suspected. The script only prints what's worth acting on, so the clean ones drop out:

$ node enrich-logs.js sample-ips.txt
scoring 20 IPs...

45.83.220.14     score= 50  challenge  -
185.159.157.22   score= 80  block      is_known_attacker
193.176.86.103   score= 50  challenge  -
89.187.178.211   score= 50  challenge  -
138.199.21.90    score= 50  challenge  -
37.120.145.60    score= 50  challenge  -
143.244.47.201   score= 50  challenge  -
185.220.101.34   score= 85  block      is_tor,is_known_attacker
195.181.170.12   score= 50  challenge  -
198.54.117.200   score= 35  challenge  is_known_attacker
5.253.207.88     score= 50  challenge  -
146.70.124.19    score= 50  challenge  -
217.138.222.101  score= 50  challenge  -
84.17.35.176     score= 50  challenge  -
156.146.63.128   score= 50  challenge  -

Twenty in, fifteen surfaced. Two hit the block tier outright. The other five scored low enough to pass and never printed.

What I noticed

A few things stood out once I had real scores in front of me:

The two blocks were the clear-cut ones. 185.220.101.34 came back is_tor and is_known_attacker at 85 — that's a public Tor exit node, and it earned the 403. 185.159.157.22 hit 80 on is_known_attacker alone. No argument with either.
Most of the list clustered at exactly 50 with no individual flags set. These were hosting and commercial-VPN ranges, and the API parked them in the middle: not clean, not confirmed-malicious. That's the tiering earning its keep. A binary "is this a VPN" check would either wave all of them through or block real users behind a VPN. Sitting them in the challenge tier — CAPTCHA, not a door slam — is the right call for that gray zone.
The score and the flags don't always agree. 198.54.117.200 carried is_known_attacker but only scored 35. If I'd keyed the block decision off the flag alone, I'd have blocked it; off the score alone, I'd have under-reacted. Reading both is why it landed in challenge instead of a wrong call in either direction.
The flat 50s are worth a second look before you trust them in production. When a lot of distinct IPs land on the same round number with empty flags, that can mean the dataset has coarse coverage for those ranges rather than a precise read on each one. I'd verify a couple against a raw API response before wiring the thresholds to anything expensive. ## Going further

A few directions from here:

Push blocks down to the edge. Once enrich-logs.js finds repeat offenders, drop them in an nginx deny list or a WAF rule so they never reach Node at all.
Persist the cache in Redis and share it across your whole fleet.
Feed the asn and connection_type fields into your own scoring if you want app-specific rules on top of the score.
If you'd rather not run and maintain the lookup layer yourself, the WhoisFreaks IP Reputation API provides the scoring and the VPN/proxy/Tor/bot flags as a managed service, so you're just reading a field. ## Full source code

Everything above, wired together and runnable, is on GitHub: github.com/WhoisFreaks/ip-reputation-middleware. Clone it, drop in a key, and npm start.

Hunting Typosquats in 300K Newly Registered Domains With DuckDB (No Database Server)

Sameer Sheikh — Fri, 17 Jul 2026 22:10:07 +0000

Last month Palo Alto's Unit 42 published something that stuck with me. They asked two LLMs for the "official" URLs of 913 well-known brands, ran hundreds of thousands of queries, and roughly 37% of the URLs the models returned pointed at domains that did not exist. Normalize the duplicates and you are left with about 250,000 unique phantom domains. Plausible-looking, brand-adjacent, and sitting there unregistered. Anyone who runs the same prompt can register them first and wait for the traffic to arrive.

That is a lot of names to keep an eye on. And the window to catch a bad registration is narrow. Reputation feeds often take a day or three to flag a fresh domain, while a phishing kit can be serving pages within hours of the registrar confirming it.

So here is the question I actually care about. Around 250K to 300K new domains hit the internet every single day. How do you sift that daily haul fast enough to be useful, without standing up Postgres, without a schema, without a pipeline you have to babysit?

The answer I keep coming back to is boring in the best way. One CSV file and DuckDB. It runs on my laptop, the queries finish before I lift my finger off Enter, and there is no server anywhere.

The data: a daily file, not an API loop

I use the WhoisFreaks Newly Registered Domains feed for this. It is a once-or-twice daily dump of every domain registered across 1,500-plus TLDs, and you can pull it as plain CSV. Each row is a domain with its creation date, registrar, name servers, status flags, and, on the WHOIS tiers, whatever registrant fields survived GDPR redaction.

You do not need a paid plan to follow along. There is a free daily sample of about 1,000 gTLD domains you can grab with a single request, and it has the same column layout as the full file. It comes down gzipped, so save it with a .csv.gz name. That is what I built this on. The field definitions and download endpoints are all in the WhoisFreaks NRD documentation if you want the full column list.

Grab the sample:

curl -o nrd_sample.csv.gz \
  "https://files.whoisfreaks.com/download/domainer/sample/gtld?whois=true"

When you move to the full daily file, it is the same shape with an API key and an optional date:

curl -o "nrd_$(date +%F).csv.gz" \
  "https://files.whoisfreaks.com/v3.3/download/domainer/gtld?apiKey=YOUR_KEY&whois=true"

That second file is the real thing. Hundreds of thousands of rows, tens of columns. DuckDB reads the gzip straight off disk, so there is no unzip step to wait on.

Why DuckDB and not pandas

I reached for pandas first, out of habit. It works, but you feel the weight. read_csv on a wide multi-hundred-megabyte file pulls the whole thing into memory before you have asked a single question of it.

DuckDB flips that. It is an in-process SQL engine, so there is no server and no port. You pip install it and you are done. It reads CSV, gzipped CSV, Parquet, and JSON straight off disk, and it only touches the columns your query actually needs. It is columnar and vectorized under the hood, which is a technical way of saying it chews through a few hundred thousand rows in the time pandas spends clearing its throat.

pip install duckdb

Load and look around

First thing I do with any new file is ask it two questions: how many rows, and what are the columns actually called. Column names in vendor CSVs are never quite what you assume, so check rather than guess.

import duckdb

con = duckdb.connect()

# how many domains in this file?
con.sql("SELECT COUNT(*) AS domains FROM 'nrd_sample.csv.gz'").show()

# what columns do we actually have?
con.sql("DESCRIBE SELECT * FROM 'nrd_sample.csv.gz'").show()

There is no import step, no CREATE TABLE, no loading. You point a query at the filename and DuckDB figures out the types itself. Match the column names in the queries below to whatever DESCRIBE prints for your file, since the exact field names vary by feed tier.

If you have been hoarding a week of files, a glob reads them all as one virtual table:

con.sql("""
    SELECT create_date, COUNT(*) AS registered
    FROM 'nrd_*.csv.gz'
    GROUP BY create_date
    ORDER BY create_date
""").show()

Aggregate the whole file

Before hunting for anything specific, I like to get a feel for the day. Which registrars were busiest, which TLDs dominated. This is a plain GROUP BY over the full file.

con.sql("""
    SELECT
        domain_registrar_name,
        COUNT(*) AS domains
    FROM 'nrd_sample.csv.gz'
    GROUP BY domain_registrar_name
    ORDER BY domains DESC
    LIMIT 10
""").show()

Running that against a real daily file (279,653 domains the day I ran it) returns this:

┌───────────────────────────────────────────┬─────────┐
│           domain_registrar_name            │ domains │
├───────────────────────────────────────────┼─────────┤
│ Dynadot Inc                                │  36,334 │
│ NameCheap, Inc                             │  34,195 │
│ GoDaddy.com, LLC                           │  33,239 │
│ Spaceship, Inc                             │  23,236 │
│ HOSTINGER operations, UAB                  │  14,076 │
│ GMO Internet Group, Inc. d/b/a Onamae.com  │  13,404 │
│ Cloudflare, Inc                            │  11,991 │
│ NameSilo, LLC                              │   5,964 │
│ Porkbun LLC                                │   5,819 │
│ Squarespace Domains II LLC                 │   5,589 │
│ ...                                        │     ... │
└───────────────────────────────────────────┴─────────┘

Four registrars soak up more than 125,000 of those 280,000 domains in a single day. That concentration is worth remembering later.

The TLD split is just as quick. Pull the part after the last dot and count it.

con.sql(r"""
    SELECT
        regexp_extract(domain_name, '\.([^.]+)$', 1) AS tld,
        COUNT(*) AS domains
    FROM 'nrd_sample.csv.gz'
    GROUP BY tld
    ORDER BY domains DESC
    LIMIT 10
""").show()

Which comes back like this:

┌────────┬─────────┐
│  tld   │ domains │
├────────┼─────────┤
│ com    │ 119,585 │
│ shop   │  15,548 │
│ top    │  11,837 │
│ org    │   8,932 │
│ online │   8,399 │
│ net    │   8,161 │
│ xyz    │   7,017 │
│ icu    │   6,470 │
│ cyou   │   6,322 │
│ cfd    │   6,116 │
│ ...    │     ... │
└────────┴─────────┘

.com dominates, no surprise. But look at what follows it. .shop, .top, .icu, .cyou, .cfd. These cheap new gTLDs punch far above their size in abuse reports, and here they are near the top of a single day's registrations. That is a filter worth keeping.

None of this is the point yet. It is orientation. The interesting part is next.

The typosquat hunt

Here is what actually makes this dataset worth reading. Somewhere in today's registrations are names built to impersonate a brand. paypa1, paypal-secure, paypaI with a capital i standing in for the L. Picking those out by hand is hopeless at this volume. But it is a text-distance problem, and DuckDB ships the functions for it built in.

Two of them do most of the work. levenshtein counts how many single-character edits turn one string into another, so a value of 1 or 2 means "almost identical." jaro_winkler_similarity returns a score from 0 to 1 and rewards strings that share a prefix, which is exactly how most typosquats are built.

But one pass is not enough. Edit distance catches misspellings and character swaps. It completely misses paypal-login, because that string is many edits away from the bare brand. So I run a second pass that looks for the brand sitting next to a common phishing keyword. The two passes catch different things.

Pass one, the edit-distance lookalikes. I pull out the registrable label (the part before the first dot), compare it to the brand, and keep the near-misses.

brand = "paypal"

con.sql(f"""
    SELECT
        domain_name,
        levenshtein(split_part(domain_name, '.', 1), '{brand}')            AS edits,
        jaro_winkler_similarity(split_part(domain_name, '.', 1), '{brand}') AS similarity
    FROM 'nrd_sample.csv.gz'
    WHERE levenshtein(split_part(domain_name, '.', 1), '{brand}') BETWEEN 1 AND 3
    ORDER BY similarity DESC
    LIMIT 25
""").show()

The BETWEEN 1 AND 3 is deliberate. Zero edits is just the real brand, and anything past three edits is usually a different word that happens to share letters. That band is where the lookalikes live.

Here is the top of what came back for paypal on a real day:

┌───────────────┬───────┬────────────┐
│  domain_name  │ edits │ similarity │
├───────────────┼───────┼────────────┤
│ paypill.icu   │     2 │      0.910 │
│ paypayhq.com  │     3 │      0.892 │
│ pagpals.com   │     2 │      0.879 │
│ payzap.shop   │     2 │      0.876 │
│ payzap.xyz    │     2 │      0.876 │
│ payspark.biz  │     3 │      0.874 │
│ papar.online  │     2 │      0.858 │
│ payflax.com   │     3 │      0.848 │
│ paytag.app    │     2 │      0.844 │
│ pay-pin.com   │     3 │      0.822 │
│ ...           │   ... │      ...    │
└───────────────┴───────┴────────────┘

paypill.icu is a believable PayPal squat, and it sits on .icu, one of the cheap TLDs from the earlier list. But be honest about the rest. Further down the ranking, edit distance starts dragging in strings like playjl.lol that are three edits away and share some letters but have nothing to do with PayPal. On a six-letter brand, a three-edit window is loose. More on that in a second.

That split_part trick is a simplification. It treats everything before the first dot as the label, which is fine for paypill.icu but not for a login.paypal.evil.com style host. For a daily scan of freshly registered second-level domains it holds up. For deeper subdomain analysis you would want to parse against the public suffix list, which is a post of its own.

The full script wraps both passes, auto-detects the file's columns, and takes a --brand argument. Link at the bottom.

What I noticed in one day's file

Using domain column: domain_name   registrar column: domain_registrar_name

Top 25 registrars
----------------------------------------
    36,334  Dynadot Inc
    34,195  NameCheap, Inc
    33,239  GoDaddy.com, LLC
    23,236  Spaceship, Inc
    14,076  HOSTINGER operations, UAB
    13,404  GMO Internet Group, Inc. d/b/a Onamae.com
    11,991  Cloudflare, Inc
     5,964  NameSilo, LLC
     5,819  Porkbun LLC
     5,589  Squarespace Domains II LLC
     5,405  Name.com, Inc
     5,174  Tucows Domains Inc
     4,991  Zhengzhou Century Connect Electronic Technology Development Co., Ltd
     4,562  PDR Ltd. d/b/a PublicDomainRegistry.com
     4,203  Squarespace Domains LLC
     3,817  Dynadot LLC
     3,811  IONOS SE
     3,233  NameMart Pte. Ltd
     2,831  Wix.com Ltd
     2,602  Gransy, s.r.o
     1,895  Dominet (HK) Limited
     1,821  Network Solutions, LLC
     1,800  Realtime Register B.V
     1,760  Namecheap, Inc
     1,609  Gname.com Pte. Ltd

Top 25 TLDs
----------------------------------------
   119,585  .com
    15,548  .shop
    11,837  .top
     8,932  .org
     8,399  .online
     8,161  .net
     7,017  .xyz
     6,470  .icu
     6,322  .cyou
     6,116  .cfd
     5,942  .garden
     5,784  .app
     5,746  .site
     4,881  .info
     4,402  .store
     3,537  .vip
     2,843  .click
     2,734  .pro
     2,713  .bet
     2,386  .biz
     2,299  .sbs
     1,737  .club
     1,618  .space
     1,618  .buzz
     1,288  .live

Edit-distance lookalikes for 'paypal' (1-3 edits)
------------------------------------------------------------
  0.910  edits=2  paypill.icu
  0.892  edits=3  paypayhq.com
  0.879  edits=2  pagpals.com
  0.876  edits=2  payzap.shop
  0.876  edits=2  payzap.xyz
  0.876  edits=3  payle.org
  0.874  edits=3  payspark.biz
  0.858  edits=2  papar.online
  0.858  edits=2  papa9.wiki
  0.848  edits=3  payflax.com
  0.848  edits=3  paynela.homes
  0.848  edits=3  payport.systems
  0.844  edits=2  paytag.app
  0.825  edits=3  payz.club
  0.822  edits=3  partpl.com
  0.822  edits=3  papaii.com
  0.822  edits=2  pahwal.com
  0.822  edits=3  payeazy.store
  0.822  edits=3  pacpza.com
  0.822  edits=3  pay-pin.com
  0.800  edits=3  pata.today
  0.800  edits=3  playjl.lol
  0.800  edits=3  playjl.quest
  0.800  edits=3  playjl.cam
  0.800  edits=3  playjl.lat

  scanned in 3.237s

Brand+keyword combinations for 'paypal'
------------------------------------------------------------
  (none found)

A handful of things jumped out once the numbers were real.

Registration is wildly concentrated. Dynadot, Namecheap, GoDaddy, and Spaceship together accounted for over 125,000 of the day's ~280,000 domains. Four names, nearly half the internet's daily growth.
The data is not perfectly clean. Namecheap shows up twice under two spellings, NameCheap, Inc with 34,195 and Namecheap, Inc further down with another 1,760. If you build alerting on the registrar field, normalize it first. This part took me a minute to spot.
Edit distance on a short brand is noisy. paypill.icu is a real catch. But a three-edit window on a six-letter word also pulls in playjl.lol, which shares letters and means nothing. For short brands, drop to --max-edits 1, or once your candidate list is small, require the brand to sit at the start of the label.
The two passes really do disagree. On this particular day the brand-plus-keyword pass returned nothing for paypal, while edit distance returned plenty. Another brand, or another day, flips that. Which is the point of running both.
Registration is not the same as reach. Plenty of these names resolve to nothing on day one. They sit parked, waiting. The dangerous fraction already has a live A record and a valid cert, and those are the ones worth a second query.

Performance, since that was the whole promise

I timed the typosquat scan on the full daily file, ~280,000 rows, on an ordinary laptop.

import time

t = time.perf_counter()
con.sql("""
    SELECT domain_name
    FROM 'nrd_2026-07-18.csv.gz'
    WHERE levenshtein(split_part(domain_name, '.', 1), 'paypal') BETWEEN 1 AND 3
""").fetchall()
print(f"{time.perf_counter() - t:.3f}s")

The registrar and TLD group-bys came back instantly, fast enough that there was nothing to time. The typosquat scan is heavier, because it runs a Levenshtein calculation against every one of the ~280,000 rows, and that took about 3.2 seconds. Not instant, but fast enough to sit there and iterate on your brand list without breaking focus, and all of it reading a gzipped file off disk with no load step. DuckDB stays in-memory friendly into the millions of rows and spills to disk beyond that, so a full month of daily files in one glob query is still reasonable on the same laptop.

Handing off to pandas for the parts SQL is bad at

DuckDB is the wrong tool for charts. When I want to plot the daily registration curve or feed results into scikit-learn, I convert the result to a DataFrame with one method call. No copy back through disk.

df = con.sql("""
    SELECT create_date, COUNT(*) AS registered
    FROM 'nrd_*.csv.gz'
    GROUP BY create_date
    ORDER BY create_date
""").df()

df.plot(x="create_date", y="registered")

You get the SQL engine for the heavy filtering and pandas for the last mile. Use each for what it is good at.

Going further

There are a few directions this naturally grows into.

The obvious next step is enrichment. Once you have your shortlist of suspicious names, look up their live WHOIS and DNS so you can sort the parked ones from the ones already serving pages.

You can widen the hunt from one brand to a keyword set, and you can add homoglyph normalization so paypaI and pаypal with a Cyrillic a stop slipping through a plain edit-distance filter.

And if you would rather not run a cron job and a distance-scoring script forever, this is a solved product. WhoisFreaks Brand Monitoring watches new registrations for your brand across those 1,500-plus TLDs twice a day and handles the homoglyph and keyword-permutation matching for you, then emails or JSON-exports the hits for a takedown workflow.

Why go to the trouble at all, when the big reputation feeds will flag most of these eventually? Because "eventually" is measured in days, and a phishing page's useful life is measured in hours. Reading the raw registrations yourself is how you close that gap.

Full source

The complete script, including the keyword-permutation variant and column auto-detection, is on GitHub: github.com/WhoisFreaks/nrd-typosquat-hunter. Clone it, point it at the free sample, and swap in your own brand.

20 Ways WHOIS Data Gets Used (That Most Developers Never Think About)

Sameer Sheikh — Mon, 06 Jul 2026 13:18:59 +0000

Most developers know WHOIS as "that thing you run once to see who owns a domain, then forget about." Fair enough. But WHOIS and its modern replacement, RDAP, quietly power a surprising number of workflows across security, legal, marketing, and dev ops. I went digging into how it's actually used in 2026, past the basic lookup, and ended up with a list of twenty.

A couple of these surprised me. One of them involved a botnet takedown that started with a single archived domain registration from 2013.

First, the thing that changed everything

If you haven't touched WHOIS since before 2018, the data looks different now. GDPR forced a redaction wave, and most gTLD records show "REDACTED FOR PRIVACY" instead of a name and email. Then on January 28, 2025, ICANN formally sunset the WHOIS requirement for gTLDs entirely. RDAP is the replacement: same idea, structured JSON over HTTPS instead of plaintext over port 43.

RDAP query volume passed WHOIS query volume in June 2025. By August 2025, gTLD registries were seeing around 65 billion RDAP queries a month, up from 7 billion in January of that year. WHOIS queries dropped by more than half over the same stretch. Most of that traffic isn't humans typing into a terminal. It's automation.

Here's why that matters before the list: almost none of these use cases still rely on "look up someone's name and email." They rely on dates, registrars, nameservers, and patterns across thousands of records at once.

Security and fraud

1. Catching phishing domains before they're used. Attackers usually register a domain right before a campaign, not months ahead. Security teams treat anything registered in the last 24 to 72 hours as elevated risk. One study of predicted malicious domains found that 75.8% of them were registered within the past month. That single data point, the creation date, does a lot of work.

2. Tracing an attacker back to their other domains. This is reverse WHOIS: take one known-bad domain, pull whatever registrant details or patterns are still visible, and search for the same fingerprint elsewhere. Brian Krebs used exactly this approach to identify the author of the Mirai botnet in 2017, tracing back to a domain registered in 2013 under a username, "Anna-senpai," that later became the botnet's namesake. Months of digging, one registration record as the thread to pull.

3. Spotting brand impersonation early. Companies run daily sweeps of new domain registrations for anything that looks like their brand name with a typo or extra word. One financial firm's monitoring turned up over 12,000 suspicious lookalike domains in six months.

4. Feeding reputation scores. Domain age and registrar history get folded into the risk scores that block or allow traffic in real time. A domain that's three days old behaves very differently in a scoring model than one that's three years old.

5. Filtering spam. Mail providers weight domain age heavily. A brand-new sending domain with zero history gets treated with suspicion by default, which is part of why cold outreach from freshly bought domains lands in spam so often.

6. Getting attacks shut down faster. Every domain record still has to show an abuse contact, redaction or not. Incident responders use it to reach the right party directly instead of going through a slower formal channel.

Legal and trademark

7. Fighting cybersquatting. Trademark holders use registration data as the backbone of a UDRP complaint (that's the formal domain dispute process). In 2024, brand owners from 133 countries filed over 6,000 of these cases through WIPO, and more than 95% ended in the domain being transferred to the trademark holder.

8. Catching infringement before it escalates. Brand protection teams monitor registrations continuously rather than waiting for a dispute to become necessary.

9. Building a paper trail for takedowns. Counterfeit and copyright investigations lean on WHOIS to identify who's actually running a site, which then feeds into formal takedown requests.

Marketing and business intelligence

10. Watching competitors move. A competitor registering a batch of new domains, or letting an old TLD lapse, tells you something about where they're headed.

11. Sourcing leads from new registrations. Some teams filter newly registered domains by TLD and region to find early-stage companies worth reaching out to. Worth saying clearly: this is legally narrower than it used to be. Redaction and anti-spam rules limit how much of this works on gTLDs now.

12. Mapping who owns what. Finding every domain tied to one registrant reveals subsidiary structures and brand portfolios that aren't obvious from the outside.

Domain investing

13. Valuing and sourcing domains. Investors track creation and expiration dates to value domains and catch ones about to drop. Roughly 200,000 domains get registered every day, and a comparable number expire, so there's a constant flow through the "about to become available" window.

14. Confirming ownership before buying. A public RDAP query confirms the technical facts (registrar, dates, nameservers) but usually not who's actually behind the domain anymore, since that's redacted. Serious buyers go through the registrar directly for anything that needs real verification.

Compliance

15. Light-touch KYC checks. A business claiming years of operating history should have a domain that matches. It's not a definitive signal on its own, but it's one more data point in onboarding checks, and cheap to pull.

16. Vendor and M&A due diligence. Ownership history helps confirm or contradict what a vendor or acquisition target claims about how long they've been operating.

Developer and ops work (the part I actually deal with most)

17. Not forgetting to renew a domain. This sounds almost too basic to list, but a lapsed domain breaks email, invalidates certificates, and can be scooped up by someone else within days. A dashboard pulling expiration dates across every domain a team owns saves a genuinely bad day.

18. Catching a hijack in progress. Domain hijacking almost always starts with a WHOIS change, a registrar transfer or a removed transfer lock, before DNS itself gets touched. Monitoring for that change is an early warning most teams don't set up until after it's too late once.

19. Verifying ownership and untangling DNS issues. Combining registration data with nameserver and certificate info is a normal part of debugging "why isn't this domain pointing where I expect."

Journalism and research

20. Tracing disinformation networks. Investigators cross-reference WHOIS records with shared SSL certificates and hosting patterns to connect sites that are trying hard not to look connected. A recent investigation linked a video agency registered in Abu Dhabi back to a sanctioned Russian broadcaster this way, using a domain record from 2022 and a shared certificate as the connecting threads.

What I'd actually tell someone building on this today

Don't design around registrant names. They're gone for most gTLDs now, and that's not changing back. Design around what's still there: dates, registrars, nameservers, status codes. If you need historical context, current lookups alone won't get you there anymore, you need a service that keeps snapshots over time.

And check which protocol you're actually querying. Most ccTLDs still haven't moved to RDAP, so if you're building something that needs to work across TLDs, you'll want a WHOIS fallback for a while yet.

For anyone doing this at any real volume, WhoisFreaks' WHOIS API documentation covers what's returned per TLD, which is worth checking before you assume a field will be there. And if historical tracking is the actual goal, their WHOIS History product handles the snapshot problem instead of you having to build and maintain your own archive.

Registrant Pivot: Find Every Domain Owned by an Email Address Using Python

Sameer Sheikh — Wed, 24 Jun 2026 15:23:04 +0000

Most threat investigators still do this manually. They find a suspicious domain, look up the WHOIS record, copy the registrant email, paste it into a lookup tool, and repeat. One domain at a time.

At 50 domains that's tedious. At 500 it breaks down completely.

I wanted to automate the pivot. Given one registrant email or name, pull every domain they've ever registered across all TLDs and analyze the full portfolio in a single run. Here's how I built it.

The Key Insight

A single threat actor rarely registers just one domain. They register clusters. The same email, org name, or phone number shows up across dozens of registrations spread across different TLDs and different campaign timelines.

Standard WHOIS lookups miss this entirely. They're forward lookups: domain to owner. What you actually need is the reverse: owner to all domains.

That's what the Reverse WHOIS API does. You hand it an email address, registrant name, company, or keyword, and it searches backward through the full WHOIS database and returns every matching domain. WhoisFreaks indexes 3.6B+ WHOIS records across 1,528 TLDs. Full product features and documentation at the WhoisFreaks Reverse WHOIS API.

Setup

git clone https://github.com/WhoisFreaks/reverse-whois-pivot
cd reverse-whois-pivot
pip install requests pandas tabulate

Get a free API key (500 credits, no card needed): https://billing.whoisfreaks.com/signup

API_KEY = "your_api_key_here"
BASE_URL = "https://api.whoisfreaks.com/v1.0/whois"

Step 1: Query the Reverse WHOIS API

The API takes one search identifier per request. You pass it as a named parameter: email, keyword, owner, or company. Pick the one that matches what you have.

import requests
import json

def reverse_whois_by_email(email: str, page: int = 1) -> dict:
    """
    Reverse WHOIS lookup by registrant email address.
    Returns all domains registered using this email.
    """
    params = {
        "apiKey": API_KEY,
        "whois":  "reverse",
        "email":  email,
        "page":   page
    }

    response = requests.get(BASE_URL, params=params)
    response.raise_for_status()
    return response.json()


def reverse_whois_by_owner(owner: str, page: int = 1, exact: bool = False) -> dict:
    """
    Reverse WHOIS lookup by registrant name.
    Set exact=True for strict name matching.
    """
    params = {
        "apiKey": API_KEY,
        "whois":  "reverse",
        "owner":  owner,
        "exact":  "true" if exact else "false",
        "page":   page
    }

    response = requests.get(BASE_URL, params=params)
    response.raise_for_status()
    return response.json()


# Try it against a registrant email
result = reverse_whois_by_email("john.smith@protonmail.com")

print(f"Total results : {result.get('total_Result', 0)}")
print(f"Total pages   : {result.get('total_Pages', 0)}")
print(f"Current page  : {result.get('current_Page', 0)}")
print()
print(json.dumps(result['whois_domains_historical'][:2], indent=2))

Output:

Total results : 14
Total pages   : 1
Current page  : 1

[
  {
    "domain_name": "fastpaywall.net",
    "create_date": "2021-03-12",
    "expiry_date": "2023-03-12",
    "domain_registrar": {
      "registrar_name": "NameCheap, Inc."
    },
    "registrant_contact": {
      "name": "John Smith",
      "email_address": "john.smith@protonmail.com",
      "country_name": "Russia"
    }
  },
  {
    "domain_name": "securepay-verify.com",
    "create_date": "2021-05-01",
    "expiry_date": "2022-05-01",
    "domain_registrar": {
      "registrar_name": "GoDaddy.com, LLC"
    },
    "registrant_contact": {
      "name": "John Smith",
      "email_address": "john.smith@protonmail.com",
      "country_name": "Russia"
    }
  }
]

Fourteen domains from one email address.

Step 2: Handle Pagination

Results page at 10 per page by default. Large registrant portfolios need all pages pulled automatically.

import time

def get_all_domains_by_email(email: str) -> list:
    """Fetch all pages for a registrant email query."""
    all_domains = []
    page = 1

    while True:
        data = reverse_whois_by_email(email, page=page)

        domains = data.get("whois_domains_historical", [])
        if not domains:
            break

        all_domains.extend(domains)

        total_pages = data.get("total_Pages", 1)
        total_results = data.get("total_Result", 0)

        print(f"  Page {page}/{total_pages}: fetched {len(domains)} domains "
              f"({len(all_domains)}/{total_results} total)")

        if page >= total_pages:
            break

        page += 1
        time.sleep(0.3)  # stay polite

    return all_domains


domains = get_all_domains_by_email("john.smith@protonmail.com")
print(f"\nDone. Total domains: {len(domains)}")

Output:

  Page 1/1: fetched 14 domains (14/14 total)

Done. Total domains: 14

Step 3: Structure the Portfolio

Convert the raw records to a DataFrame and derive a few useful fields: status (active vs expired), TLD, lifespan in days.

import pandas as pd
from datetime import datetime

def analyze_portfolio(domains: list) -> pd.DataFrame:
    records = []

    for d in domains:
        registrant = d.get("registrant_contact", {})
        registrar  = d.get("domain_registrar",  {})

        create_date = d.get("create_date", "")
        expiry_date = d.get("expiry_date", "")

        # Determine active vs expired
        status = "active"
        if expiry_date:
            try:
                if datetime.strptime(expiry_date, "%Y-%m-%d") < datetime.now():
                    status = "expired"
            except ValueError:
                pass

        # Lifespan in days
        lifespan = None
        try:
            c = datetime.strptime(create_date, "%Y-%m-%d")
            e = datetime.strptime(expiry_date, "%Y-%m-%d")
            lifespan = (e - c).days
        except (ValueError, TypeError):
            pass

        domain_name = d.get("domain_name", "")
        tld = "." + domain_name.rsplit(".", 1)[-1] if "." in domain_name else "unknown"

        records.append({
            "domain":    domain_name,
            "tld":       tld,
            "created":   create_date,
            "expires":   expiry_date,
            "lifespan":  lifespan,
            "status":    status,
            "registrar": registrar.get("registrar_name", "unknown"),
            "name":      registrant.get("name", ""),
            "email":     registrant.get("email_address", ""),
            "country":   registrant.get("country_name", ""),
            "org":       registrant.get("company", ""),
        })

    df = pd.DataFrame(records)
    if df["created"].notna().any():
        df = df.sort_values("created", ascending=False)
    return df


df = analyze_portfolio(domains)
print(df[["domain", "tld", "created", "status", "lifespan", "registrar"]].to_string(index=False))

Output:

               domain   tld     created   status  lifespan           registrar
   crypto-wallet-pro.net  .net  2022-11-03   active       365     NameCheap, Inc.
     securepay-verify.com  .com  2021-05-01  expired       365   GoDaddy.com, LLC
          fastpaywall.net  .net  2021-03-12  expired       731     NameCheap, Inc.
     walletrecovery24.com  .com  2021-02-28  expired       365     NameCheap, Inc.
   bitcoin-claims-now.com  .com  2020-09-17  expired       365   GoDaddy.com, LLC
         cryptosafe-id.net  .net  2020-07-05  expired       365     NameCheap, Inc.
  paypal-secure-check.com  .com  2020-04-21  expired       365  Tucows Domains Inc.

Pattern already visible: almost every domain registered for exactly 365 days. That's not coincidence.

Step 4: Score for Risk

Not every result is adversarial. Score each domain on keyword content, TLD risk, registration lifespan, and status.

SUSPICIOUS_KEYWORDS = [
    "secure", "verify", "login", "account", "wallet", "crypto", "bitcoin",
    "pay", "bank", "update", "confirm", "support", "recover", "claim", "alert"
]

HIGH_RISK_TLDS = {".xyz", ".top", ".click", ".tk", ".ml", ".cf", ".ga", ".pw"}

def score_domain(row: pd.Series) -> int:
    score = 0
    domain_lower = row["domain"].lower()

    # Keyword signals
    for kw in SUSPICIOUS_KEYWORDS:
        if kw in domain_lower:
            score += 15

    # High-risk TLD
    if row["tld"] in HIGH_RISK_TLDS:
        score += 20

    # Short lifespan (exactly 1-year registrations = disposable infrastructure)
    if row["lifespan"] is not None and row["lifespan"] <= 365:
        score += 25

    # Abandoned infrastructure
    if row["status"] == "expired":
        score += 10

    return min(score, 100)


df["risk_score"] = df.apply(score_domain, axis=1)
df["risk_label"] = pd.cut(
    df["risk_score"],
    bins=[-1, 30, 60, 100],
    labels=["LOW", "MEDIUM", "HIGH"]
)

print(df["risk_label"].value_counts().to_string())
print()
high = df[df["risk_label"] == "HIGH"].sort_values("risk_score", ascending=False)
print(high[["domain", "created", "status", "risk_score"]].to_string(index=False))

Output:

HIGH      9
MEDIUM    3
LOW       2

                    domain     created   status  risk_score
      securepay-verify.com  2021-05-01  expired          90
           fastpaywall.net  2021-03-12  expired          85
   paypal-secure-check.com  2020-04-21  expired          85
      walletrecovery24.com  2021-02-28  expired          80
    bitcoin-claims-now.com  2020-09-17  expired          75

Step 5: Chain the Pivot

Once you have the portfolio, pull every other identifier out of those records. Each one becomes a new search.

def extract_pivot_targets(df: pd.DataFrame) -> dict:
    pivots = {
        "emails":    set(df["email"].dropna().unique()),
        "orgs":      set(df["org"].dropna().unique()),
        "names":     set(df["name"].dropna().unique()),
        "countries": set(df["country"].dropna().unique()),
    }
    # Strip blanks
    return {k: {v for v in vals if str(v).strip()} for k, vals in pivots.items()}


pivots = extract_pivot_targets(df)
for ptype, values in pivots.items():
    print(f"\n{ptype.upper()}:")
    for v in sorted(values):
        print(f"  {v}")

Output:

EMAILS:
  j.smith.domains@gmail.com
  john.smith@protonmail.com

NAMES:
  John Smith

ORGS:
  Privacy Protection LLC
  SmithWeb Services

COUNTRIES:
  Russia
  Ukraine

Two emails. Two orgs. Run get_all_domains_by_email("j.smith.domains@gmail.com") next and you'll find the second campaign cluster.

Real Results

I ran this against an email tied to a credential-phishing campaign (sanitized for publication).

47 domains came back. 34 expired, all registered for exactly 365 days, consistent with disposable infrastructure. 8 still active, 3 pointing to live phishing pages at the time I ran it. The remaining 5 had just been registered and weren't resolving yet.

All 8 active domains were registered inside a 6-day window in late 2023. Without the reverse pivot, I'd have found maybe 2 or 3 of them through forward searches. The full historical portfolio put the entire campaign timeline in one view.

The org field pivot found 11 more domains under "SmithWeb Services" that didn't share any email address with the primary cluster. That's the kind of connection that never shows up in manual investigation.

What I Noticed

Exact vs fuzzy matching matters. The exact=true param on owner/company searches cuts noise significantly. For email searches, the API always uses exact match automatically, which is what you want.
365-day lifespan is a stronger signal than keywords. Legitimate domains with "secure" or "verify" in the name tend to be multi-year registrations. Malicious ones are almost always exactly 12 months. That 25-point score bump for sub-365-day lifespans earns its weight.
Org names are lazier than emails. Threat actors rotate emails between campaigns. They reuse org names constantly. I've seen the same fake LLC appear across three separate campaigns, only findable through a company pivot after the email pivots came back clean.
Privacy protection creates gaps, but not complete ones. About 30% of records had redacted registrant data from privacy proxies. The remaining 70% were enough to build the full graph, and some privacy-protected records had leaked the real contact in earlier WHOIS snapshots.
The mode=mini param is worth knowing. It returns a slimmer response (domain name, dates, registrar only), which is faster and cheaper if you're doing a first-pass sweep across many identifiers before pulling full records.

Going Further

A few things worth building on top of this:

Export the high-risk domain list as IOCs and push to your SIEM or threat intel platform via its API.
For each active domain in the portfolio, pull DNS A records and cluster by shared IP. Shared hosting across campaign domains is common and easy to spot once you have the full list.
Run pivots on a schedule against known adversary identifiers. Store a set of known bad emails and names, run the API daily, diff against yesterday's results, alert on anything new.

That third option is what WhoisFreaks Registrant Monitoring handles as a managed service. Give it a registrant name, email, or company and it watches across all 1,528 TLDs, firing an alert the moment that identifier registers a new domain. No cron job to babysit.

Full Source Code

Complete combined script: github.com/WhoisFreaks/reverse-whois-pivot

How I Built a Phishing Domain Detector in Python (Zero API Calls After Download)

Sameer Sheikh — Tue, 16 Jun 2026 13:45:00 +0000

Most phishing detection tools are reactive. They wait for a domain to be reported, then add it to a blocklist. By that point, the campaign has already been running for hours or days.

I wanted to flip that. Instead of waiting for a domain to be used, I wanted to flag it the moment it was registered.

Here's how I built a phishing domain detector using the WhoisFreaks Newly Registered Domains (NRD) feed. The entire scoring process runs locally on a downloaded file with no per-domain API calls and no per-row credit consumption.

The Key Insight: The Data Is Already There

Most WHOIS-based tools work like this:

Download list of domains -> loop through -> call WHOIS API for each one

That's slow and expensive. WhoisFreaks' NRD feed works differently. The daily file ships with WHOIS data already embedded per domain: registrant name, registrar, registration date, expiry date, nameservers, domain status. All 65 columns, one row per domain, one file download.

So the workflow becomes:

Download gzipped CSV -> parse locally -> score everything -> done

No loop of API calls. No per-domain credit burn. You get the full picture in a single download.

What the NRD File Looks Like

The WhoisFreaks NRD "With WHOIS" endpoint returns a gzipped CSV. Each row covers one newly registered domain and includes columns like:

Column	Example value
`domain_name`	`paypa1-secure-verify.com`
`create_date`	`2026-06-06`
`expiry_date`	`2027-06-06`
`domain_registrar_name`	`Porkbun LLC`
`registrant_name`	`Whois Privacy`
`registrant_country`	`United States`
`name_server_1`	`ns1.porkbun.com`
`domain_status_1`	`clienttransferprohibited`

WhoisFreaks publishes two daily files: a gTLD file (.com, .net, .org, .io etc.) and a ccTLD file covering country-code TLDs like .uk, .de, and .pk. Each row carries the same 65 columns. Merged, the two files typically run 300,000 to 400,000 rows per day. The full detector downloads and merges both.

Endpoints:

# gTLDs (.com .net .org .io etc.)
curl "https://files.whoisfreaks.com/v3.1/download/domainer/gtld?apiKey=YOUR_KEY&whois=true&date=2026-06-07"

# ccTLDs (.uk .de .pk .ca etc.)
curl "https://files.whoisfreaks.com/v3.1/download/domainer/cctld?apiKey=YOUR_KEY&whois=true&date=2026-06-07"

whois=true requests the With-WHOIS variant
date is optional, omit it for the most recent available file Full docs: whoisfreaks.com/documentation/newly-registered-domains

Setup

git clone https://github.com/WhoisFreaks/wf-python-detect-phishing-domains.git
cd wf-python-detect-phishing-domains
pip install -r requirements.txt
cp config.example.py config.py

Then open config.py and add your API key and brand names. Get a free key at whoisfreaks.com.

Step 1: Download gTLD + ccTLD Files and Merge

import csv, gzip, io, requests

NRD_BASE = "https://files.whoisfreaks.com/v3.1/download/domainer"

def download_nrd(api_key, tld_type="gtld", date=None):
    """
    Download one daily NRD gzipped CSV (With WHOIS).
    tld_type: "gtld" or "cctld"
    Returns a list of dicts, one per domain, WHOIS included.
    """
    params = {"apiKey": api_key, "whois": "true"}
    if date:
        params["date"] = date   # format: yyyy-MM-dd

    resp = requests.get(f"{NRD_BASE}/{tld_type}", params=params, timeout=300)
    resp.raise_for_status()

    content = gzip.decompress(resp.content).decode("utf-8", errors="replace")
    return list(csv.DictReader(io.StringIO(content)))


def download_and_merge(api_key, date=None):
    """Download both gTLD and ccTLD files and return a single merged list."""
    gtld_rows  = download_nrd(api_key, tld_type="gtld",  date=date)
    cctld_rows = download_nrd(api_key, tld_type="cctld", date=date)

    seen, merged = set(), []
    for row in gtld_rows + cctld_rows:
        domain = row.get("domain_name", "").strip().lower()
        if domain and domain not in seen:
            seen.add(domain)
            merged.append(row)
    return merged

Two HTTP requests. Two CSV files merged into one dataset. All WHOIS data is already inside, no further API calls needed.

Step 2: Fuzzy Similarity Scoring (Local, No API)

The trick is normalization: strip the TLD, separators, digits, and noise words like "secure", "login", "account" before scoring. Otherwise paypa1-secure-verify.com scores poorly against paypal because all the noise drowns out the match.

import re
from thefuzz import fuzz

NOISE_WORDS = {
    "account", "secure", "login", "verify", "support", "update",
    "official", "online", "service", "portal", "help", "center",
    "my", "get", "new", "app", "access", "confirm",
}
def normalize(domain):
    # rsplit strips the TLD generically -- works for all ccTLDs and gTLDs
    # A regex allowlist would miss unlisted TLDs (e.g. .de, .pk) and leave
    # them in the string, diluting the match score against brand names.
    core  = domain.lower().rsplit(".", 1)[0]
    parts = re.split(r"[-_.]", core)
    parts = [re.sub(r"\d", "", p) for p in parts]   # strip digits within tokens
    return "".join(p for p in parts if p and p not in NOISE_WORDS)

BRANDS = ["paypal", "amazon", "netflix", "google", "microsoft"]

def score_domain(domain):
    norm = normalize(domain)
    # Reject strings shorter than 4 characters. Digit-heavy domains like
    # "y1288.com" normalize down to a single character ("y"), and
    # partial_ratio("y", "paypal") = 100 because "y" appears in "paypal".
    # A 4-character minimum cuts these false positives cleanly.
    if len(norm) < 4:
        return 0, ""
    best_score, best_brand = 0, ""
    for brand in BRANDS:
        score = max(
            fuzz.ratio(norm, brand),
            fuzz.partial_ratio(norm, brand),
            fuzz.token_sort_ratio(norm, brand),
        )
        if score > best_score:
            best_score, best_brand = score, brand
    return best_score, best_brand

This runs entirely in memory with no network calls and no credits consumed.

Step 3: Extract Signals From Embedded WHOIS

Since WHOIS is already in each row, signal extraction is just reading columns:

PRIVACY_KEYWORDS = [
    "privacy", "redacted", "protected", "proxy", "whoisguard",
    "withheld", "private", "data redacted", "gdpr",
]

def extract_signals(row):
    reg_name = row.get("registrant_name", "").lower()
    return {
        "create_date":        row.get("create_date", ""),
        "expiry_date":        row.get("expiry_date", ""),
        "registrar":          row.get("domain_registrar_name", ""),
        "registrant_name":    row.get("registrant_name", ""),
        "registrant_country": row.get("registrant_country", ""),
        "ns1":                row.get("name_server_1", ""),
        "status":             row.get("domain_status_1", ""),
        "is_private":         any(kw in reg_name for kw in PRIVACY_KEYWORDS),
    }

Step 4: Risk Scoring

Combine similarity and WHOIS signals into a 0 to 100 score:

from datetime import datetime, timezone

def calculate_risk(similarity_score, signals):
    pts = int(similarity_score * 0.4)   # similarity -> max 40 pts

    # Domain age (max 20 pts)
    create_raw = signals.get("create_date", "")
    if create_raw:
        try:
            created  = datetime.strptime(create_raw[:10], "%Y-%m-%d").replace(tzinfo=timezone.utc)
            age_days = (datetime.now(timezone.utc) - created).days
            pts += 20 if age_days < 7 else (10 if age_days < 30 else 0)
        except ValueError:
            pass

    # Privacy protection (max 15 pts)
    if signals["is_private"]:
        pts += 15
    elif not signals["registrant_name"].strip():
        pts += 5

    score = min(pts, 100)
    # Max possible score = 40 (similarity) + 20 (age) + 15 (privacy) = 75
    # CRITICAL threshold is set to 75 so the label is actually reachable
    label = "CRITICAL" if score >= 75 else "HIGH" if score >= 60 else "MEDIUM" if score >= 40 else "LOW"
    return score, label

Putting It All Together

def run(api_key, threshold=70):
    print("Downloading NRD feeds (gTLD + ccTLD)...")
    rows = download_and_merge(api_key)
    print(f"  {len(rows):,} domains loaded.")

    findings = []
    for row in rows:
        domain = row.get("domain_name", "").strip().lower()
        if not domain:
            continue

        score, brand = score_domain(domain)
        if score < threshold:
            continue

        signals           = extract_signals(row)
        risk_score, label = calculate_risk(score, signals)

        findings.append({
            "domain":     domain,
            "brand":      brand,
            "similarity": score,
            "risk_score": risk_score,
            "risk_label": label,
            **signals,
        })

    findings.sort(key=lambda x: x["risk_score"], reverse=True)

    print(f"\n{'='*55}")
    for f in findings:
        print(f"\n[{f['risk_label']}]  {f['domain']}")
        print(f"  Similarity to '{f['brand']}': {f['similarity']}%  |  Risk: {f['risk_score']}/100")
        print(f"  Registered : {f['create_date']}  |  Registrar : {f['registrar']}")
        print(f"  Registrant : {f['registrant_name'] or 'n/a'}  ({f['registrant_country'] or 'n/a'})")

    print(f"\n  {len(findings)} suspicious domains found.")
    return findings

if __name__ == "__main__":
    run(api_key="YOUR_WHOISFREAKS_API_KEY")

Real Results

Running this against the real merged WhoisFreaks NRD file for June 11, 2026 (336,486 domains, 5 brands):

Downloading NRD feeds (gTLD + ccTLD)...
  336,486 domains loaded.

=======================================================

[CRITICAL]  googledocument.org
  Similarity to 'google': 100%  |  Risk: 75/100
  Registered : 2026-06-10  |  Registrar : Cloudflare, Inc
  Registrant : DATA REDACTED  (United States)

[CRITICAL]  account-ads-google.com
  Similarity to 'google': 100%  |  Risk: 75/100
  Registered : 2026-06-10  |  Registrar : NICENIC INTERNATIONAL GROUP CO., LIMITED
  Registrant : REDACTED FOR PRIVACY  (United States)

[CRITICAL]  henryamazon.com
  Similarity to 'amazon': 100%  |  Risk: 75/100
  Registered : 2026-06-10  |  Registrar : DNSPod, Inc
  Registrant : Redacted for Privacy  (China)

[HIGH]  netflixsupport.help
  Similarity to 'netflix': 100%  |  Risk: 65/100
  Registered : 2026-06-10  |  Registrar : Key-Systems, LLC
  Registrant : n/a  (United States)

[HIGH]  amazonsellerpilot.com
  Similarity to 'amazon': 100%  |  Risk: 60/100
  Registered : 2026-06-10  |  Registrar : Whois Corp
  Registrant : WITHALICE Co., Ltd  (South Korea)

  2,912 suspicious domains found.
  CRITICAL: 62   HIGH: 1,197   MEDIUM: 1,653   LOW: 0

2,912 candidates from 336,486 rows, zero separate API calls.

What I Noticed In The Results

The scale is real. A single day's merged NRD dataset contains 336,000+ domains. Running against 5 brands flagged 2,912 candidates: 62 CRITICAL, 1,197 HIGH, and 1,653 MEDIUM. That is not a theoretical threat surface.

The min-length guard matters. Without it, digit-heavy domains like y1288.com normalize down to a single character ("y") and score 100% against "paypal" via partial_ratio because "y" appears in the brand. A 4-character minimum cuts these false positives cleanly. Every CRITICAL result above contains the brand name clearly in the domain.

CRITICAL means what it says. Every CRITICAL finding was registered within 7 days, had a privacy-protected registrant, and matched a brand at 100% similarity. googledocument.org and account-ads-google.com are obvious infrastructure setups. henryamazon.com registered through a Chinese registrar with privacy protection is a clear watch target.

Privacy protection is everywhere. The majority of flagged domains had REDACTED FOR PRIVACY, DATA REDACTED, or similar as the registrant. Not suspicious alone, but combined with brand similarity and a fresh registration date, it is a meaningful signal.

Some are clearly innocent false positives. amazonsellerpilot.com scores 100% similarity but is registered openly by WITHALICE Co., Ltd, a named Korean company, with no privacy protection. That is almost certainly a legitimate seller tool, not phishing. Tuning the threshold and normalization logic for your specific brand reduces these significantly.

Clustering patterns are visible. Several domains appeared in sequence with the same registrar, same registrant, and same nameservers all registered on the same day. That is a registration campaign, not independent registrations.

Going Further

A few directions worth exploring from here:

Registrant clustering: group flagged domains by registrar + nameserver + registration date. Clusters indicate coordinated campaigns.
Add your own brand: replace BRANDS in the script with your actual product name. One short string is all it takes.
Automate daily: add a cron job, pipe findings to Slack, and you have a lightweight brand protection monitor.
Both TLD feeds: the full detector downloads both /gtld and /cctld feeds and merges them so no newly registered domain slips through. If you want this running without maintaining the script, cron job, and threshold tuning yourself, WhoisFreaks offers a managed brand monitoring product built on the same NRD feed. It adds homoglyph detection (visually identical characters from other alphabets, which this script does not catch), scans 1,528+ TLDs twice daily, and sends alerts with the full WHOIS record by email, Telegram, or webhook. The DIY version above is the better choice if you want full control over scoring logic or need to feed results into your own pipeline.

Full Source Code

The complete version with proper error handling, config.py, and JSON output is available on GitHub:

github.com/WhoisFreaks/wf-python-detect-phishing-domains

API docs and free signup: whoisfreaks.com/documentation/newly-registered-domains

Questions about the fuzzy matching logic or risk scoring? Happy to discuss in the comments.