🔎 WHOIS- / RDAP-Abfrage

About WHOIS and RDAP

Every domain name, block of IP addresses and autonomous system number is recorded in a registry, and those registries publish a slice of that record for the public to query. The original protocol for asking was WHOIS, defined in 1982 and refreshed as RFC 3912 in 2004. It is charmingly simple: open a TCP connection to port 43, send the thing you want to look up, read back whatever comes down the socket, and close the connection.

That simplicity is also its downfall. WHOIS has no schema, no defined character encoding, no authentication, no way of saying “this field is the expiry date”, and no standard way to discover which server holds the answer. Every registry invented its own layout, so anyone consuming the data ended up maintaining a pile of brittle text parsers that broke whenever a registry adjusted its formatting.

RDAP: the replacement

RDAP — the Registration Data Access Protocol — is the IETF's standardised successor, published in 2015 as RFC 7480 to 7484 and revised in 2021 as RFC 9082 (queries) and RFC 9083 (responses). It fixes essentially every complaint about WHOIS:

• It is ordinary HTTPS. A lookup is a GET request, so it is encrypted, cacheable and works through any HTTP client.
• Responses are JSON with a defined schema. Dates are ISO 8601 in a typed events array, statuses are a controlled vocabulary, contacts are jCard objects. No text scraping.
• Everything is UTF-8, so internationalised domain names and non-Latin addresses survive intact.
• Server discovery is standardised. IANA publishes bootstrap files mapping each TLD, IP block and AS range onto the authoritative RDAP service, so a client can always find the right server.
• It supports differentiated access. A registry can serve a public view to anyone and a fuller view to authenticated parties such as law enforcement — impossible with port-43 WHOIS.

ICANN made RDAP compulsory for all gTLD registries and registrars in 2019, and under the Registration Data Policy that took effect in 2025 the legacy port-43 WHOIS service for gTLDs is being retired outright. RDAP is now the primary source, not a nicety.

How this tool works

Your query is classified as a domain, an IP address or an AS number, then resolved against IANA's published bootstrap registries to find the authoritative RDAP service — Verisign for .com, Nominet for .uk, ARIN or RIPE NCC for an address block, and so on. We query that registry directly and parse the JSON it returns. No API key, no third-party data broker, no cached copy: what you see is what the registry said, and every response tells you exactly which host answered.

Why the contact details are usually blank

Until 2018, a WHOIS lookup on a domain typically returned the registrant's full name, postal address, telephone number and email. When the General Data Protection Regulationcame into force in May 2018, publishing the personal data of an identifiable individual to the entire internet — with no consent, no purpose limitation and no way to object — became impossible to justify under EU and UK law. ICANN responded with the Temporary Specification, since folded into permanent policy, which requires registries to redact the personal fields by default.

What you now get for most domains is:

• Published: the domain handle, registrar name and IANA ID, status codes, registration/expiry/last-changed dates, nameservers, DNSSEC state and a registrar abuse contact.
• Redacted: registrant, administrative and technical names, organisations, addresses, phone numbers and email addresses. Many registries substitute an anonymised relay address such as redacted@registry.example or a web contact form.
• Usually still published: the registrant organisation where the registrant is a company rather than a private individual, since GDPR protects natural persons — though plenty of registries redact it anyway rather than judge case by case.

RFC 9537 gave this a formal shape: registries can list precisely which fields were removed and why, and where that machine-readable declaration is present this tool shows it to you. Requesting the withheld data means going through the registrar's disclosure process with a legitimate legal basis. Note that IP address and AS number records are far less affected — those are allocated to organisations rather than individuals, so RIR data remains largely intact, including the abuse contact you would use to report a compromised host.

Reading domain status codes

Status codes come in two families. Codes beginning client are set by your registrar; codes beginning server are set by the registry itself and cannot be cleared from your control panel.clientTransferProhibited, clientDeleteProhibited andclientUpdateProhibited together form the standard registrar lock, and seeing all three on a domain you own is a good sign — it is the cheapest defence against domain hijacking. Codes such as serverHold, redemptionPeriod andpendingDelete are the ones to worry about: they mean the domain is out of DNS or on its way to being released. This tool translates each code it finds into plain English.

Coverage limits — what this tool cannot tell you

RDAP is mandatory for gTLDs (.com, .net, .org,.dev, .xyz and the rest) and for all five Regional Internet Registries, so IP and ASN lookups always work. Country-code TLDs are run by independent national registries and joined voluntarily, so coverage varies. At the time of writing.uk (including .co.uk, via Nominet), .nl,.fr, .au, .br and .in all publish RDAP, while .de, .it, .ru, .eu,.ch, .jp, .cn, .se and .iodo not appear in the IANA bootstrap registry at all.

When you query a TLD with no RDAP service, this tool says so plainly and points you at the registry that does hold the record. It will never fabricate a plausible-looking answer to fill the gap — a blank is more useful than a guess.

Privacy and rate limits

Lookups run server-side, so the registry sees this site's address rather than yours. RDAP servers throttle heavy use; if you hit a limit you will get a clear rate-limit message rather than a silent failure. Please keep queries to what you actually need.