RDAP and WHOIS are often compared as if they were two versions of the same lookup page. They are protocols, and the differences show up before any registration field appears. WHOIS sends a text query over TCP port 43 and returns text chosen by the server. RDAP uses HTTP semantics, typed query paths, JSON objects, links, notices, and machine-readable errors. That makes RDAP easier to build against, but it does not guarantee that a server will publish a registrant name, return every optional field, or answer without policy restrictions.
The policy position also changed. On 28 January 2025, RDAP became the definitive source for registration information from ICANN-contracted generic top-level domain registries and registrars. Most of those contracted parties no longer have to provide a WHOIS service. Country-code TLD managers operate under their own rules, and support remains uneven. A current implementation therefore needs two separate ideas: prefer RDAP where an authoritative service exists, and preserve a carefully labelled compatibility path where traditional WHOIS still supplies useful data.
The 2025 gTLD cutover changed the default
ICANN announced the gTLD WHOIS sunset on 27 January 2025, effective the next day. Its current user guidance says all gTLD registries and accredited registrars must provide RDAP under the gTLD profile. It also names three exceptions to the WHOIS sunset: .com, .name, and .post remain subject to WHOIS service requirements. A port 43 response may still exist elsewhere, but continued availability is different from a contractual obligation. New gTLD tooling should not assume that a legacy WHOIS host will remain authoritative or maintained.
That statement applies to ICANN's contracted gTLD system. It does not convert country-code TLDs into gTLDs, and it does not require every ccTLD to publish an RDAP endpoint. .io is a ccTLD, as are .de, .jp, .se, and .uk. Their managers choose services under local policy and technical practice. Some publish RDAP through the IANA bootstrap; some rely on WHOIS or a web lookup; some expose different data through different channels. Coverage claims need a date and a source rather than a list copied from another article.
- Contracted gTLDs use RDAP as the definitive registration-data service.
- .com, .name, and .post are the stated gTLD exceptions where WHOIS service remains required.
- ccTLD service and publication rules vary by registry and can change independently of ICANN's gTLD contracts.
- A working WHOIS server is not proof that WHOIS remains the authoritative or contractually required path.
WHOIS has almost no response contract
RFC 3912 describes a small transaction. The client connects to TCP port 43, sends text terminated by carriage return and line feed, receives one or more lines, and treats connection close as the end of the response. The RFC says the content is human-readable, but it does not define a domain-registration schema. It also records the protocol's lack of internationalization, access control, integrity, and confidentiality. Those are properties of the wire protocol, not complaints about one registry's formatting.
Everything beyond that minimal exchange is service convention. A server can choose labels, date formats, encodings, disclaimers, referral text, not-found messages, and throttling language. A parser may normalize common labels successfully and still fail after a registry changes a heading. Error handling is especially awkward because no protocol-level status distinguishes not found, malformed input, policy refusal, or temporary overload. A client has to interpret text, an empty response, a closed connection, or a referral based on provider-specific rules.
RDAP is a family of specifications
No single RFC is the whole RDAP protocol. RFC 7480 explains how RDAP uses HTTP, including GET requests, content negotiation, redirects, negative answers, rate-limit responses, and access-control considerations. The 2015 RFC 7482 and RFC 7483 established the query and JSON formats. They are now obsolete, replaced by current RFC 9082 and RFC 9083. RFC 9224 covers authoritative service discovery. Calling RFC 9224 the RDAP specification confuses discovery with transport, queries, and responses.
- RFC 7480: HTTP use, response classes, redirects, errors, authentication capability, and extensibility.
- RFC 7482 and RFC 7483: the original query and JSON specifications, retained here for the protocol's standards history.
- RFC 9082 and RFC 9083: the current query and JSON specifications that obsolete RFC 7482 and RFC 7483.
- RFC 9224: selection of an authoritative RDAP base URL from IANA bootstrap data.
RDAP's structure is stable enough for shared parsing, but implementations can add registered extensions and profiles can impose extra requirements. Clients should check objectClassName, rdapConformance, content type, and the fields they use. They should also tolerate optional fields, additional members, nested entities, and links that lead to more authoritative data. JSON removes the need to guess whether Creation Date is a label. It does not remove the need to validate the response or understand the provider's profile.
Transport and error handling
WHOIS sends the query and response without protocol-level encryption. RDAP uses ordinary HTTP mechanisms, and current public services are normally reached over HTTPS. The client can send an Accept header for application/rdap+json, follow standard redirects, apply HTTP caching rules, and use normal TLS validation. The server can return 200 for a resource, 3xx when another location should be queried, 404 when it has no matching resource, or another 4xx response when policy or request syntax prevents an answer.
RFC 9083 gives RDAP errors a JSON form with an errorCode and optional title and description, continuing the model introduced by RFC 7483. RFC 7480 describes 429 for rate limiting and allows familiar HTTP signalling such as Retry-After. This is much better than matching a sentence in a WHOIS disclaimer, but it is not permission to hardcode one request budget for every service. Each operator can apply its own limits and access policy. A robust client backs off, caches bootstrap data, records the source, and distinguishes not found from unavailable.
Schemas do not decide what becomes public
RDAP can represent domains, events, status values, nameservers, secure DNS data, entities with roles, and contact properties in jCard form. RFC 9083 is the current response specification, replacing RFC 7483 while preserving the core object model. A response may contain a registrar entity, abuse contact, registrant entity, registration event, expiration event, and links to related records. The schema tells a client where such data belongs. It does not require every server to return every object, and an entity role does not establish ownership of a domain. The server may omit or redact fields according to policy and applicable law.
For contracted gTLDs, the current ICANN Registration Data Policy governs collection, transfer, publication, and lawful disclosure. It took effect on 21 August 2025 and was revised on 12 May 2026. Section 9 identifies data that contracted registries and registrars must, may, or conditionally publish. That policy is separate from the IETF protocol. RFC 7483 can define a registrant entity without making the registrant's personal contact details public.
RDAP can use HTTP authentication and can support differentiated responses. Capability is not entitlement. A server may offer only anonymous public access, may require a provider-specific authenticated process, or may direct eligible requestors to a disclosure workflow. ICANN's cutover announcement points users seeking nonpublic gTLD data to the Registration Data Request Service for participating registrars or to the sponsoring registrar's disclosure process. A client should not assume that adding an Authorization header will reveal redacted data.
Discovery and actual coverage
WHOIS discovery often depends on a maintained table, a registry referral, or conventions outside RFC 3912. RDAP has an official bootstrap process. For a domain query, the client takes the TLD label, finds it in IANA's DNS bootstrap, and selects a published base URL. Separate IANA files map IPv4 ranges, IPv6 ranges, and autonomous system number ranges to RDAP services. RFC 9224 defines how clients use those registries and deal with multiple candidate URLs.
Coverage is a snapshot. The IANA DNS bootstrap retrieved for this article on 10 July 2026 had publication timestamp 2026-07-09T01:00:03Z. It listed 1,199 TLD labels across 592 service groups. The file included ccTLD entries for .au, .br, .nl, and .uk. It did not list .de, .io, .jp, .kz, or .se at that moment. Broad claims about ccTLD coverage are therefore unsafe. The bootstrap may change after publication, so clients should refresh it and reports should retain the publication value they used.
{
"version": "1.0",
"publication": "2026-07-09T01:00:03Z",
"services": [
[["au"], ["https://rdap.cctld.au/rdap/"]],
[["uk"], ["https://rdap.nominet.uk/uk/"]],
[["br"], ["https://rdap.registro.br/"]],
[["nl"], ["https://rdap.sidn.nl/"]]
]
}A bootstrap entry means IANA has published a base URL after its registration process and basic service checks. It does not promise identical public fields, unlimited availability, or a particular local registration policy. Absence also needs careful wording: it means the DNS bootstrap did not provide a service for that label in the cited snapshot, not that no registry website, WHOIS server, registrar interface, or future RDAP service exists. Store source and observation time with every coverage report.
Domain, IP, and autonomous system queries
RDAP is not limited to domain names. Current RFC 9082 includes paths for IP networks and autonomous system numbers, and the corresponding RFC 9083 objects use object classes such as ip network and autnum. These rules update the original RFC 7482 and RFC 7483 specifications. Discovery follows the resource: domain labels use the DNS bootstrap, IP addresses and CIDR blocks use the IPv4 or IPv6 bootstrap, and AS numbers use the ASN bootstrap. That is a material difference from domain-focused WHOIS tools, even though legacy WHOIS services also exist for Internet number resources.
GET /v1/rdap?query=example.com
GET /v1/rdap?type=ip&query=8.8.8.8
GET /v1/rdap?type=ip&query=2001:4860:4860::8888/128
GET /v1/rdap?type=autnum&query=AS174DomScan defaults /v1/rdap to type=domain. IP-shaped and AS-shaped input requires an explicit type so an ambiguous string is not silently routed as a domain. The response wrapper reports query, type, status, the upstream object under rdap when one was found, an entity summary, and lookup_summary evidence. Consumers should use the type and objectClassName rather than assuming every successful response has domain events or nameservers.
Raw RDAP and normalized WHOIS in DomScan
DomScan keeps a distinction between protocol-oriented and compatibility-oriented endpoints. GET /v1/rdap is the protocol-oriented route. For a direct RDAP success, it preserves the upstream JSON under rdap and adds summaries describing the query type, source, object class, entities, and fallback evidence. This is the better endpoint when an application needs RDAP-native events, notices, remarks, links, entities, secureDNS, or an IP network or autnum object without flattening it into a domain-only schema.
The source evidence matters. DomScan has a WHOIS-first policy for selected TLDs whose practical service path is more reliable through traditional WHOIS. In those cases, /v1/rdap can return a translated RDAP-shaped object with lookup_summary.data_source set to whois. A domain lookup can also use a labelled DNS fallback when registration services are unavailable, in which case rdap is null and the response is not equivalent to registration data. Code that ignores lookup_summary can mistake a fallback classification for an authoritative RDAP answer.
GET /v1/whois is the normalized compatibility route. It checks its cache, prefers RDAP for fresh registration data, maps the result into stable fields such as registrar, dates, status, nameservers, DNSSEC, contacts, and privacy signals, and can fall back to traditional WHOIS or labelled DNS evidence. GET /v2/whois fetches RDAP and traditional WHOIS in parallel when possible, then adds useful traditional fields and raw WHOIS text without replacing the normalized RDAP base. Both endpoints expose source metadata so callers can tell which path produced the result.
- Use /v1/rdap for RDAP-native domain, IP, or autnum objects and inspect lookup_summary on every response.
- Use /v1/whois when an application wants a stable normalized domain-registration shape across RDAP and traditional WHOIS paths.
- Use /v2/whois when traditional port 43 enrichment and raw WHOIS evidence are useful alongside normalized RDAP fields.
- Do not treat a DNS fallback as a registration record or a redacted entity as evidence about the registrant's identity.
What WHOIS History actually records
DomScan WHOIS History is not a purchased WHOIS archive, a global crawler, or an ownership-history database. It is an observation log created by qualifying DomScan lookups. A fresh, successful, RDAP-backed GET /v1/whois or GET /v2/whois request can record at most one normalized snapshot for a domain in a UTC day. A cache hit does not record another snapshot. Bulk WHOIS requests, history reads, traditional WHOIS-only fallbacks, and DNS fallbacks do not add snapshots.
The service compares observed registrar name, expiry value, nameservers, status codes, DNSSEC, transfer-lock state, and privacy or redaction detection. It stores creation and update dates but does not compare those two fields automatically. It does not store historical registrant identity or contact fields. A registrar-name difference is an observed value change, not proof that a transfer completed; an expiry change may reflect renewal or upstream correction. Missing dates in the timeline can simply mean that no qualifying fresh lookup occurred.
- At most one recorded normalized snapshot per domain per UTC day.
- Only fresh successful RDAP-backed single-domain WHOIS lookups qualify.
- Returned history and summaries describe DomScan's recorded observation window, not the domain's complete lifetime.
- The log does not prove ownership, transfer, or the identity behind redacted registration data.
Migration guidance for clients
A new client should begin with the resource type, perform IANA bootstrap discovery, query the selected RDAP base, validate the HTTP response and JSON object, and preserve notices, remarks, links, and source timestamps. Cache bootstrap data but refresh it on a defined schedule and recover when an endpoint moves. Treat 404, policy refusal, rate limiting, malformed responses, and network failure as different outcomes. Never turn every error into available, because unavailable registration data says nothing conclusive about whether a domain is registered.
Existing WHOIS consumers can migrate field by field. Add RDAP-native storage first, then build a normalized projection for the fields the application actually uses. Keep the raw object or a stable reference so parser changes remain auditable. Retain traditional WHOIS only for explicit exceptions and coverage gaps, label that source in the result, and measure how often it is used. Do not make fallback invisible. A caller deciding whether to investigate a domain needs to know whether the evidence came from authoritative RDAP, parsed WHOIS, cache, or DNS heuristics.
The working rule
For contracted gTLD registration data, start with RDAP. For ccTLDs, consult the current IANA bootstrap and the registry's own documentation instead of assuming coverage. Use DomScan /v1/rdap when the native object and source path matter, and use the normalized WHOIS endpoints when a stable cross-protocol domain schema matters more. Preserve the source either way. That one field prevents a structured fallback, a redacted response, or a lookup-driven history snapshot from being described as evidence it never was.