Why an RDAP Lookup Fails in a Browser

An RDAP request can succeed from a terminal or backend service yet fail in a web browser. That does not necessarily mean the domain, IP address or Autonomous System Number has no registration record. A browser adds security rules—especially the same-origin policy—that a command-line client does not enforce.

RDAP Lookup sends the request from your browser directly to the RDAP service selected through IANA bootstrap data. That preserves a direct path to the source, but the service must permit the browser to read its response. If it does not, the browser can block the result even when the service is reachable and would answer the same request to another kind of client.

Quick answer: First separate browser access failures from RDAP results. A visible 404 response from the correctly selected authoritative service means it found no matching object; a CORS error, network timeout, 429, redirect problem or invalid response means the lookup did not establish that. Record the final URL, status and retrieval time, then use a permitted client or the operator’s documented service when necessary.

A browser lookup has several stages

Before a result can appear, a browser-based RDAP client has to complete several independent steps:

1. Load the applicable IANA bootstrap registry.
2. Match the domain suffix, IP prefix or ASN range to an RDAP base URL.
3. Construct the resource-specific request URL.
4. Connect to the selected service and follow any allowed redirects.
5. Receive a response that the browser is permitted to expose to the page.
6. Confirm that the response is an RDAP response for the requested object.

A failure at any step can look like a generic lookup error. The important question is where the request stopped. A discovery problem, browser-policy block and authoritative 404 have very different meanings.

For the underlying discovery process, see How to Find the RDAP Server for a Domain. For terminal commands that can inspect a selected endpoint, see How to Query an RDAP Server with cURL.

CORS: the common browser-only failure

Web pages are normally allowed to read responses only from their own origin. This is the same-origin policy. An RDAP page at https://rdaplookup.org is making a cross-origin request when it reads a registry response from another hostname.

For the browser to expose that response to the page, the RDAP service must return a suitable Cross-Origin Resource Sharing (CORS) response header. For a simple public request, that commonly includes:

Access-Control-Allow-Origin: *

It can also name a particular permitted origin. The exact header policy is controlled by the RDAP service, not by the page making the request.

When the service omits a suitable CORS header, the network request may still reach the service. The browser then prevents the page’s JavaScript from reading the response. Developer tools can show a CORS-related message, while the page itself cannot reliably inspect the response body or status.

This is why an endpoint can work with curl but not in a browser:

curl --header 'Accept: application/rdap+json' \
  'https://rdap.example.test/ip/192.0.2.1'

cURL does not implement a web page’s same-origin policy. Its success shows that the endpoint was reachable for that command and time; it does not show that the endpoint allows a browser page on a different origin to read the result.

What CORS does and does not mean

A CORS block means the page could not read the response. It does not prove that:

• the requested object does not exist;
• the RDAP service is offline;
• the registry has no data for the resource;
• the returned record is invalid; or
• the service would reject a backend or command-line request.

Conversely, a service that enables CORS is not necessarily reachable, complete or suitable for every request. It can still return an RDAP error, rate-limit the client, redirect the request or apply its own access policy.

Do not try to bypass CORS with a random public proxy or a browser extension that disables web security. Those approaches can expose lookup terms, response data or account credentials to an unrelated third party, and they can make normal browser protections ineffective. A production fallback should be a controlled backend that performs its own discovery and validates each destination; it must not proxy arbitrary user-provided URLs.

Read visible HTTP responses by category

When a page can access an RDAP response, the HTTP status is part of its meaning. The response body can provide useful context, but a JSON body alone does not make a request successful.

Result	What it can mean	What it does not establish
200 OK	The service returned a response. Validate that it is RDAP and matches the requested object.	That every optional registration field is public or complete.
301, 302, 303, 307, 308	The service directed the client to another URL.	That the browser can safely follow or read the final response.
400 Bad Request	The server could not process the submitted query.	That the requested resource is absent.
401 Unauthorized	Authentication is required.	That no record exists.
403 Forbidden	The service understood the request but denies this client or request.	That the resource is unregistered.
404 Not Found	The correctly selected service has no matching object for the query.	That a domain is available to register.
429 Too Many Requests	The client has exceeded the service’s request policy.	That another immediate request will succeed.
5xx	The service encountered a temporary or server-side failure.	That discovery or registration data is wrong.

For a browser lookup, only a status and body the browser actually exposes to the page can be interpreted this way. A generic browser “failed to fetch” error can represent CORS, a network problem, a blocked redirect or another failure where the page cannot determine the status.

A 404 is not a domain-availability answer

A 404 Not Found from a correctly routed, readable RDAP service can be useful negative registration evidence. It means that service did not return a matching object for that request. It does not by itself establish that a domain can be registered.

Domain availability can also depend on registry reservations, premium-name rules, eligibility requirements, pending lifecycle operations and registrar systems that are outside the RDAP response. A browser error, timeout or CORS block provides even less evidence: it says nothing reliable about the resource’s registration state.

For IP addresses and ASNs, a 404 is likewise not a statement about current routing, reachability, geolocation or whether the number is in use. These are separate questions from registration-data lookup.

Redirects can change the request path

An RDAP service can use an HTTP redirect to direct a client to another URL. A browser follows redirects according to HTTP and browser security rules, subject to its own constraints. The final service can have different CORS behavior from the original URL.

If the page displays a final response URL, preserve it with the retrieval time. It identifies the service that supplied the response, which can differ from the IANA bootstrap base URL. A redirect itself is not a failure, but it should be handled with limits and HTTPS restrictions in an automated client.

Do not rebuild a redirect destination by guessing a URL from a registry name, response handle or partial path. Use the complete Location URL provided by the service. The domain-discovery guide explains why preserving a published base path matters.

Rate limits require waiting, not faster retries

RDAP services can limit traffic by IP address, request pattern, user agent or other service-specific policy. A visible 429 Too Many Requests response means the client should reduce its request rate. If the service provides a Retry-After header, wait for at least that period before retrying.

Repeated refreshes can extend a restriction or make a shared-network rate limit worse for other users. Browsers also do not offer the same level of queueing, caching and per-service backoff control as a carefully designed backend client.

For routine or automated use:

• cache bootstrap data rather than downloading it for every request;
• avoid repeatedly querying the same object;
• use bounded retries only for temporary failures;
• honor Retry-After when it is supplied; and
• follow the service’s terms and published guidance.

Do not treat a 429, timeout or CORS error as an invitation to switch automatically to unrelated endpoints. The correct service is determined through RDAP discovery, not hostname guessing.

A response can be readable but not be RDAP

An HTTP 200 response is not enough. A misconfigured base URL, captive portal, proxy or unrelated web page can return HTML or ordinary JSON at the expected hostname. A browser client should verify the response before displaying it as registration data.

Useful checks include:

• an RDAP media type such as application/rdap+json;
• valid JSON;
• the top-level rdapConformance member;
• an appropriate objectClassName, such as domain, ip network or autnum; and
• an identifier or range consistent with the submitted query.

For example, an IP lookup should return an ip network object whose startAddress and endAddress contain the queried IP address. A readable HTML page or a JSON object unrelated to the requested resource is not an RDAP result.

The guides to reading an IP address RDAP response and reading an ASN RDAP response describe object-specific validation and interpretation.

Use browser developer tools carefully

If you need to investigate a failed browser request, developer tools can help distinguish a visible HTTP response from a browser-side block. In the browser’s Network panel, find the request and note:

1. the request URL and any redirect chain;
2. whether a response status is visible;
3. the response Content-Type and CORS headers, when available;
4. the final URL; and
5. the time of the request.

The Console panel can report that a cross-origin response was blocked, but browser messages differ by browser and may not disclose the server’s response. Treat console text as a diagnostic clue rather than a substitute for the record itself.

Avoid publishing complete request logs or raw responses without considering whether they include personal or sensitive operational information. Preserve only the evidence needed for troubleshooting, and follow the remote service’s terms of use.

A practical troubleshooting sequence

Use this sequence when a lookup fails in a browser:

1. Check that the input is a domain, IP address or ASN in a valid form.
2. Confirm that bootstrap discovery found a base URL for the resource type.
3. Record the selected and final URL, if either is visible.
4. If a readable HTTP status is available, interpret it by category rather than treating every failure as “not found.”
5. If the browser reports CORS or a generic fetch failure, do not infer anything about the registration state.
6. For 429, wait and reduce the query rate instead of immediately retrying.
7. For 5xx, timeout or TLS errors, retry later within reasonable limits and check the operator’s published status or help information when available.
8. If permitted and necessary, inspect the same authoritative endpoint with a controlled command-line or backend client, preserving the method and retrieval time.
9. Validate any returned JSON as RDAP before acting on its fields.

Frequently asked questions

Why does the URL work in cURL but not on an RDAP website?

cURL does not enforce the browser same-origin policy. The server may return a response to cURL but omit the CORS header required for a web page on another origin to read it.

Does a CORS error mean the RDAP service is down?

No. It means the browser page could not read the cross-origin response. The service may be operating normally for other clients, or it may have encountered a separate problem that the browser cannot expose to the page.

Can a browser client add the CORS header itself?

No. The RDAP service must return the permission header in its response. A page can request a resource, but it cannot grant itself permission to read another origin’s response.

Does 404 Not Found prove that a domain is available?

No. After correct discovery, it can show that the RDAP service found no matching registration object. Registry reservations, lifecycle state, eligibility rules and registrar systems can still affect whether a name can be registered.

Should I disable browser security to make a lookup work?

No. Disabling security protections or using an untrusted proxy can expose your query and returned data. Use the registry’s documented service or a controlled, security-reviewed client when a browser cannot read the endpoint.

Inspect the source, not just the error

Run an RDAP lookup to see the selected service and any readable result. When a response is available, use How to Read a Domain RDAP Response to interpret its fields, notices and limitations.

Primary references

• RFC 7480: HTTP Usage in the Registration Data Access Protocol (RDAP)
• RFC 9082: Registration Data Access Protocol (RDAP) Query Format
• RFC 9224: Finding the Authoritative Registration Data Access Protocol (RDAP) Service
• MDN Web Docs: Cross-Origin Resource Sharing (CORS)