Explicit RDAP Redirects

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Many Registration Data Access Protocol (RDAP, described in [RFC7480], [RFC7481], [RFC9082], [RFC9083] and others) resources contain links to related RDAP resources.¶

For example, in the domain space, an RDAP record for a domain name received from the registry operator may include a link for the RDAP record for the same object provided by the sponsoring registrar (for example, see [gtld-rdap-profile], in which links to registrar RDAP URLs are provided by using a link object with the related relation), while in the IP address space, an RDAP record for an address allocation may include links to enclosing or sibling prefixes.¶

In both cases, RDAP service users are often equally if not more interested in these related RDAP resources than the resource provided by the TLD registry or RIR. However, to obtain the URL(s) of the related resources(s), the client must request the full RDAP record (which the server must then produce and deliver) in order to extract the relevant URL from the "links" property of the object.¶

This results in the wasteful expenditure of time, compute resources and bandwidth on the part of both the client and server.¶

This document describes an extension to RDAP that allows clients to request that an RDAP server redirect them to the URL of a related resource.¶

2. RDAP Redirect Request

To request a redirect to a related resource, the client sends an HTTP GET request with a URL of the form:¶

<base URL>redirects0_ref/<relation>/<lookup path>

The client replaces <base URL> with the applicable base URL (which, as per [RFC9224], has a trailing / character), <relation> with the desired relationship type, and <lookup path> with the lookup path of the object being sought (which, as per [RFC9082], does not have a leading / character).¶

For example, the URL of a redirect query for the domain example.com, where the base URL for the "com" TLD is https://rdap.example.com/rdap/, would be:¶

https://rdap.example.com/rdap/redirects0_ref/related/domain/example.com

The redirect query for the parent network of 192.0.2.42 with the base URL of https://rdap.example.net/ would be:¶

https://rdap.exampple.net/redirects0_ref/rdap-up/ip/192.0.2.42

Lookup paths for domain names, IP networks, autonomous system numbers, nameservers, and entities are described in [RFC9082]. Lookups defined by RDAP extensions may also use this extension.¶

Redirect requests for searches, where more than one object is returned, and help queries, as described by [RFC9083], are not supported. Servers MUST return an HTTP 409 for these requests.¶

3. RDAP Redirect Response

If the object specified in the request exists, a single appropriate link exists, and the client is authorised to perform the request, the server response MUST:¶

1. have an HTTP status code of 301 (Moved Permanently), 302 (Found), 303 (See Other), 307 (Temporary Redirect) or 308 (Permanent Redirect, see Section 15.4.9 of [RFC9110]); and¶

2. include an HTTP Location header field, whose value contains the URL of the linked resource.¶

If the server cannot find an appropriate link, the response MUST have an HTTP status of 404.¶

If an RDAP server holds in its datastore more than one relationship type for an object, a scenario that is possible but not common, only one of the URLs, as determined by server policy, can be returned.¶

The following examples use the HTTP/1.1 message exchange syntax as seen in [RFC9110].¶

An example of a redirect request from a domain registry to a domain registrar, where the registry implements [gtld-rdap-profile]:¶

Client Request:

GET /redirects0_ref/related/domain/example.com HTTP/1.1
Accept: application/rdap+json

Server Response:

HTTP/1.1 307 Temporary Redirect
Location: https://registrar.example/domain/example.com

An example of a redirect request for a parent IPv4 network:¶

Client Request:

GET /redirects0_ref/rdap-up/ip/192.0.2.42 HTTP/1.1
Accept: application/rdap+json

Server Response:

HTTP/1.1 307 Temporary Redirect
Location: https://rir.example/ip/192.0.2.0/24

An example of a redirect request for a parent IPv6 network:¶

Client Request:

GET /redirects0_ref/rdap-up/ip/2001%3adb8%3a%3a1 HTTP/1.1
Accept: application/rdap+json"

Server Response:

HTTP/1.1 307 Temporary Redirect
Location: https://rir.example/ip/2001%3adb8%3a%3a/32

Vary: accept, accept-language

4. RDAP Conformance

Servers which implement this specification MUST include the string "redirects0" in the "rdapConformance" array in responses to RDAP "help" queries.¶

5. Bootstrap Use Case

The primary use case of this extension is a one-hop redirect, where the client is not interested in the use of this extension beyond the first redirect. Another use case is querying a bootstrap redirect server for the authoritative source of information according to the IANA RDAP bootstrap information.¶

Client Request:

GET /redirects0_ref/rdap-bootstrap/ip/2001%3adb8%3a%3a1 HTTP/1.1
Accept: application/rdap+json"

Server Response:

HTTP/1.1 307 Temporary Redirect
Location: https://rir1.example/ip/2001%3adb8%3a%3a/32

Other uses cases may exist, but for this specific use case, this document registers the "rdap-bootstrap" link relationship type.¶

6. Multi-Hop Redirect Limitations

In some scenarios, a target server might have a policy to issue another redirect using this extension. For example:¶

Client Request to rdap1.example:

GET /redirects0_ref/rdap-example/exampleFoo_thing/abc HTTP/1.1
Accept: application/rdap+json"

Server Response:

HTTP/1.1 307 Temporary Redirect
Location: https://rdap2.example/redirects0_ref/rdap-example/exampleFoo_thing/abc

Note "rdap-example" is not a real relationship and is provided only for demostration purposes.¶

In this scenario rdap1.example is redirecting to rdap2.example with a "/redirects0_ref" path. However, not all servers may support this extension. Therefore, the "/redirects0_ref" path defined in this specification MUST only be used in an HTTP redirect if the server issuing the redirect is assured that the target server of the redirect supports this extension.¶

7. IANA Considerations

8. Security Considerations

A malicious HTTP redirect has the potential to create an infinite loop, which can exhaust resources on both client and server side.¶

To prevent such loops, RDAP servers which receive redirect requests for the self relation MUST respond with a 400 HTTP status.¶

As described in Section 15.4 of [RFC9110], when processing server responses, RDAP clients SHOULD detect and intervene in cyclical redirections.¶

9. Operational Considerations

The benefits of this extension will not materialize if a client issues a query using this extension, receives an error, and subsequently requeries a server without using this extensions. Therefore, clients SHOULD NOT use this extension unless the client has a priori knowledge of the target servers ability to process queries with this extension.¶

Likewise, servers SHOULD NOT issues redirects in the manner described in Section 6 unless the origin server has a priori knowledge of the target servers ability to process queries with this extension.¶

A redirect loop will occur if a server issues a redirect causing a client to follow redirects back to a previous server queired during the processing of the same query. Clients MUST cancel any queries when a redirect loop is detected. Servers MUST NOT issue responses that cause redirect loops.¶

10. Change Log

This section is to be removed before publishing as an RFC.¶

11. Acknowledgements

The authors would like to thank the following persons for their feedback and advice:¶

Jasdip Singh, Pawel Kowalik, Tom Harrison, Ben Schwartz.¶

Authors' Addresses