BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
WHOIS: The Protocol and How to Read the Data on Any Domain
WHOIS is the query-and-response protocol that answers one question about any domain: who registered it, when, through which registrar, and under what status. The protocol is old and simple. Reading the record it returns is where the real skill sits.
This guide does both halves on one page. It explains how the WHOIS protocol works on the wire, then walks the record field by field, so a creation date, a status code, or a blank registrant field each tells you something specific instead of nothing.
It also reads that data through a lens the registrar guides skip: registration data is the diligence layer for buying an aged or expired domain. The same fields that identify an owner also reveal a domain’s age, its transfer-readiness, and its history. SEO Domains screens that data across its curated catalogue before a domain is listed, so the record is read once, properly, before money moves.
What is the WHOIS protocol, and what does reading the data mean?
WHOIS is a query-and-response protocol that returns the registration record for a domain name, IP address block, or autonomous system. Reading the data means interpreting that record: the registrar, the key dates, the nameservers, the status codes, and the registrant fields, each of which carries a specific meaning beyond the raw text.
The word WHOIS names two things that get blurred together. One is the protocol, the wire format that fetches the record. The other is the record itself, the block of fields a lookup returns. A page that explains only the first leaves the reader unable to interpret what comes back. A page that explains only the second leaves them unsure where the data lives or why it sometimes refuses to answer. This guide keeps both in view.
The two halves of WHOIS
The protocol half is mechanical and unglamorous. A client opens a connection, sends a domain name as plain text, and reads back a plain-text response. The reading half is interpretive. The same response that looks like a wall of text to one person is, to a trained eye, a clear statement of when a domain was created, whether it is locked, who runs its nameservers, and whether its registrant data is public or redacted.
For anyone evaluating a domain instead of merely owning one, the reading half is the work. A domain’s creation date is an age signal. Its status codes reveal whether it can be transferred today. Its registration history hints at prior use. None of that is visible until the record is read deliberately, which is the skill this page builds.
The protocol (the wire format)
How the record is fetched: a TCP connection on port 43, a plain-text query, a plain-text answer drawn from registry and registrar databases. Defined in RFC 3912 and now succeeded by RDAP.
The record (the data you read)
What the lookup returns: registrar, creation and expiry dates, nameservers, domain status codes, and registrant or admin or technical contact blocks. Reading it correctly is the diligence skill.
How the WHOIS protocol actually works
WHOIS operates over TCP on port 43. A client sends a plain-text query naming the resource, and the server returns a plain-text record. The data is not held in one central database. It is distributed across registry and registrar servers, and the model splits into thick registries, which store the full record, and thin registries, which point to the registrar that holds it.
Port 43, plain text, and RFC 3912
The protocol is deliberately minimal. The current specification, RFC 3912, published in 2004, defines WHOIS as a TCP-based transaction on port 43: the client connects, transmits the query text terminated by a carriage return and line feed, and the server replies with the record, then closes the connection. There is no encryption, no authentication, and no fixed response format in the original protocol. That simplicity is why WHOIS lasted for decades and also why it eventually needed a successor.
WHOIS predates the modern web. The first directory was built by Elizabeth Feinler and her team for ARPANET in the early 1970s, and the NICNAME/WHOIS protocol was documented in RFC 812 in 1982. The lineage matters because it explains the format: a 1980s plain-text protocol was never designed for the structured, privacy-aware data access that registration records now demand.
There is no single WHOIS database
A common misconception is that ICANN or a central body keeps one master WHOIS file. It does not. The data is distributed. Each registry, the organisation that runs a top-level domain such as Verisign for .com and .net or PIR for .org, maintains the authoritative records for its own TLD, and the registrars who sell domains hold registrant data too. A lookup is routed to whichever server is authoritative for the domain in question.
This distribution is why responses look different from one TLD to the next. A .com record and a .io record are returned by different servers run by different operators, with different field labels and formatting. Reading WHOIS well means recognising the same underlying fields even when their labels and order shift.
Thick versus thin registries
The distributed model has two shapes. A thick registry stores the complete registration record, including registrant contact data, at the registry level. A thin registry stores only the bare minimum plus a pointer to the registrar that holds the full record, so a complete lookup takes two hops: query the registry to find the registrar, then query the registrar for the details. The .com and .net registries are the classic thin model; .org is thick.
| Aspect | Thick registry | Thin registry |
|---|---|---|
| Where the full record lives | At the registry | At the registrar |
| Lookups needed | One query to the registry | Two: registry points to the registrar, then query the registrar |
| Example TLDs | .org and many newer gTLDs | .com and .net |
| What you read first | Full contact and status data | Registrar name and the referral server, then the details |
The anatomy of a WHOIS record: every field, and how to read it
A WHOIS record groups into four blocks: identity, dates, infrastructure, and status. Reading it means knowing that the registrar is the seller and not the owner, that the creation date is an age signal, that the nameservers reveal where a domain is hosted, and that a blank registrant field is redaction by policy, not an absent owner.
The four blocks of a record
Every record, whatever its formatting, carries the same logical groups. The identity block names the registrar and, where public, the registrant, administrative, and technical contacts. The date block carries creation, expiry, and last-updated timestamps. The infrastructure block lists the nameservers and sometimes the DNSSEC state. The status block holds the EPP status codes covered in the next section. Read the blocks in that order and the record stops being a wall of text.
The registrar is not the owner
The single commonest misread is treating the registrar as the owner. The registrar is the accredited company that sold and manages the domain, a Namecheap or a GoDaddy, and it can manage millions of domains it does not own. The registrant is the person or organisation that controls the domain. When privacy is enabled, the registrant block shows the privacy service in place of the registrar, which is a third distinct party again. Keeping registrar, registrant, and privacy provider separate is the foundation of reading a record correctly.
Dates are signals, not decoration
The date fields carry more diligence value than any other part of the record. The creation date is when the domain was first registered, and it is the closest single proxy for domain age, the trait that distinguishes an aged domain from a freshly registered one. The expiry date is the renewal deadline and a clue to how long the current owner has committed. The last-updated date flags recent changes, which can indicate a recent transfer, a nameserver change, or a status update worth investigating.
| Field | What it shows | How to read it for diligence |
|---|---|---|
| Registrar | The accredited company managing the domain | The seller, not the owner. Note it, then look past it to the registrant. |
| Registrant | The controlling person or organisation | The real owner. Often redacted on gTLDs since 2018, which is normal, not a red flag. |
| Creation date | When the domain was first registered | The primary age signal. Older creation dates indicate an aged domain. |
| Expiry date | The renewal deadline | How long the current registration runs. A near date can mean an imminent drop. |
| Updated date | When the record last changed | A recent change can flag a transfer, a nameserver swap, or a status update. |
| Name servers | The authoritative DNS servers | Where the domain resolves. Default registrar nameservers often mean a parked or unused domain. |
| Domain status | EPP status codes | Whether the domain is locked, transferable, or on hold. Read in the next section. |
| DNSSEC | Signed or unsigned state | Whether DNS responses are cryptographically signed. Often unsigned on small domains. |
The nameserver line deserves a second look. Nameservers pointing at a registrar default, such as a parking nameserver, are a strong sign the domain is registered but unused, which is common with aged and expired names. The deeper mechanics of nameservers and how to change them on a domain you acquire are covered in the DNS & Nameservers hub. When the goal is to source a domain whose record already reads clean, screened aged and expired domains on the SEO Domains marketplace have their registration data checked before they are listed, so the creation date, status, and history are verified, not assumed.
Domain status codes: how to read them and why they matter
Domain status codes are EPP status codes, standardised states that tell you what can and cannot be done with a domain right now. They split into client codes set by the registrar and server codes set by the registry, where server codes take precedence. Reading them tells you whether a domain is locked against transfer, frozen against updates, or removed from the zone entirely.
Client codes versus server codes
Every status code is prefixed client or server, and the prefix tells you who set it. Client codes, such as clientTransferProhibited, are applied by the registrar and can be lifted by the registrar at the owner’s request. Server codes, such as serverHold, are applied by the registry and take precedence over client codes, so they cannot be cleared at the registrar level. When reading a record, a server code is the heavier signal because it sits above the registrar.
The codes that matter most when reading a record
A handful of codes carry the bulk of the diligence weight. The transfer and update locks tell you whether a domain is ready to change hands. The hold codes tell you whether it is even resolving. The pending-delete and redemption codes tell you a domain is on its way out of registration, which is exactly the window an expired-domain buyer watches.
| Status code | Set by | What it means when you read it |
|---|---|---|
| clientTransferProhibited | Registrar | Registrar lock against transfer, a standard anti-hijack default. The owner can lift it to sell or move the domain. |
| clientUpdateProhibited | Registrar | Updates such as nameserver changes are blocked. Often paired with the transfer lock. |
| clientHold | Registrar | The domain is pulled from the zone, so its sites and email stop working. Often set on expiry or failed verification. |
| serverHold | Registry | A registry-level hold, heavier than clientHold and not clearable at the registrar. A strong warning sign. |
| pendingDelete | Registry | The domain is queued for deletion and will soon drop. The window expired-domain buyers track. |
| redemptionPeriod | Registry | The domain expired and is in a grace window where only the prior owner can restore it. |
| ok (or active) | Registry | No restrictions applied. Read alongside the rest of the record rather than as an all-clear on its own. |
The pendingDelete and redemptionPeriod codes connect WHOIS directly to the expired-domain lifecycle. A domain showing redemptionPeriod has lapsed but is not yet available, while pendingDelete signals an imminent drop. The full sequence from expiry to availability is documented in the Expired Domain Fundamentals hub.
WHOIS privacy, redaction, and GDPR: why fields are blank
Blank or generic registrant fields are usually redaction, not an absent owner. Two forces drive it: optional WHOIS privacy services that registrars sell, and mandatory GDPR redaction that took effect in 2018 for registrants covered by the regulation. Reading a redacted record correctly means treating the missing contact data as withheld by policy, not as a sign of something wrong.
Privacy services versus GDPR redaction
There are two distinct reasons a registrant block is hidden, and reading them apart matters. A WHOIS privacy or proxy service is an optional, usually paid product where the registrar substitutes its own proxy contact details for the registrant’s, by the owner’s choice. GDPR redaction is mandatory: since the EU General Data Protection Regulation took effect on 25 May 2018, registrars and registries have redacted personal contact data for covered registrants by default, whether or not the owner bought a privacy product. The structural fields, registrar, nameservers, status, and dates, stay public in both cases.
The practical reading rule is simple. A redacted registrant on a modern gTLD is the norm, not a warning sign. The fields that still tell you what you need, the dates, the status codes, and the nameservers, are exactly the ones that remain visible. The mechanics of optional privacy products are covered in WHOIS privacy and proxy services, and the regulatory side in GDPR impact on WHOIS.
What you can still read when contact data is hidden
Redaction removes the human contact details, not the domain intelligence. A redacted record still tells you the registrar, the creation and expiry dates, the nameservers, the status codes, and usually the registrant country and organisation type. For diligence on a domain you are evaluating, that is the bulk of what matters. The owner’s name and email are rarely the deciding factor; the age, the lock state, and the history are. Where the owner’s identity genuinely matters, historical WHOIS records captured before redaction can still surface it, a technique covered in WHOIS history services compared.
RDAP, the successor: how the same data reads after January 2025
RDAP, the Registration Data Access Protocol, replaced WHOIS as the definitive source for gTLD registration data on 28 January 2025. It returns the same underlying data as structured JSON over HTTPS instead of plain text over port 43, with standardised fields, encryption, and support for differentiated access. Reading RDAP means mapping the familiar WHOIS fields onto their JSON equivalents.
Why RDAP exists and what changed
RDAP solves the structural flaws of a 1980s protocol. Where WHOIS returns unencrypted, unstructured plain text whose format varies by registry, RDAP is a RESTful service over HTTPS, defined across RFCs 7480 to 7484 in March 2015, with its JSON response format in RFC 9083. The data is the same registration record. The delivery is encrypted, machine-readable, and consistent across operators. ICANN designated 28 January 2025 as the date RDAP becomes the definitive source for gTLD registration data, after which ICANN no longer requires gTLD registries and registrars to maintain a WHOIS service on port 43.
The transition is well underway, not theoretical. Reporting on ICANN’s figures put gTLD query volumes at roughly 122 billion WHOIS lookups per month against 7 billion RDAP in January 2025, with the two crossing over around June 2025 as RDAP overtook WHOIS. Anyone reading registration data in 2026 can treat RDAP as the primary source, with WHOIS as a fading fallback.
Differentiated access: the feature WHOIS never had
The capability that defines RDAP for the privacy era is differentiated access. RDAP supports tiered access control, so the data a viewer sees can depend on who they are. An anonymous member of the public, an accredited body, or a legal authority can be served different levels of detail from the same record, which lets operators comply with privacy rules while still providing fuller data to authorised requesters. WHOIS, with no authentication, was limited to showing everyone the same redacted view.
| What you are reading | WHOIS plain text | RDAP JSON |
|---|---|---|
| Transport | TCP port 43, unencrypted | HTTPS on port 443, encrypted |
| Format | Unstructured plain text, varies by registry | Structured JSON, standardised by RFC 9083 |
| Creation date | A Creation Date label line | An events array entry with eventAction registration |
| Status codes | Domain Status label lines | A status array of the same EPP code strings |
| Nameservers | Name Server label lines | A nameservers array of objects |
| Access model | One redacted view for everyone | Differentiated access by requester type |
How to run and read a lookup end to end
Running and reading a registration lookup is a six-step procedure: pick a tool, query the domain, identify the protocol you received, read the four record blocks in order, interpret the status codes, and cross-check anything that matters against history. Each step has a reading move and a common misread to avoid.
The procedure below works whether the answer comes back as WHOIS plain text or RDAP JSON, because the underlying fields are the same. The point is to read deliberately, block by block, instead of scanning for a single line and stopping.
-
Pick a lookup tool
Use the ICANN Lookup tool, a registrar lookup page, an RDAP client, or the command-line whois utility on macOS and Linux. ICANN Lookup now queries RDAP by default for gTLDs, which is the current authoritative source.
The misread: trusting a single third-party tool that caches stale data. For anything that matters, confirm against an authoritative registry or registrar source.
-
Query the domain
Enter the bare domain without the protocol or path, for example example.com and not https://example.com/page. On a thin TLD such as .com, expect a first response that names the registrar and refers you onward.
The misread: querying a subdomain or a full URL. Registration data exists for the registered domain, not for a subdomain or a specific page.
-
Identify which protocol answered
Note whether you received WHOIS plain text or RDAP JSON. In 2026 a gTLD lookup usually returns RDAP. The fields are the same, but JSON groups them into arrays, so know which view you are reading.
The misread: assuming a blank-looking WHOIS field means no data. The same fact can be present in the RDAP response under a structured key.
-
Read the four blocks in order
Work through identity, dates, infrastructure, and status, as set out in the record-anatomy section. Separate the registrar from the registrant from any privacy provider, then read the creation date as the age signal and the nameservers as the hosting clue.
The misread: reading the registrar as the owner. The registrar is the seller; the registrant is the controller, and a privacy service is a third party again.
-
Interpret the status codes
Map each status code to its meaning using the EPP table above. Distinguish client codes the owner can lift from server codes they cannot, and flag any hold, redemption, or pendingDelete state as a lifecycle signal.
The misread: treating clientTransferProhibited as a problem. It is a standard registrar lock, not a defect, and the owner can release it to transfer the domain.
-
Cross-check against history
For a domain you are evaluating, confirm what the live record implies against historical registration data. A recent updated date or a redacted owner is worth checking against prior records to confirm the domain’s real history and prior use.
The misread: trusting a clean live record alone. A domain can read fine today yet carry a problematic history that only a historical lookup reveals.
Common WHOIS misreads: the reading checklist
The mistakes that produce a wrong conclusion from a registration record are a short, repeatable list. Each one comes from reading a single field out of context. The fix in every case is the same: read the record as a whole, block by block, and confirm anything load-bearing against history.
| The misread | Why it happens | The correct reading |
|---|---|---|
| Registrar read as owner | The registrar name is prominent at the top of the record | The registrar is the seller; the registrant is the owner. Keep them separate. |
| Redaction read as suspicious | A blank registrant looks like missing or hidden data | GDPR redaction since 2018 is the default on gTLDs, not a red flag. |
| Creation date confused with transfer date | A recent updated date is mistaken for a new registration | Creation date is true age; updated date flags a recent change such as a transfer. |
| clientTransferProhibited read as a defect | The word prohibited sounds like a problem | It is a standard anti-hijack lock the owner can lift to transfer. |
| Parking nameservers read as active hosting | Any nameserver line looks like a working site | Default registrar nameservers often mean a parked, unused domain. |
| Clean live record read as clean history | The current record shows no issues today | Confirm prior use with historical WHOIS; today’s record hides the past. |
| WHOIS blank read as no RDAP data | A legacy WHOIS view is empty after the 2025 sunset | Query RDAP, where the same field may be present and structured. |
WHOIS and RDAP frequently asked questions
The five questions people raise when they search for how the WHOIS protocol works and how to read the data, answered against the protocol record and the current RDAP transition.
Q1What protocol does WHOIS use, and on what port?
WHOIS is a query-and-response protocol that runs over TCP on port 43, defined in RFC 3912. A client sends a plain-text query naming the domain, and the server returns a plain-text record. There is no encryption or authentication in the original protocol, which is one reason RDAP, running over HTTPS, has replaced it for gTLDs.
Q2Is WHOIS still used in 2026?
It is fading, not gone. ICANN made RDAP the definitive source for gTLD registration data on 28 January 2025 and no longer requires registries to run WHOIS on port 43. Reporting on ICANN figures showed RDAP query volume overtaking WHOIS around June 2025. WHOIS still answers in places, but RDAP is now the primary source to read.
Q3Why is the registrant blank when I read a record?
A blank registrant is almost always redaction, not an absent owner. Since the GDPR took effect on 25 May 2018, personal contact data for covered registrants is redacted by default on gTLDs, separate from any optional privacy product the owner chose to buy. The structural fields, registrar, dates, status, and nameservers, stay public, and those are the fields that carry the diligence value.
Q4What does clientTransferProhibited mean when I see it?
It is a registrar lock that prevents the domain from being transferred to another registrar, a standard anti-hijack default that registrars apply at registration. It is not a defect. The owner can lift it to sell or move the domain. A server-prefixed code such as serverHold is the heavier signal, because the registry sets it and the registrar cannot clear it.
Q5How do I read a domain’s age from a WHOIS record?
Read the creation date, the date the domain was first registered, which is the closest single proxy for domain age. Be careful to use creation date and not the updated date, which only flags a recent change. For acquisition diligence, confirm the creation date against historical registration records, since a domain’s true age and prior use are what give an aged domain its value.
Reading registration data as domain diligence
For anyone evaluating a domain to acquire, WHOIS and RDAP are the diligence layer. The same record that identifies an owner reveals a domain’s age through its creation date, its transfer-readiness through its status codes, and its prior use through its history. Reading those fields correctly is the difference between buying a vetted asset and inheriting a problem. SEO Domains screens that data before a domain is listed.
The three fields that decide a domain acquisition
Strip the record down to what matters for a purchase and three readings dominate. The creation date establishes age, the trait that separates a genuinely aged domain from a recently registered one. The status codes establish whether the domain can change hands today or is locked, on hold, or mid-lifecycle. The history, read through prior registration records, establishes whether the domain was used cleanly or carries baggage a clean live record hides.
Reads as a vetted asset
A genuine creation date establishing real age, a transferable status with only standard registrar locks, real nameserver history, and a clean prior-use record confirmed against history.
Reads as a risk
A recent creation date dressed up as aged, a serverHold or pending-delete state, default parking nameservers with no history, and a prior use the live record quietly omits.
Why screened registration data is the starting point
Reading a record well is a learnable skill, but at scale it is a process. The diligence that reads age, status, and history on one domain has to run on every domain before it is worth a buyer’s time. That is the work SEO Domains does up front: aged and expired domains in the curated catalogue have their registration data, creation date, status, and history read and screened before they are listed and priced, so the buyer starts from a verified record instead of a raw lookup.
