How WHOIS and RDAP Work: Domain and IP Lookup Explained

Every IP address block, domain name, and autonomous system number on the internet has a registered owner. WHOIS and its modern successor RDAP are the protocols that expose this registration data — who holds the resource, which organization administers it, and when it was allocated. This site's domain lookup feature uses RDAP to retrieve registration information for the IP addresses and ASNs you query.

WHOIS: The Original Protocol (RFC 3912)

WHOIS dates to the early ARPANET era and was standardized in RFC 3912. The protocol is deliberately simple: open a TCP connection to port 43, send a query string followed by CRLF, and read back a plain-text response. There is no authentication, no encryption, no structured data format, and no versioning. What comes back is free-form text whose layout depends entirely on the server.

A minimal WHOIS session looks like this:

$ telnet whois.arin.net 43
> 8.8.8.8
[plain-text response with OrgName, NetRange, CIDR, etc.]

Each Regional Internet Registry (RIR) — ARIN (North America), RIPE NCC (Europe/Middle East), APNIC (Asia-Pacific), LACNIC (Latin America), and AFRINIC (Africa) — runs its own WHOIS server. IP addresses and ASNs are looked up at the RIR that allocated them. Domain names are looked up at the registry for that TLD, and often the registry will refer you to a registrar's WHOIS server for per-domain contact details.

Referral Chains

A WHOIS query rarely ends at the first server you contact. The protocol supports referrals — a server can respond with a line like ReferralServer: whois.ripe.net, telling the client to repeat the query at a different server for more authoritative data. Most WHOIS clients follow this chain automatically.

For domain names the chain has up to three hops:

1. IANA root WHOIS (whois.iana.org) — returns the registry for the TLD
2. Registry WHOIS (e.g., whois.verisign-grs.com for .com) — returns registrar info and a referral
3. Registrar WHOIS (e.g., whois.godaddy.com) — returns per-domain contact data

For IP address space the chain is shorter: IANA's WHOIS (or a direct query to an RIR) directs you to the holding RIR, and from there you may get further referrals to LIR (Local Internet Registry) WHOIS servers for sub-allocations.

Thick vs. Thin Registries

The terms thick and thin describe how much data a registry stores centrally versus delegating to registrars.

ICANN completed the migration of .com from thin to thick in 2024, requiring Verisign to centralize all registrant contact data. This simplifies WHOIS lookups — one query to the registry returns the full record — but it also concentrates enormous amounts of personal data at a single operator.

GDPR and WHOIS Redaction

The GDPR, which took effect in May 2018, fundamentally changed what domain WHOIS records can contain for European registrants. RIRs and domain registries responded by redacting personal contact information — registrant name, email, phone, and address — replacing it with proxied contact forms or simply blank fields. The result is that a large fraction of WHOIS records now return essentially no useful contact data for natural persons.

ICANN's System for Standardized Access/Disclosure (SSAD) is a framework for accredited parties (law enforcement, IP rights holders) to request unredacted data, but its deployment has been slow. IP address WHOIS at RIRs is less affected because allocations are made to organizations rather than individuals, though RIRs have also started redacting personal names from abuse contacts.

RDAP: The JSON Successor

The Registration Data Access Protocol (RDAP) was designed to address every structural weakness of WHOIS. It is defined by a suite of RFCs: RFC 7480 (HTTP usage), RFC 7481 (security), RFC 7482 (query format, now superseded by RFC 9082), RFC 7483 (response format, now superseded by RFC 9083), and RFC 7484 (bootstrap registry). RDAP operates over HTTPS, returns JSON, supports internationalized names (IDN), and uses standard HTTP authentication and redirect mechanisms for access control.

A typical RDAP query for an IP address:

GET https://rdap.arin.net/registry/ip/8.8.8.8
{
  "objectClassName": "ip network",
  "handle": "NET-8-8-8-0-1",
  "startAddress": "8.8.8.0",
  "endAddress": "8.8.8.255",
  "ipVersion": "v4",
  "name": "LVLT-GOGL-8-8-8",
  "entities": [ ... registrant and abuse contacts ... ],
  "events": [ ... registration and last-changed dates ... ]
}

The structured JSON response means a client can reliably extract the registrant name, abuse contact email, or registration date without fragile regex parsing against free-form text.

RDAP Bootstrap: Finding the Right Server

Because RDAP uses HTTP redirects for referrals, you need to know which server to start with. The IANA RDAP bootstrap registry (RFC 7484) solves this with JSON files published at https://data.iana.org/rdap/. There are separate bootstrap files for IPv4 prefixes, IPv6 prefixes, ASNs, domain TLDs, and object tags. A client fetching https://data.iana.org/rdap/asns.json gets a mapping from AS number ranges to RDAP base URLs — for example, ARIN covers AS1–AS1876, AS2307–AS2529, and so on.

Once the correct base URL is known, the query paths are standardized: /ip/{address}, /autnum/{asn}, /domain/{name}, /nameserver/{fqdn}, /entity/{handle}. This predictability is a major improvement over WHOIS, where every server has its own query syntax and response format.

IP and ASN RDAP at the RIRs

Each RIR operates an RDAP endpoint:

For an ASN like AS15169 (Google), the bootstrap file directs you to ARIN's RDAP endpoint. An RDAP client fetches https://rdap.arin.net/registry/autnum/15169 and receives a JSON object containing the organization name, address, registration events, and contact handles — all in a predictable schema that requires no parsing heuristics.

Registry vs. Registrar Data

For domain names the data model has two layers. The registry (e.g., Verisign for .com) holds authoritative data about the domain's delegation — its nameservers, registrar, and creation/expiry dates. The registrar (e.g., Namecheap, GoDaddy) holds the registrant contact information submitted at registration time. RDAP encodes both layers within a single response using entities objects with role fields (registrant, administrative, technical, registrar).

When GDPR redaction applies, the registrant entity's vcardArray will be empty or replaced with a proxy address. The domain's nameservers and registrar data are unaffected by redaction and remain fully visible.

Practical Differences for Security and Abuse Research

For network operators investigating abuse — spam, DDoS, BGP hijacks — RDAP and WHOIS serve different practical needs. WHOIS is still useful for quick terminal lookups and is universally supported by abuse-handling tools. RDAP is the right choice when writing automated tooling because the JSON schema is stable, the abuse contact email appears at a predictable path (.entities[?role==abuse].vcardArray), and HTTP rate-limit headers tell the client when to back off.

RDAP also supports search queries at some registries — searching by organization name or email address across all registrations — which is invaluable for tracking IP space held by a particular organization. WHOIS has no standardized search mechanism; support is entirely server-dependent.

When investigating a BGP hijack or unexpected route origin, combining RDAP data with RPKI ROA records gives a complete picture: RDAP tells you who the RIR says legitimately holds the address space; ROAs tell you which ASes are authorized to announce it.

Explore It Live

This tool uses RDAP to annotate IP addresses and ASNs with registration data. Try it on some well-known resources:

• Look up 8.8.8.8 — Google's DNS; see the ARIN RDAP registration for the owning netblock
• AS3356 — Lumen/Level 3, a major transit provider; see RDAP org data alongside BGP routes
• AS2856 — BT Group; RIPE NCC RDAP registration for a European operator

Enter any IP address or ASN in the lookup box to see live BGP routing data combined with RDAP registration information pulled directly from the relevant RIR.