What the record actually is
A whois record is the registry's own statement about a registration. It answers a small set of questions, namely when this name was created, when it was last touched, when it expires, who sponsors it and where it is delegated, and it answers nothing else. That narrowness is the point. Within its scope a whois record is as authoritative as data on the web gets, because the party publishing it is the party that created the fact. Outside its scope it is silent, and the silence is routinely misread as absence.
The distinction matters because of what people try to use the record for. A whois record cannot tell you whether a site is any good, whether it has traffic, whether it has ever published anything, or whether the person named on it still exists. It is a ledger entry. Every one of the other layers of website data sits on top of it and is less certain than it is.
Every field in a whois record
Registries vary in what they emit, but the following set is close to universal across generic top-level domains. The dates are the fields worth learning first, because they are the only ones that let you reconstruct a history.
Standard fields
| Field | What it states | Public today |
|---|---|---|
| Domain Name | The registered name, normalised to lower case, with internationalised names shown in their punycode form.An internationalised name will appear as an xn-- string here even though it displays natively in a browser. | Yes |
| Registry Domain ID | The registry's own opaque handle for this registration.Stable for the life of one registration. A new handle means a new registration, not a transfer. | Yes |
| Creation Date | When the current registration was created.Not when the name first existed. A dropped and re-registered domain shows the new date and loses the old one entirely. | Yes |
| Updated Date | The last material modification to the record.Moves on transfer, on nameserver change, on status change and on renewal. This is the single most informative field. | Yes |
| Expiry Date | The end of the paid term.Not the date the name becomes available. Several weeks of grace and redemption follow it: see the domain lifecycle. | Yes |
| Registrar | The sponsoring registrar, with its IANA identifier.The IANA ID is the reliable part; trading names change without the ID changing. | Yes |
| Domain Status | One or more EPP status codes.Multiple codes are normal and they combine. See the status section below. | Yes |
| Name Server | The delegated nameservers, usually two to four.An empty list is a real and meaningful state, not a formatting error. | Yes |
| DNSSEC | Whether a signed delegation exists.Almost always unsigned. Says nothing about the site's security posture. | Yes |
| Registrant Name / Organization | The holder of the registration.Organisations are frequently still published. Natural persons almost never are. | Rarely |
| Registrant Address | Street, city, postcode, country.Country often survives redaction when everything above it does not. | Country only |
| Registrant Email / Phone | Contact routes for the holder.Usually replaced by a registrar-operated forwarding address or a web form. | Proxied |
Two of these fields do most of the work. Read the creation date and the updated date together and you can usually tell what happened to a name without any other source. Everything else in a whois record is either administrative or, increasingly, blank.
What the registrar controls and what the registry controls
A registration involves two parties, and confusing them makes several fields unreadable. The registry operates the top-level domain and holds the authoritative record. The registrar is the reseller the holder actually deals with, and it sponsors the registration on the holder's behalf. The registrar sets contact data, nameservers and renewal behaviour; the registry sets the dates, the identifier and the status codes that constrain what the registrar may do.
This is why a thin whois record from a registrar and a fuller one from a registry can both be correct at once. Registrar-served whois is a copy, sometimes formatted differently and sometimes a little stale. When the two disagree, the registry is right. The practical rule is to read the registry's own service, or to read RDAP, where the responsible party is unambiguous. It is also the distinction the generated lookup pages of the early 2010s lost, which is what the old domain profile pages held and why none of them has an answer left.
Status codes, and what they block
The status field is where the most useful operational information hides, and it is written in a vocabulary that explains nothing on sight. The codes are defined by EPP, the protocol registries and registrars speak to each other with, and they describe what is currently prohibited.
Common status codes
| Code | Meaning |
|---|---|
| ok | No restrictions. Perversely, this is the least common state on a well-managed name, because registrar locks are good practice. |
| clientTransferProhibited | The registrar has locked the name against transfer at the holder's request or by default. Routine and desirable. |
| clientHold | The registrar has asked the registry to stop publishing the delegation. The name resolves to nothing while this is set. |
| serverHold | The same, imposed by the registry rather than the registrar. Usually a dispute or an abuse finding. |
| pendingDelete | The redemption window has closed. The name will be released, typically five days later. |
| redemptionPeriod | The registration has been deleted but can still be restored by the previous holder, at a fee. |
| autoRenewPeriod | The term lapsed and the registry auto-renewed it provisionally. The registrar can still reverse this. |
A name showing clientHold is the clearest example of why the record and the site are
different questions. The registration is valid, paid and locked; the site is unreachable. Nothing
in the resolution layer can fix that, because the delegation is being withheld one level up.
Why most contact data is redacted
Until 2018 a whois record published the holder's name, postal address, telephone number and email by default, for anyone who asked, at any volume. The General Data Protection Regulation made that default unlawful for natural persons in Europe, and registries chose to apply the change globally rather than operate two regimes. The result is the modern record: the structure intact, the identifying lines replaced.
The redacted fields are worth understanding precisely, because "redacted" does not mean deleted. The data still exists at the registrar, is still disclosed to law enforcement and to substantiated legal requests, and is still visible to the holder. What changed is bulk public access. Organisations are treated differently from individuals: a company name in the registrant organisation field is not personal data, so it is frequently still published, which is why some records look surprisingly complete.
Two practical consequences follow. First, absence of a name is not evidence of concealment: it is the default. Second, the redacted fields are not where investigation happens any more; the dates, the status codes and the nameservers are, because those were never personal data and were never removed.
Reading a record in practice
The fastest way to read an unfamiliar registration is to work down the dates, then the status, then the delegation, and to ignore the contact block entirely. A creation date long in the past with a very recent updated date says the name is established and something just happened to it. A creation date within the last month on a name with a decade of history in third-party sources says the previous registration lapsed. An empty nameserver list says the name is registered and resolves to nothing, which is a state most availability checkers report identically to "unregistered".
If you have a record in front of you and want the fields named for you, the record field decoder parses both whois text and an RDAP response in the browser and labels every line. For what happens after the expiry date, the domain lifecycle page walks the five windows in order.
