/domain-check

Availability tools disagree, and the one most people reach for is the one most likely to be wrong. This skill is a reconciliation policy, not another lookup client. It says which source wins when two sources conflict, what a negative result does and does not prove, and what the handler still does not know when the verdict lands.

The house rule is wrap, don't build. Keyless servers already implement lookup with sensible fallbacks — saidutt46/domain-check and stucchi/domain-check-mcp both do RDAP with a WHOIS fallback, and Brave Labs' domain-checker-mcp ships a DNS-then-RDAP hybrid. Use one of those, or plain curl and nslookup. What none of them handle is aftermarket detection and a documented precedence order. That gap is this skill.

Structured execution spec: protocol.yon. Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

Why this exists

A GoDaddy-backed availability tool reported available: true for seven domains: hexis.com, shim.com, mortise.com, limen.com, vinculum.com, honeyourcraft.com and poweryouragent.com. Every one was registered and parked on a broker nameserver — afternic.com, namefind.com, or domainmarket.com.

The failure was confirmed independently. A request to https://rdap.verisign.com/com/v1/domain/hexis.com returns HTTP 200, meaning registered. A genuinely unregistered domain and a random control both return 404. So RDAP was right, DNS was right, and the registrar layer was the unreliable one.

A hypothesis, not a diagnosis. GoDaddy's availability endpoint takes a checkType parameter of FAST (the default) or FULL, documented as "Optimize for time (FAST) or accuracy (FULL)". It also returns a definitive boolean meaning the answer was verified against the registry. A tool sitting on the default fast path would plausibly produce exactly these false positives. That fits the evidence. It has not been confirmed against a live trace, and this skill does not assert it as the cause.

The precedence order

Apply authority to each fact separately: RDAP owns registry status, DNS corroborates delegation, and a verified candidate-specific listing supplies sale evidence. Preserve disagreements; an operator nameserver is not proof of a sale or purchase opportunity.

1. RDAP — authoritative. Resolve the registry endpoint through the IANA (Internet Assigned Numbers Authority) bootstrap file at https://data.iana.org/rdap/dns.json. Its shape is services: [[tlds], [urls]]; .com resolves to https://rdap.verisign.com/com/v1/. HTTP 404 means the name is not in the registry. HTTP 200 means it is registered.

Never hardcode a per-registry base URL. A misrouted query returns 404 for the wrong reason, and a 404 for the wrong reason is indistinguishable from availability. Bootstrap first, then query.

2. DNS — fast pre-filter and corroboration. Query NS (nameserver) and SOA (start of authority) records with nslookup -type=NS or dig, against two resolvers, one of which is 8.8.8.8. A delegated nameserver is strong evidence of registration. Absence of one is weak evidence of anything.

Never treat an NXDOMAIN as final without an authoritative query. Under RFC 2308, negative answers are cached, and a resolver can keep serving NXDOMAIN for a name that has since been registered. A stale negative reads as availability — the same error class this skill exists to prevent, arriving from the DNS side instead of the registrar side. Query an authoritative server before believing a negative, and let RDAP settle it either way.

3. Operator and sale evidence. A nameserver match identifies a configured operator or parking service only. It neither overrides registry evidence nor proves the candidate is listed for sale. Use these exact domain keys:

afternic.com   sedo.com       dan.com       domainmarket.com
bodis.com      namefind.com   sedoparking.com

Match exact configured domain boundaries, not a raw substring. Lowercase an ASCII DNS hostname and remove its final dot. It matches a configured key only when equal to that key or ending in . plus that key (ns1.sedo.com → sedo.com). Reject malformed or unresolved hostname identities as unknown; do not guess a registrable domain from the last two labels of an arbitrary hostname. A naive substring test produces real false positives: sedo matches ns1.sedona.com, and dan.com matches ns1.sheridan.com. Both are ordinary registered domains, and flagging one as brokered is the same false verdict running in the opposite direction.

Separately recognize a complete DNS label exactly equal to domain-is-4-sale as an unverified sale marker, never a substring or proof. Parking, an operator match or this marker alone leaves sale and purchasability unknown. Use registered-and-brokered only with registration evidence plus a separately verified, candidate-specific broker sale listing. A listing still does not guarantee a completed purchase or a current final price.

4. Registrar API — price context only. Consult a registrar for pricing, premium tiers, and aftermarket asking prices. Never take its binary answer. Treat any available: true from a registrar as provisional until RDAP corroborates it.

What a negative result does not prove

An RDAP 404 means "probably registrable". It does not mean purchasable. All of these still block a registration that RDAP says is free:

• Reserved strings. Registries withhold names by policy.
• Sunrise and landrush restrictions. A new TLD (top-level domain) may accept only trademark holders during its early phases.
• Registry-premium pricing. The name is available at a price that is not the standard registration fee.

The opposite direction also fails. A domain in redemption or pending-delete returns RDAP 200 and looks taken — it is taken, but it is also not yet registrable by you, and it may become free later. And a registered domain with no delegated nameservers looks empty to DNS. That is the false-negative case, and it is the reason DNS never outranks RDAP.

A forward expiry date is not a renewal. A .com auto-renews at its expiration date by registry default, so the expiry event advances a year whether or not anyone paid to keep the name. Reading that as "the registrant renewed" is the standard trap on an expiring domain. The registrar then holds a 45-day grace in which it may delete the name for a credit — so the expiry date later reverting is not a data error, it is the registrar releasing the name toward deletion.

A third-party mirror is not a live source. WHOIS mirrors and lookup sites serve cached records stamped with their own fetch date, sometimes weeks stale. When a mirror disagrees with RDAP, the mirror is stale — that is not new information. Read the mirror's fetch timestamp before believing anything it reports, and let the registry-direct RDAP answer stand.

Coverage and rate limits

Roughly 189 country-code top-level domains have no RDAP service at all. For those, WHOIS is the only fallback. WHOIS is free-text, per-registry, and parse-fragile. Label any WHOIS-derived verdict as lower-confidence and say so in the output.

Rate limits are the operational constraint on any bulk sweep:

• rdap.org caps at 10 requests per 10 seconds.
• WHOIS is punitive. It will IP-ban (internet protocol address ban), and on a shared address the ban can be inherited from someone else's abuse. Roughly one query per second per address is the safe default.

For a bulk candidate sweep, query the registry-direct RDAP endpoint from the bootstrap rather than an aggregator, add backoff, and never fan out in parallel.

The flow

Single domain. Bootstrap the RDAP endpoint for the TLD. Query it. Query DNS from two resolvers. If nameservers are present, test them against the broker list. Optionally consult a registrar for price. Reconcile by precedence, then report.

Bulk sweep. Same sequence per candidate, run serially with backoff. DNS first is legitimate as a cheap ordering step, but never settles a candidate by itself. Every candidate follows the authoritative RDAP or declared WHOIS fallback path before its final registration verdict. Preserve DNS/RDAP conflicts; do not turn a parking match into a bulk shortcut.

Reporting

Every verdict carries three parts. Do not drop the third.

1. The verdict. Available, registered, registered-and-brokered, or unknown. Report registration evidence separately from parking/operator, verified sale listing and purchasability. Fail current availability to unknown when contradictory live evidence cannot be reconciled; preserve the RDAP observation rather than discarding it.
2. The sources that agreed. Name them. "RDAP 404 and no nameservers on two resolvers" is a verdict a reader can audit; "available" is not.
3. The residual uncertainty. Price and premium status are unknown unless a registrar was consulted. Registry policy restrictions are unknown either way. Say this even when the verdict is confident.

A worked example of the reporting shape:

example.com   REGISTERED (illustrative reporting shape, not a live lookup)
  Registry-direct RDAP 200 + nameserver operator match.
  Parking/operator evidence is separate; sale listing and purchasability unknown.
  Price unknown; no registrar consulted.

Boundary

• Not /investigate — that gathers facts over a codebase; this reconciles conflicting external lookups into one verdict.
• Not /double-check — that re-verifies a claim already on the table; this produces the claim.
• Not a lookup client. It does not reimplement RDAP or WHOIS. It decides which answer wins.
• It does not register anything. Buying a domain is a spend and a handler's call — surface it, never execute it.

Human output. This skill's handler-facing output obeys the human-output contract (human-output/SKILL.md).

Next skills. On completion, run the Next Skills protocol (next-skills/SKILL.md): surface the next-skills recommendations from front-matter for the caller to pick. Offer only — never auto-invoke.

Self-improvement. On completion, run the Self-Improvement Protocol (self-improve/SKILL.md): apply its signal taxonomy and threshold to this run; surface any surviving proposal for handler approval. Conservative — silent otherwise. Never auto-apply.