RDAP proposal would give lookup tools more control over redirects
A proposed pair of RDAP extensions would let tools request a handoff to a related record or ask to stay with the current server. The source of a result would still matter.
On this page
RDAP lookup tools could gain more control over whether a query moves to another service. An October 13, 2026 update to the IETF draft Explicit RDAP Redirects documents an option to request no redirection alongside an existing proposal for requesting a handoff to a related record.
The distinction matters when a registry and a registrar each hold a domain record, or when an IP-address lookup moves from a regional registry to a service with more-specific registration information. The server that receives the first request is not always the server that supplies the final result.
The extensions remain proposals under development. Revision 05 is an active Internet-Draft intended to become a Proposed Standard, not an approved standard or a feature available from every RDAP service.
Why a lookup can move between services
RDAP does not store every registration record in one central database. A tool normally uses IANA bootstrap information to select an initial service, then requests the relevant object.
For a domain, a registry response may contain a link to the sponsoring registrar’s RDAP record for the same name. That link is part of the JSON response. It does not, by itself, redirect the HTTP request: the tool must decide whether to retrieve it.
An HTTP redirect works differently. The server returns a redirect status and a Location header telling the client where to make its next request. In the IP-address case described by the draft, the service selected through bootstrap discovery may redirect to another server holding more-specific registration information.
Both mechanisms can lead to another source, but a tool handles them differently. Our RDAP server discovery guide explains the existing bootstrap and redirect process.
Asking for a related record directly
The proposed redirects0 extension would let a client request a redirect to a resource with a specified relationship to the object being queried.
Without that extension, a tool seeking a registrar’s domain record may first retrieve the registry’s full response, inspect its links array and extract the registrar URL. The proposal would let the tool ask the registry for that handoff directly.
For example, a request to a supporting registry could use this path:
GET /redirects0_ref/related/domain/example.com HTTP/1.1
Accept: application/rdap+jsonIf an appropriate link exists and the client is authorized, the server would return an HTTP redirect with the linked URL:
HTTP/1.1 307 Temporary Redirect
Location: https://registrar.example/domain/example.comThis is an illustrative exchange, not a working endpoint. The server’s published base path would also need to be preserved when constructing the request.
The tool requests a relationship, not an arbitrary destination. The server selects a matching link according to the draft’s rules and its policy. If no appropriate link exists, the draft requires a 404 response. That does not necessarily mean the domain is unregistered: the unavailable item may be the requested relationship.
The mechanism applies to object lookups, not searches or help queries. It also depends on known server support; the draft advises against trying it speculatively and then repeating the lookup without the extension after an error.
Under the draft, supporting servers advertise each implemented extension in the rdapConformance array of their help responses.
Asking the current server not to redirect
The proposed noRedirects0 extension addresses the opposite need. A client may want the registration information held by the initially selected server rather than an automatic handoff to a more-specific source.
Revision 05 illustrates an IP-address lookup with this request header:
Accept: application/rdap+json;exts_list=rdap_level_0+noRedirects0The exts_list mechanism is itself described in a separate IETF draft. If the server honors the no-redirect preference, it must return an RDAP resource, not a web page or another non-RDAP response.
This is a preference, not a guarantee. The draft explicitly requires clients sending the signal to remain capable of processing a redirect. It does not force a service to supply a record it cannot provide.
For an investigator, keeping the initial server’s response could make it easier to examine that provider’s registration view and decide separately whether to follow a referral. It would not establish that this view is always the most detailed or the best fit for the investigation.
What changed on October 13
The revision 05 change log lists documentation of noRedirects0 among the changes. The explicit redirect-request mechanism predates this update.
The revision also defines new link relationships for hierarchy navigation, returns to HTTP 400 for redirect requests involving searches or help, updates security guidance, and adds a geolocation-feed example. These are changes to the proposal, not announcements of provider deployment.
October 21, 2026 update: service discovery, not record redirects
The separate RDAP Extensions draft, not Explicit RDAP Redirects, proposes three service-discovery link relationships in revision 16, section 7.3, dated October 20, 2026:
rdap-base: the base URL of an RDAP service.rdap-base-up: the base URL of the RDAP service one level up in a service hierarchy.rdap-base-down: the base URL of the RDAP service one level down.
These identify services, not individual records. Clients use a base URL to construct a query by adding the appropriate path. For example, https://rdap.example/rdap/ is a base URL; adding domain/example.com identifies a particular domain record.
For all three relationships, the draft says they MUST NOT be used in HTTP redirects because their targets are not expected to fully identify the requested RDAP resource. A service base alone is not a complete record destination, unlike the registrar-record URL in the explicit redirect example above.
As checked on October 21, the RDAP Extensions status page lists revision 16 as the latest. Both drafts remain work in progress. The proposed IANA registrations do not establish completed registration, standards approval or provider deployment.
What readers should watch for
The practical benefit would be more deliberate selection of a registration-data source. It would not automatically reveal withheld information, make a registrar’s response superior to a registry’s, or solve browser cross-origin access restrictions.
A lookup tool should still retain the requested URL, final responding URL and retrieval time. If it retrieves both registry and registrar records, it should identify their sources rather than silently combine conflicting values. Redirect-loop protection remains necessary too.
As of October 21, 2026, the next developments to watch are changes to the drafts, formal approval and RFC publication, and verified server adoption. The Explicit RDAP Redirects status page still lists revision 05; provider documentation and actual responses are separate evidence that a service supports it.