WHOIS Lookup

What a WHOIS lookup actually asks

WHOIS is the oldest service still in everyday use on the internet, and it is far simpler than its output suggests. A client opens a TCP connection to port 43 on a registry’s server, writes a domain name followed by a carriage return, and reads plain text until the server hangs up. That is the entire protocol, specified in RFC 3912 in a document shorter than this page.

What it is not is a lookup in the DNS. The DNS answers “where does this name point right now”; WHOIS answers “who registered this name, when, through whom, and until when”. The two are maintained by different parties for different purposes and can legitimately disagree — a domain can have perfect DNS and an expiry date next week.

There is no central WHOIS database, either. Every top-level domain runs its own, so the first job of any lookup is deciding which server to ask. This tool keeps a fixed list for the common top-level domains and asks IANA for anything else, because IANA maintains the authoritative record of who runs each TLD.

Why no two answers look alike

RFC 3912 defines how to ask. It says nothing whatsoever about the answer — not the field names, not the order, not the date format, not even the character encoding. Every registry therefore invented its own layout, and the differences are not cosmetic:

• Creation Date, Registered on, created, [Created on] and Domain Registration Date are all the same field at different registries.
• Dates arrive as 1997-09-15T04:00:00Z, 01-Jan-2000, 2000/01/01 and half a dozen other shapes, some without a timezone at all.
• Some registries put the label on one line and the value on the next; some wrap labels in square brackets; some publish nothing but a status word.

This page normalises what it confidently can and leaves the rest alone. Where a field could not be found it says Not published rather than guessing, and where a date could not be parsed into a real date it is left empty rather than echoed back as if it were one. The count of fields published is shown next to the record for the same reason: a thin record and a thin domain are completely different things, and only the registry knows which you are looking at. The full response is always included underneath, because registries put genuinely useful detail in free text that no parser should pretend to understand.

Two records for one domain

Most generic top-level domains keep the registration in two places. The registry holds the authoritative facts about the domain — when it was created, when it expires, which nameservers are delegated, which locks apply. The registrar holds the customer relationship, and historically carried the contact details.

That is why a .com answer usually contains a line like Registrar WHOIS Server: whois.example-registrar.com. It is a pointer to the second, fuller record. This tool follows that referral once and merges the two, preferring the registrar’s values where both publish a field, and lists every server it contacted so the result can be reproduced. Where the two disagree about the expiry date, the registry is the one that counts — it is the database the deletion process actually runs from.

Why the owner’s details are redacted

Until 2018, a WHOIS record typically contained the registrant’s name, postal address, email address and telephone number, published to anybody who asked, with no rate limit worth mentioning and no way to opt out. The GDPR made that untenable, and ICANN’s Temporary Specification required contracted parties to remove personal data from public output. Redaction is now the default across gTLDs, and many country-code registries had reached the same conclusion years earlier.

What you see instead depends on the registry:

• REDACTED FOR PRIVACY, or similar wording, where a field has been withheld. The data still exists at the registrar.
• A privacy or proxy service — the domain is genuinely registered to that service, which forwards contact attempts to the real owner.
• An organisation name, but no individual. Company details are not personal data, so many registries still publish them. That is why this page has a registrant organisation field and no registrant name field.
• An anonymised forwarding address or a web form link, in place of a real email address.

Redaction is not the same as anonymity. The information is disclosed to law enforcement, to trademark holders through defined processes, and increasingly through RDAP’s authenticated access. If you need to reach a domain owner, the registrar’s abuse contact — which is still published, because ICANN requires it — is the route that works.

Reading the dates

Three dates matter, and only one of them is urgent. The creation date is the beginning of the current unbroken registration; it resets if a domain is ever allowed to lapse and is re-registered, which is why an old brand can show a surprisingly recent date. The updated date records the last change to the registration itself — a nameserver change, a transfer, a renewal — and not a change to the website. The expiry date is the one to act on.

Expiry does not mean the name becomes available the next morning. It enters a sequence that takes months, and the earlier stages are recoverable:

The practical advice is the same as for TLS certificates: automate it and monitor the result rather than the calendar. Turn on auto-renew, keep the card on file valid, and make sure the renewal notices go to an address that is not hosted on the domain being renewed — an outage that starts by silencing its own warning emails is a bad outage.

Domain status codes

The status field carries EPP status codes, and it is the most useful part of a WHOIS record once you can read it. Codes beginning client were set by the registrar, usually at the owner’s request; codes beginning server were set by the registry and cannot be changed from the registrar’s control panel.

Seeing several Prohibited codes at once is normal and healthy: they are locks protecting the domain from unauthorised transfer or deletion, not warnings. The two to worry about are clientHold and serverHold, which mean the domain has been pulled out of the zone entirely and no DNS lookup for it will succeed.

WHOIS and DNS answer different questions

The nameservers in a WHOIS record are the delegation the registry holds — the answer the TLD’s nameservers give when asked where your zone lives. They are not read from your zone, and they are not what a resolver has cached. A nameserver change is visible here as soon as the registry processes it, while resolvers around the world can carry on using the old delegation until the cached records expire.

So if a change has not taken effect, compare the two directly: this page shows what the registry has recorded, the DNS Checker shows what is being answered now, and DNS Propagation shows whether resolvers in different places agree yet. The same distinction applies to DNSSEC — a WHOIS record reports whether a signed delegation exists at the registry, not whether your zone’s signatures currently validate.

WHOIS, RDAP, and what comes next

RDAP — the Registration Data Access Protocol — is WHOIS rebuilt for the modern internet: the same registration data served over HTTPS as structured JSON, with a real specification for field names, proper support for non-Latin scripts, and a defined way to authenticate a request for the parts that are no longer published to everyone. Every gTLD registry and registrar has been required to run it since 2019.

Port 43 has not gone away. ICANN has published a timetable for retiring the legacy service for gTLDs, but plenty of country-code registries offer nothing else, and WHOIS remains the fastest way to get an answer from a terminal. This tool speaks WHOIS for exactly that reason: it is what the widest set of registries actually answers.

How IPGet keeps this lookup safe

A feature that makes a server open a connection to somewhere named by a stranger is a server-side request forgery primitive, and WHOIS has a sharper edge than most: the second server it connects to is chosen by the first server’s reply, not by us and not by you. A hostile or compromised registry record could otherwise say Registrar WHOIS Server: 127.0.0.1 and be pointing our own server at itself.

This lookup therefore treats every destination as untrusted, on every hop:

• You supply one thing — a domain name. You cannot choose the server, the port, the protocol or the payload.
• A server named by a response must be a bare host name. A value carrying a scheme, a port, a path or any other character is refused rather than repaired, because a referral that needs cleaning up is not one we should follow.
• Every server name — the first included — is resolved here and every address it returns is checked. If any one of them is private, loopback, link-local, carrier-NAT or reserved, the whole destination is refused, so a zone mixing a public and a private record cannot be used to reach the private one.
• The connection is made to the checked address, never to the name. Resolving the name a second time at connect would let whoever controls that zone answer with a public address for the check and 127.0.0.1 a moment later. That is DNS rebinding, and pinning the validated address is the defence.
• The port is 43 only, as a fixed constant that no response can influence. The referral chain is capped and every server already visited is remembered, so two servers cannot bounce the request between them.
• The only bytes written are the domain name itself. The reply is read up to a size limit and the socket is destroyed on every path — success, failure, timeout and size limit alike.
• The registrar’s website is shown as text and never as a link: a remote response does not get to choose where your click goes.
• Requests are rate limited more tightly than anywhere else on the site, because registries block abusive sources outright. Successful answers are cached briefly; failures never are. Looked-up domains are not logged or stored — see the privacy policy.