WHOIS and RDAP: what a domain lookup really shows

The short version

Every website address (its domain name) is registered in public records, a bit like a property deed. A lookup lets you see when a domain was registered, who manages it, and sometimes who owns it. The old tool for this is called WHOIS; it's being replaced by a cleaner, modern version called RDAP. This guide shows you how to read what a lookup returns and what's normal to see.

What's actually happening

Think of a domain like a plot of land. Someone had to register it, through a company called a registrar (think GoDaddy, Namecheap, Cloudflare). The record of that registration is public, so anyone can ask "who holds this and when does it expire?"

For years the answer came from WHOIS, a plain-text service that often listed the owner's name, address, email, and phone. Two things changed that. Privacy laws and "privacy protection" services now hide most personal details behind the registrar. And the industry is moving to RDAP, a newer system that returns the same kind of information in a tidy, consistent, structured format, with better privacy controls built in.

Why it matters to you

• Checking a suspicious website: a domain registered three days ago is a classic scam warning sign.
• Buying or researching a domain: you can see if it's taken, when it expires, and who the registrar is.
• Understanding your own footprint: if you own a domain, a lookup shows what the world can see about it.

How to read a lookup

You don't need any software. Use the lookup tool on this site, or a trusted web tool, and type the domain (like example.com). Here are the lines worth understanding:

1. Registrar — the company that manages the registration (e.g., "NameCheap, Inc.").
2. Creation / Registered date — when the domain first came into existence. Very recent dates on a site asking for money or passwords are a red flag.
3. Expiration date — when the registration lapses unless renewed.
4. Updated date — the last time the record changed.
5. Name servers — the computers that direct traffic for the domain (often your host or Cloudflare). These hint at who hosts the site.
6. Registrant — the owner. Most of the time this now shows a privacy service ("Domains By Proxy," "Withheld for Privacy," "REDACTED FOR PRIVACY") rather than a person. That's normal and legal, not suspicious.
7. Status — codes like "clientTransferProhibited" simply mean the domain is locked against being moved, which is a good, normal protection.

How to check you're reading it right

Look up a well-known domain you recognize, like a bank or a big retailer. You should see a registrar you've heard of, a creation date many years ago, and name servers that make sense. If you then look up a brand-new domain and see a creation date within the last few days or weeks, that contrast is exactly the signal you're learning to spot.

What a normal result looks like

For a legitimate, established site, expect: a recognizable registrar, a creation date years in the past, a future expiration date, sensible name servers, a privacy-protected or business registrant, and "prohibited" status codes that just mean the domain is locked. Hidden personal details are the modern default and are nothing to worry about. The things that should make you pause are a very recent creation date, a registrar you can't identify paired with a site asking for sensitive information, or name servers that don't match what the site claims to be.

Want to go further?

The Advanced version covers the command-line tools (whois and the newer RDAP clients), the January 2025 WHOIS-to-RDAP transition, how to query RDAP directly over HTTPS and read its JSON, and the differences between gTLD, ccTLD, and IP-address lookups.

Summary

WHOIS and RDAP both answer "who holds this domain (or IP) and what's its registration state," but RDAP (Registration Data Access Protocol) is the structured, HTTPS/JSON, access-controlled successor to port-43 text WHOIS. As of the ICANN contract milestones, the obligation to run legacy WHOIS for gTLDs sunset on 28 January 2025, with RDAP as the standard going forward (RDDS itself continues). This guide covers reading both, via web, CLI, and direct RDAP queries.

What's actually happening

• WHOIS — an unstructured text protocol (TCP/43) plus web gateways. Output format varies per registry/registrar, is hard to parse reliably, has no standard authentication, and post-GDPR returns heavily redacted contact data for most gTLDs.
• RDAP — RESTful, returns JSON over HTTPS, supports standardized objects (domain, nameserver, entity, IP network, autnum), internationalization, redaction signaling, and differentiated access (anonymous vs. authenticated). Defined in RFCs 7480–7484 and 9082/9083/9224.
• Bootstrapping — IANA publishes RDAP bootstrap files mapping TLDs and IP ranges to authoritative RDAP base URLs, so a client knows which server to ask. ICANN runs a lookup portal at lookup.icann.org.
• Transition — ICANN's 2023 Global Amendment set an RDAP ramp-up (Aug 2023–Feb 2024) and a WHOIS sunset of 28 Jan 2025 for the obligation to operate legacy WHOIS; some registrars have their own later port-43 retirement dates. RDDS (the data service) persists; the access protocol shifts to RDAP.

Why it matters

For investigation (phishing triage, brand abuse, incident response), RDAP's structured output and consistent fields make automation reliable where WHOIS parsing was brittle. Registration age, registrar, nameserver delegation, and status codes are high-signal: a days-old domain, mismatched NS, or a registrar known for abuse tolerance all inform risk. Understanding redaction is key: absence of registrant PII is policy-driven, not evidence of wrongdoing.

How to query and read it, per method

Web

1. Use ICANN's lookup.icann.org (RDAP-backed) or a registry's RDAP/WHOIS page. Read creation/expiry/updated timestamps, registrar, statuses, and nameservers.

CLI: whois

1. whois example.com (Linux/macOS have it built in; on Windows use Sysinternals whois.exe or WSL). The client follows referrals from the thin registry to the registrar's WHOIS.
2. Expect variable formatting and redaction. Good for a quick look; poor for parsing.

CLI: RDAP

1. ICANN's rdap client, or OpenRDAP's rdap: rdap example.com resolves the bootstrap and returns structured data; add -j for raw JSON.
2. Or query directly with curl once you know the base URL from the IANA bootstrap: e.g. curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq . for .com.
3. For IPs/ASNs, use the RIR endpoints, e.g. curl -s https://rdap.arin.net/registry/ip/8.8.8.8 | jq . (ARIN; RIPE/APNIC/LACNIC/AFRINIC similarly).

Reading the JSON

• events — array with eventAction values like registration, expiration, last changed and their eventDate (ISO 8601).
• entities — roles (registrar, registrant, abuse) with vCard (jCard) contact blocks; redacted fields may be flagged in a top-level redacted array (RFC 9537).
• nameservers — delegated NS set.
• status — EPP status codes: client/serverTransferProhibited, clientHold, pendingDelete, etc.
• secureDNS — DNSSEC signing state (delegationSigned).

Edge cases

• ccTLDs (e.g., .uk, .de, .io) set their own policy; some expose little, some run RDAP, some only WHOIS, and formats differ.
• Thin vs. thick registries: .com/.net are thin (registry points to registrar for contact data), so you may need a second hop; many others are thick.
• Rate limits / access tiers: anonymous RDAP is throttled and redacted; authenticated access (for eligible parties) can return more.
• Privacy services: registrant shows a proxy/privacy provider; the registrar field and abuse contact remain useful for reporting.

How to verify your reading

Query a known-good domain and confirm fields line up with reality (established creation date, expected registrar, matching NS). Then compare a suspect domain: a very recent registration event, abuse-tolerant registrar, or NS that contradict the site's stated identity are the actionable signals. Cross-check the same domain via both whois and rdap to see redaction and formatting differences.

What a normal result looks like

A legitimate established domain shows a recognizable registrar, a multi-year-old registration event, a future expiration, coherent nameservers, EPP ...TransferProhibited locks, often DNSSEC enabled, and registrant contact either business-identifiable or redacted/privacy-proxied. Redaction is expected post-GDPR and is not a risk signal by itself. Treat recency, incoherent delegation, and registrar reputation, not the mere absence of PII, as your risk inputs.

Want to go further?

Pair domain lookups with the DNS-records guide (NS here points at the zone you'd then inspect with dig), and with reverse/IP RDAP at the RIRs to map hosting. For tooling, script against RDAP JSON rather than scraping WHOIS text, honor rate limits, and use the IANA bootstrap registry so your client always hits the authoritative server as the ecosystem finishes migrating off legacy WHOIS.