WHOIS vs RDAP: how to find out who owns a domain

What WHOIS is, and what it never was

WHOIS is about as simple as a protocol gets. You open a TCP connection to port 43 on a server, send a domain name followed by a carriage return and line feed, and the server sends back some text and closes the connection. RFC 3912, which obsoleted RFC 954 and RFC 812, is four pages long and specifies the transport and nothing else.

That is the problem, and the RFC says so itself: it defines no structure for the response, no encoding, no authentication and no security. Every registry and registrar invented its own layout. Field names differed, date formats differed, the same concept appeared under three labels across three registries, and parsing the output reliably meant maintaining a per-registry set of rules that broke whenever a registry reformatted its template.

It was also non-hierarchical in practice. Finding the right server for a domain meant consulting a list somewhere, or querying a thin registry that referred you to a registrar's own server for the detail, a two-step dance every client had to implement itself.

None of this made WHOIS useless — it ran the internet's registration lookups for decades — but it made automation fragile and it made access control impossible. There is no way in the protocol to distinguish a person looking up one domain from a scraper harvesting a registry, and no way to show different data to each.

# What the whois command actually does
printf 'example.com\r\n' | nc whois.verisign-grs.com 43

# The same via the client, which also handles the referral to the registrar
whois example.com

What RDAP is, and where the transition stands

RDAP is a set of IETF standards, not a single document. RFC 7480 defines how it uses HTTP; RFC 9082 defines the query URL patterns (obsoleting RFC 7482); RFC 9083 defines the JSON responses (obsoleting RFC 7483); and RFC 9224 defines how a client finds the authoritative server for a given name, address or AS number (obsoleting RFC 7484). Together these are Internet Standard 95.

The practical differences matter more than the document list. RDAP runs over HTTPS, so queries are encrypted and servers are authenticated. It returns JSON with defined member names, so the same field appears in the same shape from every compliant server. It supports differentiated access, so a server can return more to an authenticated, authorised requester than to an anonymous one — something WHOIS cannot express. And it bootstraps itself: IANA publishes machine-readable files that map every TLD, IP range and AS number block to the server that answers for it.

For generic TLDs, ICANN has set the dates. ICANN states that all gTLD registries and registrars are required to provide RDAP services using the gTLD RDAP Profile, and that as of 28 January 2025 they are no longer required to provide WHOIS services — with .com, .name and .post as named exceptions. The Registration Data Policy, which supersedes the earlier Temporary Specification and sets out how registration data is processed, took effect on 21 August 2025 at the end of a transition period that ran from 21 August 2024.

Read the WHOIS date carefully, because it is the one most often misstated: gTLD contracted parties are no longer required to run WHOIS. Several still do, voluntarily, and the three named TLDs still must. So a working port-43 answer for a gTLD in 2026 is not evidence that the sunset did not happen.

Country-code registries are outside ICANN's gTLD contracts entirely and each sets its own course. Many now run RDAP; a substantial number still answer only over WHOIS, or over a web form and nothing machine-readable at all.

Querying RDAP yourself

An RDAP query is an HTTPS GET. The path patterns are fixed by RFC 9082: /domain/{name}, /ip/{address or CIDR}, /autnum/{number}, /nameserver/{name} and /entity/{handle}. What varies is the base URL, and that is what the IANA bootstrap files tell you.

IANA publishes four bootstrap registries as JSON: dns.json for top-level domains, ipv4.json and ipv6.json for address space, and asn.json for AS numbers. Each maps a set of resources to the base URLs of the servers authoritative for them. A correct client fetches the relevant file, finds the entry covering the resource, and appends the path. Checked on 17 September 2026, the DNS bootstrap file was published 16 September 2026 and covered 1,202 top-level domains.

The response is JSON with a defined shape, so you can query fields directly rather than pattern-matching free text. That difference is the entire reason the transition happened.

A practical note on rate limits: registry terms forbid high-volume automated querying and every registry throttles. A handful of lookups by hand is fine; a loop over a list of domains will start getting 429 responses, and that is by design rather than a bug to work around.

# 1. Which server answers for .com?
curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0][] == "com") | .[1][0]'
# -> https://rdap.verisign.com/com/v1/

# 2. Ask it about the domain
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq .

# 3. Pull out just the parts you came for
curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq '{status, events: [.events[] | {a: .eventAction, d: .eventDate}]}'

# IP and AS number lookups use the same shape, at the RIR that holds them
curl -s https://rdap.arin.net/registry/ip/203.0.113.10 | jq .

The structure of an RDAP response

An RDAP domain object is a JSON document with a small number of members that carry nearly everything you would have read out of a WHOIS template.

• objectClassName, always domain for a domain query, plus ldhName (the ASCII form) and unicodeName where the name is internationalised. handle is the registry's own identifier for the registration.

• status, an array of strings. These are the EPP status codes, and they are the most operationally useful part of the record. The next section covers them.

• events, an array of eventAction and eventDate pairs. registration is the creation date, expiration is the expiry, last changed is the last modification to the registration, and last update of RDAP database tells you how fresh the answer is rather than anything about the domain.

• entities, an array of the people and organisations attached to the registration, each with a roles array — registrar, registrant, technical, administrative, abuse — and contact details in jCard format, which is a JSON array-of-arrays representation of vCard. It is awkward to read by eye and unambiguous to parse, which is the trade it makes.

• nameservers, each with its own ldhName and sometimes ipAddresses (glue), and secureDNS, which reports whether the zone is signed and carries the DS records the parent holds.

• notices and remarks, free-text blocks carrying terms of service and, importantly, redaction statements. links carries the canonical self URL and often a link to the registrar's own RDAP record for the domain.

• rdapConformance, listing the extensions the server implements. An RDAP server that implements RFC 9537 declares it here, and that is what lets it say precisely which fields it removed and why, rather than silently omitting them.

EPP status codes, and the four that actually matter

Status codes come from EPP, the protocol registrars use to talk to registries, and are defined in RFC 5731 for domains and RFC 3915 for the grace periods. ICANN publishes a plain-language reference for them. They divide into client codes, set by your registrar at your request, and server codes, set by the registry, which your registrar cannot lift alone.

Most codes are informational. ok means no restrictions are set — which, read properly, means no locks either. inactive means the domain has no nameservers delegated. addPeriod, autoRenewPeriod, transferPeriod and renewPeriod are grace windows following the corresponding operation. pendingTransfer means a transfer is in progress and has a clock on it.

Four are worth acting on rather than merely reading, and two of them are things you want to see:

• clientTransferProhibited. The registrar lock. Without it, a transfer request started by anyone with access to your registrar account completes on a timer whether you notice or not, and recovering the domain afterwards is a formal dispute rather than a support ticket. It is free at every registrar and takes about a minute. Our scanner reports its absence as a failure for exactly that reason, and never reports its presence as a fault.

• clientUpdateProhibited. Blocks changes to nameservers and contacts until it is explicitly lifted. A silent nameserver change is the quiet version of stealing a domain: the registration still says your name while the site, the mail and every certificate that can be issued for the name belong to someone else. We report its absence as a warning.

• clientHold or serverHold. The domain has been pulled from the parent zone deliberately. It resolves nowhere regardless of how the DNS is configured. clientHold usually means an unpaid renewal or an unverified registrant email address and your registrar can lift it; serverHold comes from the registry and typically means a dispute, a court order, or registration data escalated past the registrar.

• redemptionPeriod and pendingDelete. The domain is in the deletion lifecycle. See the next section, because the difference between them is the difference between an expensive recovery and none at all.

One thing not to misread: a newly registered or newly transferred domain often carries serverTransferProhibited for the first 60 days. That is a registry lock that expires on its own, and it is not a substitute for asking your registrar to set the client lock.

The expiry lifecycle, stage by stage

An expired domain does not become available immediately, and the stages are set by registry policy rather than by your registrar. The figures below are the ones our own tools state, and they are typical rather than universal — a specific registry can differ.

• Auto-renew grace period, up to 45 days after expiry. The registrar can still renew at the ordinary price. Most registrars renew automatically by default, and this window is the margin on top of that. The domain usually still resolves.

• Redemption period, roughly 30 days. Only the previous registrant can recover the name, and only through a manual, chargeable registry operation: the registrar files a restore request, the domain moves to pendingRestore, and the registrar files a closing report to complete it. Fees are typically an order of magnitude above a renewal, it cannot be done from a control panel, and not every registrar advertises that it is possible at all. The domain has been removed from the zone by this point, so DNS for it is already failing.

• pendingDelete, around 5 days. The redemption window has closed and a restore is no longer available at any price. At the end of it the name is released. For sought-after names, drop-catch services compete for the moment of release, so simply waiting and registering it manually is unlikely to work.

Read that as a cost ladder. Catching an expiry at the 30-day mark is a renewal. Catching it in redemption is an expensive recovery. Missing it entirely means someone else can register your domain, receive your mail, obtain valid certificates for it, and collect every password-reset link still addressed to it.

An expiry date on its own is not a crisis, and a tool that colours a normal renewal cycle red teaches people to ignore it. What the date tells you is when the automatic renewal has to succeed. The thing to confirm is that auto-renew is on for that specific domain — it is a per-domain setting at most registrars, and it is switched off by transfers and by bulk imports — that the card on file has not expired, and that the registrant email address is a mailbox somebody reads. An address at the domain itself is a poor choice, since it stops working at exactly the moment you need it.

Why the registrant is redacted, and what the abuse contact is for

Registration data is no longer public by default. Under ICANN's Registration Data Policy, which took effect on 21 August 2025 and superseded the earlier Temporary Specification, the contact details of natural persons are withheld from the public record. Many owners additionally pay for a privacy or proxy service, in which case the published contact genuinely is that company rather than a mask over a hidden value.

None of this reflects badly on a domain, and it is not a misconfiguration to fix. Our scanner reports it as information and deducts nothing.

It is worth distinguishing four states rather than reading every blank the same way, which is what our report does: published, where the registry publishes the registrant and it is shown; not carried, where this registry has no such field at all, so nothing is being withheld; redacted by the registry, where a value exists and policy withholds it; and behind a privacy service, where the published contact is a real third party acting for the owner. RFC 9537 is how a modern RDAP server declares exactly which fields it removed, so a well-implemented server tells you which of these you are looking at.

The abuse contact is the route that remains open. Every ICANN-accredited registrar is required to publish one, and it appears in the RDAP response as an entity with the abuse role. It is the correct channel for reporting phishing, malware distribution or spam originating from a domain — not for a commercial enquiry or a dispute over the name, which belong to the registrar's ordinary support and to the UDRP respectively.

For gTLDs there is also ICANN's Registration Data Request Service, a centralised way to submit a request for non-public registration data with a stated legitimate interest. It is a request, not a lookup: the registrar decides. Beyond those routes, there is no legitimate way to recover redacted registrant data, and any service claiming to have one is either selling you stale pre-2018 records or something worse.

When RDAP has nothing: registries that still answer only over WHOIS

A fair number of country-code registries have not joined the RDAP bootstrap. Checked against IANA's bootstrap file on 17 September 2026, the following were absent from it, and are the ones our own scanner names as unbootstrappable: .de, .ro, .eu, .it, .es, .ch, .at, .ru, .jp, .cn, .us, .io, .co and .me. Several of these publish very little even on port 43, and a few answer only through a web form with a CAPTCHA.

Treat that list as a dated snapshot. Registries join the bootstrap registry over time, and the file itself is republished frequently — re-check it rather than trusting a list in a guide, including this one.

For a ccTLD with no RDAP, the fallback order is: the registry's own port-43 WHOIS, then the registry's public web lookup, then nothing. Some ccTLDs deliberately publish almost no data at all as a matter of national policy, and that is a policy outcome rather than a failure of your lookup.

What matters is how a tool reports the gap. Ours says the registration data was unavailable, names what it tried, and scores nothing for the section — because expiry, transfer locks and suspension statuses are unknown there, not fine. If that section is blank on a domain you care about, check it by hand at your registrar rather than reading the silence as a pass.

# Is this TLD in the RDAP bootstrap at all?
curl -s https://data.iana.org/rdap/dns.json \
  | jq -r --arg tld de '.services[] | select(.[0][] == $tld) | .[1][0]'
# no output means: no RDAP service registered with IANA for that TLD

# Fall back to port 43, which for many ccTLDs is all there is
whois -h whois.denic.de example.de

IP and AS number RDAP at the RIRs

RDAP is not only for domains. The five Regional Internet Registries — AFRINIC, APNIC, ARIN, LACNIC and the RIPE NCC — run RDAP servers for the address space and AS numbers they administer, using the same query patterns and the same JSON shape.

This is often the more useful lookup of the two. Domain registration data tells you who paid for a name; an IP lookup tells you which organisation holds the address block a service actually runs on, and gives you an abuse contact for the network rather than for the registrar.

The response for an IP object carries startAddress and endAddress, the name and handle of the block, its type (allocation, assignment, reassignment), a cidr0 representation, and entities with roles including abuse and technical. An autnum object carries startAutnum and endAutnum, the AS name and the holder. Network objects also nest: querying a single address returns the most specific registration covering it, which for a customer reassignment is the customer, not the upstream provider.

The same bootstrap mechanism applies — ipv4.json, ipv6.json and asn.json at IANA — so you never need to know in advance which RIR holds a given address. Our own guide to autonomous systems and IP ownership covers what to do with the answer.

Finding who really operates a domain when the record says nothing

Registration data answers a narrow question. When it is redacted, or when you want the operational truth rather than the legal one, the useful evidence is in DNS and in TLS, and none of it requires privileged access.

• Nameservers. The NS records tell you who runs the DNS, which is frequently the hosting provider or the CDN and is rarely the registrant. A domain on a managed platform's nameservers is being operated by whoever runs that platform.

• MX records. Who handles the mail. This is often the clearest signal of what organisation is actually behind a domain, because mail is rarely outsourced to something unrelated to the operator.

• The A and AAAA records, then the network behind them. Resolve the host, then look the address up at the RIR to find the hosting provider or network operator, and their abuse contact. Behind a CDN this gives you the CDN rather than the origin, which is itself a fact worth having.

• Reverse DNS on the address. A PTR record frequently names the hosting provider explicitly, and where forward-confirmed reverse DNS is set up it ties the address to a hostname the operator chose.

• The TLS certificate. Its subject alternative names list every other hostname it covers, which often reveals sibling domains operated by the same party. Certificate Transparency logs go further: they are public, searchable, and show every certificate ever issued for a name, including subdomains that were never meant to be advertised.

• The site itself. A security.txt file at /.well-known/security.txt names a contact for security reports. A legal notice, imprint or terms page frequently names the operating company outright, and in several jurisdictions is legally required to.

• Historical registration data, with care. Records from before registrant redaction became the norm are still circulating. They may be accurate about who registered a name a decade ago and they are evidence about the past, not the present.

Put together, these will usually tell you which organisation operates a domain even when the registration record names nobody. What they will not tell you is who owns the organisation, and no lookup protocol was ever going to.

What commonly goes wrong

• Reading a redacted registrant as suspicious. It is the default state for an individual registrant under ICANN's Registration Data Policy. Drawing conclusions from it produces false accusations and nothing else.

• Believing a resale service that claims to have the real owner behind the redaction. What is generally on offer is a pre-2018 snapshot, sold as current. The legitimate routes are the abuse contact and, for gTLDs, ICANN's Registration Data Request Service.

• Assuming an empty result means an available domain. A lookup that failed, was rate-limited, or hit a TLD with no RDAP service looks identical to one that found nothing, unless the tool distinguishes them. Check availability at a registrar, not with a WHOIS query.

• Trusting an expiry date read from a cached or aggregated source. Registries can be slow to publish a renewal, and third-party databases are slower still. If you renewed recently, re-check the registry's own record in a few hours before acting.

• Leaving a domain with no transfer lock because ok sounds reassuring. The status ok means no restrictions are set, which includes no locks. It is the status a domain carries when it is easiest to take.

• Discovering redemption only when the site goes down. The domain usually stops resolving at the start of the redemption period, not at expiry, so by the time anyone notices the cheap window has already closed.

• Confusing the registrant with the operator. On a managed platform the registration may name a marketing agency, a former employee, or a privacy service, while the DNS, the mail and the site are run by someone else entirely. The DNS records are the better evidence of who is actually in charge.