RDAP Endpoint Reference: Registry URLs, Bootstrap, and Query Paths

Last updated August 8, 2026

RDAP endpoints are the HTTPS servers that answer registration-data queries for domains, IP addresses, and AS numbers. This reference lists every authoritative endpoint, shows how discovery works, and reports current coverage measured directly from IANA’s published registries.

Every figure below comes from the live bootstrap files, not a secondary source. The measurement date is stated so you can reproduce it.

What an RDAP endpoint is

An RDAP endpoint is a base HTTPS URL that accepts registration-data queries and returns JSON. Each registry operates its own. You append a path such as /domain/iana.org to the base URL, and the server replies with structured data.

RDAP replaces WHOIS, the plain-text protocol that runs on TCP port 43. WHOIS has no standard response format. Every registry formats output differently, so parsers break constantly. Our guide to RDAP vs. WHOIS covers when that changeover happened and how fast it moved.

RDAP fixes that with three guarantees. Responses are JSON with defined field names. Transport is HTTPS, so queries are encrypted. Errors use standard HTTP status codes.

The practical difference matters when you script. A WHOIS parser needs per-registry special cases. An RDAP client reads the same field names everywhere.

Our WHOIS Lookup tool runs on RDAP for exactly this reason. For help interpreting what comes back, see how to read a WHOIS lookup.

The five Regional Internet Registry endpoints

Five Regional Internet Registries answer every IP address and AS number query worldwide. Each publishes one RDAP base URL. ARIN covers North America and RIPE NCC covers Europe. APNIC, LACNIC, and AFRINIC cover Asia-Pacific, Latin America, and Africa.

These five endpoints are stable. They rarely change, so hard-coding them is lower risk than hard-coding a domain registry URL.

All five returned HTTP 200 with a valid ip network object class. Response times are single unauthenticated requests from a US-based host, so treat them as indicative rather than a benchmark.

The spread is real, though. AFRINIC took roughly six times as long as ARIN. Set client timeouts accordingly if you query all five in sequence.

Which registry holds an address

You do not need to know in advance. Query the bootstrap file, or query any RIR and follow the redirect it returns.

Each RIR also accepts /autnum/ and /entity/ paths. That covers AS number lookups and organisation handles.

How the IANA bootstrap registry works

IANA publishes five JSON files that map query targets to endpoint URLs. A client fetches the relevant file, finds the entry matching its query, and sends the request there. RFC 9224 defines this discovery process, which replaced hard-coded endpoint lists.

The files live under data.iana.org/rdap/. Each contains a services array pairing keys with base URLs.

Note the publication dates. The IPv4 file has not changed since 2019, because RIR address allocations at that level are stable. The DNS file changes often, as new TLDs add RDAP service.

A sensible client caches these files for a day. Refetching on every query wastes a round trip and adds a dependency on IANA’s availability.

The discovery flow in practice

For a domain query, the sequence has three steps.

1. Fetch dns.json and locate the entry whose key matches the TLD.
2. Take the base URL from that entry.
3. Append /domain/{name} and send the request.

The same pattern works for addresses. Match the containing prefix in ipv4.json or ipv6.json, then append the query path.

RDAP coverage across the root zone

RDAP coverage splits sharply by TLD type. Generic TLDs are near-universal because ICANN contracts require RDAP. Country-code TLDs are not bound by those contracts, and most have not adopted it. Internationalised TLDs sit between the two.

The internationalised bucket is rarely discussed and sits at 62.3%. Many are generic IDN strings run by registries already under ICANN contract. That contract explains why the rate beats country codes.

Plan for the gap rather than around it. A domain tool that assumes RDAP everywhere will fail on roughly one in seven delegated TLDs.

Query paths for every RDAP object type

RDAP defines five lookup paths and three search paths. Lookups return one object and take an exact identifier. Searches return a list and accept partial matches. RFC 9082 specifies the syntax, and support for search paths varies by registry.

Send the correct Accept header, or some servers return HTML. The media type is application/rdap+json.

Most registries decline search paths for unauthenticated clients. Expect HTTP 501 or 403 on search, and design around lookups where you can.

Object tags and entity handles

Entity handles are ambiguous across registries, because two registries can issue the same handle string. RFC 8521 solves this with object tags. A handle carries a suffix identifying its registry, and a separate IANA registry maps each suffix to an endpoint.

A handle such as ABC123-ARIN ends in a registered tag. The tag tells a client which endpoint owns that handle.

Only seven tags are registered, and AFRINIC is not among them. The mechanism is available to any registry, but uptake stays low.

What to do when bootstrap discovery fails

Discovery fails when a TLD has no bootstrap entry. Two fallbacks help. An aggregator such as rdap.org redirects queries to the right endpoint, and IANA’s own server answers domain queries directly. Neither invents data for registries that publish none.

We tested both on August 8, 2026. The IANA server returned HTTP 200 with a valid domain object. The rdap.org aggregator returned HTTP 302, redirecting to the authoritative registry as designed.

• https://rdap.org/domain/{name} — redirects to the authoritative endpoint, so your client must follow redirects.
• https://rdap.iana.org/domain/{name} — answers directly for TLDs IANA holds data on.

When a country-code TLD has no RDAP service, fall back to port 43 WHOIS. That path still works for .de, .jp, and the rest of the uncovered set.

Reading an error correctly

A 404 from the right endpoint means the object does not exist. A 404 from the wrong endpoint means your discovery step failed.

We confirmed this by querying Verisign’s .com endpoint for a .org domain. It returned HTTP 404 in 0.11 seconds, which is the correct behaviour and a common source of false negatives.

Rate limits usually surface as HTTP 429. Back off rather than retrying immediately, since several registries block persistent offenders.

RDAP endpoint FAQ

What is the difference between WHOIS and RDAP?

WHOIS is a plain-text protocol on TCP port 43 with no standard response format, so every registry formats output differently. RDAP is an HTTPS service returning JSON with defined field names and standard HTTP status codes. RDAP also supports internationalised text and structured redaction, which WHOIS cannot express.

Do I need an API key to query an RDAP endpoint?

No. Every endpoint listed on this page answers unauthenticated HTTPS requests. All five Regional Internet Registries returned data without credentials when tested. Some registries offer authenticated access that reveals additional fields, but the public tier needs no key. Rate limits still apply to anonymous clients.

Why does my country-code domain return no RDAP data?

Most country-code registries have not adopted RDAP. Only 70 of 248 country-code TLDs published an endpoint when we measured on August 8, 2026. ICANN contracts require RDAP for generic TLDs, but country-code registries operate outside those contracts. For uncovered TLDs, query the registry’s port 43 WHOIS service instead.

What does rdap.org do?

The rdap.org service is an aggregator that performs bootstrap discovery for you. You send a query to rdap.org and it issues an HTTP 302 redirect to the authoritative registry endpoint. Your client must follow redirects for this to work. It does not store or serve registration data itself.

Which RFC defines RDAP endpoint discovery?

RFC 9224 defines how clients find the authoritative RDAP service, and it obsoletes the earlier RFC 7484. Related specifications cover the rest of the protocol. RFC 7480 defines HTTP usage and RFC 7481 covers security. RFC 9082 defines the query format and RFC 9083 defines JSON responses.

Why is registrant contact data missing from RDAP responses?

Registries redact most personal contact fields by default under GDPR and ICANN privacy policy. RFC 9537 defines how a response signals which fields were removed, so redaction is explicit rather than silent. Requesting nonpublic data requires a documented legitimate interest through ICANN’s Registration Data Request Service.

References

Every figure on this page traces to a primary source. The bootstrap registries and root zone list are IANA publications. The protocol behaviour is defined across seven RFCs, all published by the RFC Editor.

• RFC Editor — RFC 9224: Finding the Authoritative Registration Data Access Protocol (RDAP) Service
• RFC Editor — RFC 9082: Registration Data Access Protocol (RDAP) Query Format
• RFC Editor — RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP)
• RFC Editor — RFC 7480: HTTP Usage in the Registration Data Access Protocol (RDAP)
• RFC Editor — RFC 7481: Security Services for the Registration Data Access Protocol (RDAP)
• RFC Editor — RFC 8521: Registration Data Access Protocol (RDAP) Object Tagging
• RFC Editor — RFC 9537: Redacted Fields in the Registration Data Access Protocol (RDAP) Response
• IANA — RDAP Bootstrap Service Registry for Domain Name Space
• IANA — RDAP JSON Values Registry
• ICANN — Registration Data Access Protocol (RDAP)

Related tools and guides

RDAP endpoints answer registration questions, but most investigations need DNS and address data too. These NetworkCheckr tools cover the adjacent lookups, and each runs in the browser without an account.

• WHOIS Lookup — queries domains, IP addresses, and AS numbers over RDAP.
• How to Read a WHOIS Lookup — interprets the fields an RDAP response returns.
• RDAP vs. WHOIS — the timeline of the changeover and what it changed.
• Reverse DNS Lookup — resolves an IP address back to its PTR record.
• DNS Lookup — checks A, AAAA, MX, TXT, and CNAME records.
• IP Geolocation Lookup — shows the ISP, ASN, and approximate location behind an address.
• Networking tools hub — the full collection.