Back to blogGuides

WHOIS vs RDAP: What Domain Registration Data Shows Today

What a WHOIS lookup still shows, why registrant details are redacted, how RDAP replaces WHOIS, and how to read domain status codes and expiry dates.

Published: · 7 min read

If you last ran a WHOIS lookup ten years ago, you remember a wall of text with a name, a street address, a phone number and an email. Run one today and most of that is gone. The record is shorter, half of it says "REDACTED", and the tool you used may not even be speaking the WHOIS protocol any more.

This guide explains what changed, what registration data still tells you, and how to read the parts that matter: status codes and dates.

What a WHOIS record still shows

Public registration data for a typical generic top-level domain (.com, .net, .org, .app and so on) reliably contains:

  • the registrar that sponsors the domain, with its IANA ID
  • the creation, last updated and expiry dates
  • one or more status codes
  • the nameservers the domain is delegated to
  • whether the domain is signed with DNSSEC
  • the registrar's abuse contact

That is enough to answer most operational questions. Is this domain about to expire? Which company do I call to fix it? Did the nameservers change last week? Is a transfer lock in place?

What it usually does not contain is the identity of the registrant.

Why registrant details are redacted

Until May 2018, ICANN contracts required registrars to publish full contact details for every gTLD registrant. When the EU's General Data Protection Regulation took effect, publishing personal data of that kind to anyone who asked no longer had a defensible legal basis. ICANN responded with a Temporary Specification that allowed registries and registrars to withhold personal fields from public output. The permanent Registration Data Policy that followed keeps the same principle.

A few practical consequences:

  • Redaction is often global. Many registrars apply it to every customer, because sorting registrants by which privacy law covers them is error-prone.
  • Organisations may still appear. A legal entity can choose to have its organisation name published. Some do.
  • Privacy and proxy services are a separate layer. These replace the registrant's details with the service's own. They existed long before 2018 and are still common.
  • There is a path for legitimate requests. Registrars must offer a way to contact the registrant without revealing the address, usually a web form or a relay email, and must consider disclosure requests from parties such as law enforcement or trademark holders.

No lookup tool can work around redaction, because the data is removed at the source. A site that claims to show the "real owner" of a redacted domain is either showing old scraped data or guessing.

What is wrong with the WHOIS protocol

WHOIS dates from the early 1980s. A client opens a TCP connection to port 43, sends a domain name followed by a line break, and receives free text. That is the whole protocol. The consequences:

  • No standard format. Every registry invents its own field names and layout. Parsers break constantly.
  • No standard errors. "Not found", "rate limited" and "server broken" are all just text.
  • No internationalisation. There is no defined character encoding.
  • No encryption or authentication. Everything travels in clear text, and there is no way to give different users different levels of access.
  • No discovery. Clients need a hand-maintained list of which server answers for which TLD.

RDAP: the replacement

The Registration Data Access Protocol was standardised by the IETF in 2015 to fix exactly these problems. It is an HTTPS API that returns JSON:

  • Defined structure. Dates are events with an action such as registration or expiration. Contacts are entities with roles such as registrar or abuse. Status values come from a fixed list.
  • Real error handling. A domain that does not exist returns HTTP 404. Rate limiting returns 429.
  • Bootstrap discovery. IANA publishes a machine-readable file that maps each TLD to its RDAP base URL, so clients always know where to ask.
  • Referrals. A registry response can link to the registrar's RDAP server, which may hold more detail.
  • Room for tiered access. Because it runs over HTTPS, a server can authenticate a requester and return more fields to those who are entitled to them.

You can try it with nothing but curl. The shape of a response, trimmed down, looks like this:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2015-03-02T10:15:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-03-02T10:15:00Z" }
  ],
  "nameservers": [
    { "ldhName": "ns1.example.net" },
    { "ldhName": "ns2.example.net" }
  ],
  "secureDNS": { "delegationSigned": false }
}

ICANN has required gTLD registries and registrars to operate RDAP since August 2019. In January 2025 the contractual requirement to keep running port 43 WHOIS for gTLDs ended, which makes RDAP the authoritative source. People still say "WHOIS lookup", and that is fine as a name for the task, but the data increasingly arrives over RDAP.

Country-code TLDs are a different story. They set their own policies. Many run RDAP, some still run only WHOIS or a web form, and a few publish very little at all.

How to read status codes

Status codes come from EPP, the protocol between registrars and registries. RDAP writes them with spaces ("client transfer prohibited"); WHOIS output uses camelCase. The prefix tells you who set the code: client means the registrar, server means the registry.

Everyday codes

  • ok / active: No restrictions. Nothing is locked.
  • clientTransferProhibited: Registrar transfer lock. Normal and desirable on domains you own.
  • clientUpdateProhibited, clientDeleteProhibited: Registrar locks against changes or deletion. Common on high-value names.
  • serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited: Registry-level locks. Seen with registry lock products and during disputes.

Codes that mean the domain does not resolve

  • clientHold: The registrar has removed the domain from the zone. Typical causes: unpaid renewal, unverified contact email, abuse handling.
  • serverHold: The registry has done the same. Usually a legal or policy matter.
  • inactive: No nameservers are set, so there is nothing to publish.

Lifecycle codes

  • addPeriod: Just registered. The registrar can still delete it for a refund, usually within five days.
  • autoRenewPeriod: The registry renewed the domain automatically at expiry. The registrar can still reverse this, typically for up to 45 days.
  • transferPeriod, renewPeriod: Short grace periods after a transfer or an explicit renewal.
  • pendingTransfer: A transfer to another registrar is in progress.
  • redemptionPeriod: The domain was deleted. The previous registrant can restore it, usually within 30 days and for a considerable fee.
  • pendingDelete: Restoration is no longer possible. After about five days the name is released.

The exact lengths vary by TLD and registrar, and ccTLDs often have completely different lifecycles. Treat the numbers above as the common gTLD pattern, not as a promise.

Expiry dates: registry versus registrar

This is the part that catches people out.

When a gTLD domain reaches its expiry date, most registries do not delete it. They auto-renew it for one year, charge the registrar, and place it in autoRenewPeriod. If the customer never pays, the registrar deletes the domain within the grace period and gets the fee back.

During that window the public record can show an expiry date a year in the future for a domain whose owner has not paid and whose website is already replaced by a parking page. The date is accurate as far as the registry is concerned. It is simply not the date that governs your relationship with your registrar.

Some records expose both values:

Registry Expiry Date: 2027-03-02T10:15:00Z
Registrar Registration Expiration Date: 2026-03-02T10:15:00Z

When they differ, the registrar's date is the one that decides whether your service stays up. Practical rules:

  1. Renew important domains well before the expiry date, not during grace periods.
  2. Read the dates together with the status codes. A far-off expiry plus autoRenewPeriod means "not yet paid for", not "safe".
  3. If you are hoping to register a name that is expiring, understand that the current registrant can normally recover it right up to the end of redemptionPeriod.

Domain age

The creation date is often used as a rough signal of how established a domain is. Keep one caveat in mind: if a name was deleted and registered again, the creation date resets. It tells you when the current registration began, not when the name was first used.

Check it with OrbitProbe

The OrbitProbe WHOIS lookup queries RDAP directly and shows the registrar, dates, status codes, nameservers and DNSSEC state, with the source server and lookup time. Redacted fields are shown as redacted. If you manage several domains, the portfolio in the workspace keeps their expiry dates in one list and sends renewal reminders.