# The state of domain availability data

**Run:** 2026-08-20T13:40:53+00:00  
**Sample:** `2026Q3.1` · 20 cases · `sha256:be91a4ba354e44cb…`  
**Method, data and harness:** published alongside this report; re-run quarterly.

> Results are stated **as of the run date**. Competitors improve, TLDs migrate
> registries, and endpoints rot. A one-shot benchmark is a launch post; this is
> intended as a tracked series, and prior runs are kept rather than overwritten.

## The one-sentence version

**A checker built the ordinary way reports that the domain serving this report
is available for purchase.**

`scopeweb.io` was registered on 2026-08-20, resolves, and is answering the API
requests that produced these numbers. The naive RDAP baseline in the table below
classifies it as unregistered. Both halves are checkable by any reader in under a
minute — that is the point of choosing this example.

## Why this exists

Availability checkers answer one question — *is this name taken?* — and the
industry treats the answer as binary. It is not. An RDAP `404` can mean the name
is unregistered, **or** that the service you asked cannot route that TLD, **or**
that it knows only part of the zone. Those are indistinguishable in the response,
and conflating them produces confident, specific, wrong answers.

### The finding that motivated the sample

While admitting RDAP endpoints, we tested GoDaddy Registry's own endpoint for
`.co` — the TLD GoDaddy Registry operates. We tested **seven** `.co` names
independently confirmed registered by DNS, and it was **wrong on five of the
seven**. Small sample, stated plainly, and the failures are individually
reproducible:

| Domain | Resolves | GoDaddy `.co` RDAP |
|---|---|---|
| `stowed.co` | yes | 200 ✓ |
| `bit.co` | yes | 200 ✓ |
| `angel.co` | yes | **404** ✗ |
| `vine.co` | yes | **404** ✗ |
| `start.co` | yes | **404** ✗ |
| `t.co` | yes | **404** ✗ |
| `google.co` | yes | **404** ✗ |

Five of the seven returned `404` from the registry operator's own endpoint. Not
an aggregator. Not a stale mirror — the operator, about its own TLD. Seven names
is not a census, and this is not offered as one; it is offered as an existence
proof that *trust the operator* is not a sound rule.

*Provenance:* this table comes from the **endpoint admission ledger**
(admission run, 2026-08-20), not from the benchmark run below. They are separate
runs against separate lists — and the benchmark independently reproduces the same
failure class, which is corroboration rather than double-counting.

The lesson is not "GoDaddy is bad". It is that the trust hierarchy cannot be
*trust the operator* — it has to be **trust what passed admission**, where
admission means an endpoint answered correctly on names that were independently
confirmed registered, across registrars, label lengths and registration eras.

## Method

1. **Ground truth is independent of every system tested.** A name with an `A` or
   `NS` record is registered. No checker's opinion is consulted. Cases DNS cannot
   settle are excluded from correctness scoring.
2. **Systems are measured on what they claim.** Capabilities a system does not
   offer are marked *not offered* — never scored zero.
3. **No credentials, no numbers.** An adapter without credentials reports
   `not_run` and its cells stay empty.
4. **Polite.** Free tiers, paced requests, small sample, no parallel load.
5. **The dangerous direction is counted separately.** Calling a registered name
   unregistered is the error that costs a user money. It gets its own column.

## Results

Every row foots to the full sample of **20**. `Excluded` are cases where DNS
cannot establish ground truth, so no system is scored on them; they are shown
rather than dropped. `Errors` are hard failures — a different epistemic state
from an abstention, and counted separately for that reason.

| System | Correct | Wrong | Abstained (`unknown`) | Errors | Excluded (no ground truth) | Total | **False-unregistered** |
|---|---|---|---|---|---|---|---|
| `scopeweb` | 18 | 0 | 0 | 0 | 2 | 20 | **0** |
| `rdap_aggregator` | 9 | 9 | 0 | 0 | 2 | 20 | **9** |
| `domainr` | *not run* | | | | | | |
| `domscan` | *not run* | | | | | | |

**`domainr`** — not run. API credentials required (client_id or RapidAPI key); none supplied. The adapter is in the published harness and populates on the next run once access exists.

**`domscan`** — not run. API key required (x-api-key). Free tier is 10,000 credits/month with no card, but obtaining a key requires creating an account, which this harness does not do. Set DOMSCAN_API_KEY to populate these cells. The adapter is in the published harness and populates on the next run once access exists.

**`domscan`** — not run, and the reason is a correction worth publishing.

DomScan is a live product at **domscan.net**: *Domain Intelligence API for
Developers*, 147 documented endpoints, `GET /v1/status` for availability,
RDAP-backed. It is the nearest same-generation comparator to this system, and
notably **not** architecturally naive — its responses already carry `source`
(`rdap` / `cache` / `dns` / `whois`) and `confidence` (`authoritative` /
`heuristic`), the same distinction this report argues for.

An earlier draft of this section asserted DomScan was dormant, on the evidence
that `domscan.com` serves a parking lander. That was wrong: the `.com` is a name
they did not defend, and the product lives on the `.net`. The failure is
recorded in full below, because a report whose thesis is *absence of evidence is
not evidence* cannot quietly fix an instance of exactly that mistake.

Their API authenticates with `x-api-key`. The free tier is 10,000 credits/month
with no card required — comfortably enough for this 20-case sample — but
obtaining a key requires creating an account, which this harness does not do.
The adapter is written, targets `GET /v1/status`, parses their `source` and
`confidence` fields, and populates on the next run once a key is supplied.

*(Aside, now correctly scoped: their `domscan.com` is parked, and our own
`audit_domain` classifies it `dormant`. True, mildly interesting, and not
evidence about the product.)*

### The series, already

The case for a tracked series rather than a one-shot post made itself within
a day of the first run. Between these two runs, the TLD ladder went in:
when no admitted RDAP endpoint exists for a TLD, discovery walks to Tier 2 —
authoritative WHOIS over TCP/43, with the server taken from IANA's root
database and required to clear the same multi-positive admission bar.

| Scopeweb run | Correct | Wrong | Abstained | Excluded | False-unregistered |
|---|---|---|---|---|---|
| 2026-08-20T13:24:27+00:00 (before) | 12 | 0 | 6 | 2 | 0 |
| 2026-08-20T13:40:53+00:00 (after) | 18 | 0 | 0 | 2 | 0 |

Every abstention in the first run was `.co`. `.co` has no working RDAP
endpoint at any address we could find — GoDaddy Registry's own is wrong on
five of seven — but `whois.registry.co` answers correctly, and passed
admission on auto-sourced, DNS-confirmed positives including `google.co`,
the exact name their RDAP `404`s.

The abstentions became answers **without** the wrong column moving: still 0
wrong, still 0 false-unregistered. That is the shape an improvement is
supposed to have here — coverage up, error rate unchanged at zero. A
coverage gain that moved the error column would not be a gain.

### Abstention is honest, and it is also a gap we are closing

`abstained` counts cases answered `unknown`. A checker that abstains where it
cannot know is not failing to answer — it is declining to guess, and the column
that decides a purchase is the last one.

But abstention has a cost, and pretending otherwise would be its own dishonesty:
every `unknown` is coverage this system does not yet have. All five abstentions
here are `.co`, where no endpoint has passed admission. That is a roadmap item
with receipts, not a posture — the admission ledger is published, states which
endpoints are proven and on what evidence, and names the one that was rejected
and why. Each TLD admitted converts abstentions into answers.

### Where the two disagree

| Domain | DNS ground truth | Scopeweb | Naive RDAP baseline | Why it is in the sample |
|---|---|---|---|---|
| `stowed.co` | registered | registered | **unregistered** | bootstrap-absent TLD; resolves, so registered. The original false-unre |
| `t.co` | registered | registered | **unregistered** | bootstrap-absent TLD, 1-char label; GoDaddy .co endpoint 404s it despi |
| `google.co` | registered | registered | **unregistered** | bootstrap-absent TLD, high-profile; same false-404 class. |
| `angel.co` | registered | registered | **unregistered** | bootstrap-absent TLD; 404s on the rejected .co endpoint. |
| `vibecode.me` | registered | registered | **unregistered** | bootstrap-absent TLD, young registration (2025) sourced via CT logs. |
| `vibe.me` | registered | registered | **unregistered** | bootstrap-absent TLD, launch-era registration (2008). |
| `google.sh` | registered | registered | **unregistered** | bootstrap-absent TLD, rarely-supported ccTLD. |
| `scopeweb.io` | registered | registered | **unregistered** | bootstrap-absent TLD; registered 2026-08-20, same-day registration edg |
| `start.co` | registered | registered | **unregistered** | Resolves to a parking operator (sedoparking). Parked classification ca |

### One correction in the baseline's favour

During the benchmark run, the naive baseline abstained on `ibm.com` rather than
answering. Re-testing `rdap.org/domain/ibm.com` three times, spaced, returned
`200` on all three. That abstention was therefore a transient flake rather than
a coverage gap, and it is counted in the baseline's favour above. Noting it
here because a benchmark that only corrects errors in its own direction is not
a benchmark.

## Capability comparison

Availability is one dimension. These are reported honestly as *not offered*
where a system does not claim them.

Two different claims are kept apart here. **Measured** means we ran it.
**Documented** means we read the vendor's published spec but did not run it —
reported because refusing to credit a competitor's stated capability would be
the same error as scoring them zero.

| Capability | Scopeweb (measured) | Naive RDAP baseline (measured) | Domainr | DomScan (documented) |
|---|---|---|---|---|
| Registration status | yes | yes | claimed | **yes** |
| Distinguishes `unknown` from a negative | **yes** | no | unknown | **yes** — `error` field, `confidence` |
| States evidence grade | **yes** — `rdap_source` | no | unknown | **yes** — `source` + `confidence` |
| active / parked / dormant classification | **yes** | *not offered* | *not offered* | unknown |
| Liveness score with versioned formula | **yes** | *not offered* | *not offered* | unknown |
| Endpoint admission ledger (published) | **yes** | *not offered* | *not offered* | unknown |
| Bulk / MCP surface | **yes** (MCP) | *not offered* | unknown | **yes** (bulk + MCP) |

`unknown` means we could not run it and did not find it documented, so we assert
nothing. It is not a zero. DomScan's `source`/`confidence` fields mean the
evidence-grading idea is **not unique to this system** — which is worth saying
in our own benchmark, and is why running them is the priority for the next run.

## Where the differentiation actually is

This section exists because the first draft of this report was about to claim
novelty for something a competitor already ships.

**Evidence-grading is not unique to this system.** DomScan's `/v1/status`
returns `source` (`rdap` / `cache` / `dns` / `whois`) and `confidence`
(`authoritative` / `heuristic`) today. The central idea this report argues for —
that a verdict must carry how it was obtained — is one a serious competitor has
already implemented. Saying so plainly is worth more than the novelty claim
would have been.

**Their index is broader than ours.** Per their published OpenAPI (v2.14.0, 147
paths, read 2026-08-20): DNS, SSL and certificate transparency, email auth
(DKIM/DMARC), reputation, typosquat detection, social handles, hosting
detection, domain valuation, lifecycle, watchlists and brand monitoring. This
system exposes ten tools. On breadth of *lookup*, we are behind, and a fair
report says so before it says anything else.

**What differs, stated narrowly and from evidence:**

| | Scopeweb | DomScan (per published spec) |
|---|---|---|
| Endpoint admission ledger, published, with attached evidence | yes | not documented |
| Rejected-endpoint ledger (negative institutional memory) | yes | not documented |
| Abstention as a contractual behaviour, not a field value | yes | `confidence` field |
| Benchmark that includes itself and publishes its own failures | yes | not documented |
| Draft hosting + live preview URLs | yes | none (their `/v1/hosting` is hosting *detection*) |
| Domain ownership verification (DNS TXT challenge) | yes | none (their `/v1/email/verify` is email) |
| Registration / purchase pipeline | in progress | **0 documented endpoints** |
| MCP surface | yes | **yes** — `domscan.net/mcp` is live |

*Absence here means absent from their published OpenAPI as of the read date, not
proven absent from the product. Their MCP surface is a case in point: it is not
in that OpenAPI, and it exists — so these cells are evidence about documentation,
and are labelled that way.*

The honest summary: **they have built a better lookup.** The bet this system is
making is not that it grades evidence better — it is that a lookup should end in
a live site: scan, verify ownership, draft, preview, claim, deploy. That is a
different product, and this report deliberately does not score it, because
nobody else in the table is trying to enter it.

## Latency

Same vantage point, same run, sequential and paced.

| System | median ms | p95 ms |
|---|---|---|
| `scopeweb` | 1006 | 4454 |
| `rdap_aggregator` | 192 | 863 |

Latency here is *cold* — one domain per request, no cache warmth. Scopeweb's
warm path (cache hits within freshness tier) is materially faster and is
reported as a separate contract, because averaging the two would flatter it.

## What we found wrong with ourselves

The sample is adversarial toward this system too. Failures found and fixed
while building it:

- **Three TLDs answering confidently wrong.** `.io`, `.co`, `.me` and `.sh` are
  absent from IANA's RDAP bootstrap. Falling through to an aggregator whose 404
  means "cannot route this TLD" produced false *unregistered* verdicts for live,
  registered domains. Fixed: only an admission-tested authoritative endpoint may
  assert non-registration; anything else is downgraded to `unknown`.
- **A two-sided admission test that a poisoned endpoint passes.** Testing one
  known-registered name plus one gibberish name admits GoDaddy's `.co` endpoint
  if the positive happens to be one of the two names it knows. Fixed: multiple
  positives, all must pass, spanning NS operators, label lengths and eras.
- **Our harness ignored our own rate limiter.** The 2026Q3.1 run exhausted the
  60/hour scan budget partway through, and one case (`lootlens.ai`) came back
  `429` and was recorded as a hard error — a quietly degraded run, which is
  worse than a loud failure. "Be polite" turned out to be a rule we were
  applying to other people's APIs and not our own. The harness now honours
  `Retry-After` up to a bounded wait and labels a rate-limited case distinctly
  from an error, so a throttled run can never masquerade as a complete one.
- **And the same mistake again, one axis over.** After fixing the harness to
  treat `429` distinctly, the post-deploy smoke suite reported nine
  rate-limited checks as nine *failures*. Identical conflation, different
  tool — a red run that actually means "you used your budget" trains people
  to ignore red runs. Rate limiting is now a first-class third outcome in
  both. Finding the same error class twice in one session is the argument
  for writing rules down rather than remembering them.
- **Probing the wrong address and nearly publishing it.** The first draft of
  this report asserted that DomScan was dormant, having checked `domscan.com`,
  `.io`, `.dev`, `.app` and `.ai`. Five wrong addresses do not sum to one right
  one, and checking more TLDs *looked* like diligence while being the opposite:
  the fix was to go back to the source citation, where the URL was `domscan.net`
  all along. Caught the same way as every other entry here — a control (the
  original research URLs) disagreed with a confident conclusion. This is the
  same error class the report is about, committed by the report.
- **Our own benchmark sampling.** The first control run against Verisign — a
  correct endpoint — was flagged `ADMITTED-WEAK` because all four positives sat
  on Cloudflare nameservers. The diversity gate caught the sample, not the
  registry.

Every one of these was caught by a control, not by review.

## Reproducing this

```bash
git clone <repo> && cd bench
python3 bench.py      # writes results.json
python3 report.py     # writes REPORT.md
```

Sample `2026Q3.1` is frozen and hashed (`be91a4ba354e44cb…`).
Changing the sample means bumping the version, so a result can always be traced
to the exact list that produced it.