Blog / July 12, 2026 · 7 min read
RDAP vs. WHOIS: How Domain Availability Checking Actually Works in 2026
Ask ten domain tools how they check availability and you'll get ten variations of the same legacy answer: query WHOIS, parse the text, hope the format didn't change. That answer is now obsolete. ICANN formally retired the port-43 WHOIS requirement for gTLDs in January 2025; RDAP — the Registration Data Access Protocol — is the authoritative path.
What RDAP changes
RDAP serves registration data as structured JSON over HTTPS. For availability checking, the contract is elegant: query the registry's RDAP endpoint for a domain, and a 404 response means no registration object exists — the name is unregistered. A 200 returns the registration with events (created, expires), status codes, and the sponsoring registrar.
Structure matters more than transport. WHOIS text required per-registry parsers that broke silently; RDAP responses conform to a schema that software — and AI agents — can consume without heuristics. Internationalized domains work natively. Rate limits are still real, but they're enforced per standard HTTP semantics instead of mystery port-43 throttling.
Where DNS fits
DNS is the fast, weak signal. An NS query answered with NXDOMAIN (RCODE 3) says no delegation exists, which usually means unregistered — but registered-and-undelegated domains produce the same answer, and negative caching can serve stale results. DNS-over-HTTPS resolvers like Cloudflare's make this check trivial to run from anywhere.
The correct architecture layers them: RDAP for registry truth, DoH for reach and speed when a registry's RDAP is unavailable, and honest labeling of which method produced each answer. DomainFind.ai encodes that as a confidence score — 0.97+ for RDAP-verified availability, around 0.75 for DNS-inferred — so consumers can decide when to re-verify.
Why this matters for agents specifically
A human eyeballing a search page can tolerate ambiguity; an autonomous agent registering a domain as part of a deployment pipeline cannot. Agents need machine-readable certainty semantics: what do you know, how do you know it, how sure are you. That's the difference between an availability API built for page rendering and one built for reasoning loops.
If you're building on our API: filter on status plus confidence, not status alone. And for anything high-stakes, treat sub-0.9 confidence as a prompt to call check_domain again — RDAP endpoints recover fast, and the second pass usually upgrades the answer.