RDAP for domains and IP addresses: a practical guide

RDAP is a protocol for accessing registration data about domain names and Internet number resources. Unlike the traditional text-oriented WHOIS service, RDAP uses HTTPS and structured responses, making fields, links and access levels easier for software and people to interpret consistently.

How RDAP differs from WHOIS

WHOIS traditionally uses TCP port 43 and does not define one universal response format. RDAP is an HTTP API with JSON representations, status codes, links and service discovery. For generic top-level domains, ICANN moved to RDAP as the definitive registration-data service on 28 January 2025; country-code domains can follow different policies.

A structured response does not make every field public. Data can be redacted or exposed only to authorised requesters. A missing registrant name therefore does not mean a domain has no registrant.

Domains, IP networks and ASNs

RDAP also covers Internet number resources. Regional Internet registries expose information about IP networks and autonomous systems. Such a record identifies a resource holder or network operator; it does not necessarily identify the individual who used an address at a particular time.

Start with the WHOIS and RDAP overview, then compare network context with the 2ip IP information service. Registration records should not be treated as proof of an exact physical location.

Reading a result safely

Check the object type, status, registration events, nameservers and links to authoritative services. A domain expiry date does not promise immediate availability because lifecycle rules depend on the registry and registrar. The RDAP response format is specified in RFC 9083.

Locate the fault by network layer

A useful workflow starts at the edge of the local network. Check the interface address, default route and DNS configuration, then test the local gateway before moving to the public address and remote service. This prevents a Wi-Fi or Ethernet problem from being mistaken for an ISP routing problem. If the gateway remains stable while latency appears farther away, compare several destinations and repeat the measurement at another time.

Intermediate devices are not required to answer every diagnostic probe. Control-plane filtering, rate limiting and asymmetric routing can change what a trace displays while the application path continues to carry traffic normally.

Addresses, routes and the network you observe

A device's local address, its public egress address and the destination address describe different parts of the path. NAT, CGNAT, VPNs, proxies, CDNs and Anycast introduce additional boundaries, so one IP address should not automatically be treated as an identity for a user or a physical server. Record the destination and time of a test because DNS and BGP can lead a later measurement to different infrastructure.

With IPv6, one interface can also have several addresses, including temporary addresses. Source-address selection is performed by the network stack and can affect the path that is observed.

Make measurements reproducible

A single test is a snapshot. Repeat measurements in a series and record whether the connection is wired or wireless, whether a VPN is active, which resolver is in use and whether background traffic is present. Compare latency to the same destination and run throughput tests under comparable conditions. If latency rises only while the link is busy, investigate queueing and bufferbloat separately.

Keep the context as well as the final number. That makes it possible to distinguish a persistent configuration fault from a brief route change, radio congestion or a different remote edge being selected.