Methodology

RDAP Lookup is a static client. It does not maintain a copied registration database. For every lookup it discovers an authoritative service from IANA’s public bootstrap registries, sends the request from your browser to that service, and presents the response it receives. This page describes each step and the limits of what the result can tell you.

Bootstrap discovery

The client loads the IANA RDAP bootstrap registries described in RFC 9224: one registry each for domain names, IPv4 address space, IPv6 address space, and autonomous system numbers. These files map identifiers and ranges to the base URLs of the RDAP services that IANA has registered for them.

The client matches a query to the most specific entry in the applicable registry: the longest matching domain suffix for a domain name, the longest matching prefix for an IP address, and the containing range for an autonomous system number. The result is a base URL for a service, not a registration record.

Query formation

The client appends the RFC 9082 path for the resource type and the normalized value:

/domain/example.com
/ip/192.0.2.1
/autnum/64496

It sends the request with an Accept header for RDAP JSON, directly from the browser to the service that IANA’s registry designated. No intermediary stores or rewrites the query.

Input normalization

Before a query is formed, the client normalizes what you type so it can be matched reliably:

• Whitespace is trimmed.
• Domains are lowercased, resolved through the URL parser to their hostname, and reduced to ASCII form, so an internationalized name such as bücher.com becomes xn--bcher-kva.com.
• A DNS root trailing dot is accepted, so example.com. and example.com address the same resource.
• Pasted URLs resolve to their hostname, so https://www.example.com/path queries www.example.com.
• IP addresses keep their class-specific form, and an ASN may be entered with or without the AS prefix.

Response handling

The client displays a compact reading of the common fields in the response: the handle and registry, status values, dates, nameservers, entities, notices, and remarks. The original JSON response and the exact service URL are preserved and shown alongside it, because the raw response is the underlying record and the compact reading is a convenience.

The client treats the response as what it is: a statement from one service, under that service’s policy, at the time of the request. Fields may be omitted or redacted by the service. Notices, remarks, and linked policy pages are part of the response and should be read alongside the fields they qualify.

Limits

• The site stores no lookup history and no database of records. Each result is fetched live.
• The authoritative service may block browser cross-origin requests. Those lookups cannot succeed from a static client alone.
• Bootstrap discovery identifies the designated service for a scope. It is not a guarantee that the returned fields are complete, accurate for a legal purpose, or legally authoritative.