| Internet-Draft | RDAP Subordinate Referrals | October 2026 |
| Ranjbar | Expires 18 April 2027 | [Page] |
An RDAP query can be followed from the IANA bootstrap registries down to the most specific object a registry operator holds, and no further. When the holder of a registered resource keeps registration data for resources below it, such as names below a registered domain or more-specific networks below an address allocation, and publishes that data from an RDAP service of its own, a client has no in-band way to find that service. This document describes how a registry operator refers clients to such a holder-designated service. The registry redirects lookups for subordinate resources to the holder's service, so an unchanged client receives the most specific record as it would from any other redirect. On top of that, the covering object can advertise the holder's service, so a client that cares can discover the delegation and cross the authority boundary knowingly. The document uses the object relations and the redirect controls of draft-ietf-regext-rdap-referrals, and defines a family of "rdap-base" link relations whose target is the base URL of an RDAP service rather than an object.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Registration Protocols Extensions (regext) Working Group mailing list (regext@ietf.org).¶
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 18 April 2027.¶
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.¶
RDAP [RFC7480] [RFC9082] [RFC9083] lets a client find the authoritative service for a resource through the IANA bootstrap registries [RFC9224], and, for Internet number resources, navigate between objects with the link relations of [RFC9910]. Where more specific data sits inside the registry system, for example with a National Internet Registry, redirects already carry the client there. Outside that system the walk ends at the most specific object the registry operator holds: the registered domain at a domain registry or registrar, or the covering allocation or aggregated assignment at a Regional Internet Registry (RIR).¶
Below that point, holders increasingly keep registration data of their own: names below a registered domain that are created and retired by software, or individual networks and addresses inside an allocation that are assigned at machine speed. Registries do not hold this detail, and for number resources the aggregation conventions exist precisely to keep it out of the central database. A holder can serve it instead from a conformant RDAP service, straight from the system where it is maintained. Today that service cannot be found in-band. A client walking down from the bootstrap has no sign that a more specific answer exists, or where.¶
Reverse DNS works this way: the registry keeps the covering delegation and points to the holder's name servers for the space below it. This document applies the same idea to registration data. The registry keeps the covering object and points, and the holder answers for what is inside it.¶
Two things are needed, and they are kept apart on purpose. Transport: a client that asks the registry about a subordinate resource should reach the holder's record without changing anything on its side, which an ordinary HTTP redirect already does. Discovery: a client should be able to see that a delegation exists, and where, before it crosses from data the registry maintains to data the holder asserts. Redirects alone give the first and not the second. This document requires the redirect and makes the discovery link additive on top of it.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A registry operator learns of a holder-designated service only because the holder tells it. How that happens is a matter for the registry operator and is out of scope here (Section 9). Everything in this section applies only to covering objects for which a holder has done so.¶
When a registry operator's server receives a lookup for a subordinate resource and the most specific object it holds is a covering object with a holder-designated service, it MUST respond with an HTTP redirect (Section 5.2 of [RFC7480]) whose Location is the holder-designated service's base URL with the request's lookup path, relative to the registry operator's own base URL, appended. Query parameters are not copied. The one exception is a request carrying "noRedirects0" that the server chooses to honour, described below. An unchanged client therefore lands on the holder's record exactly as it would land on any other redirected record today.¶
This is the backwards-compatible part of the design and it is not optional. Without it, the most specific record would be reachable only by clients that understand the links in Section 3.2.¶
A lookup that names the covering object itself, for example the exact covering network, is never redirected. The registry operator answers it with the covering object. This is what lets the holder's service link back to the covering object without creating a loop (Section 4).¶
A client that wants the registry's own covering object can ask for it with the "noRedirects0" extension [I-D.ietf-regext-rdap-referrals]. A server that honours the request returns the covering object, carrying any links described in Section 3.2. A server is not obliged to honour it, and the client must still be able to follow a redirect.¶
In addition to the redirect, a registry operator's server MAY include in the covering object an "rdap-base-down" link (Section 5) whose target is the base URL of the holder-designated service. A server that does so SHOULD include it in responses to both lookups and searches, for domain and number objects alike.¶
This link is discovery, not transport. It tells a client that a delegation exists below the covering object and where the holder's service is, so the client can query that service for subordinate resources, or enumerate them where the service supports searches, and can decide for itself to cross from registry-maintained data to holder-asserted data. A client that ignores the link loses nothing it has today.¶
The following elided example shows an IPv6 allocation with a holder-designated service:¶
{
"objectClassName": "ip network",
"handle": "2001:db8::/32",
"startAddress": "2001:db8::",
"endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff",
"ipVersion": "v6",
"links": [
{
"value": "https://rir.example/ip/2001:db8::/32",
"rel": "self",
"href": "https://rir.example/ip/2001:db8::/32",
"type": "application/rdap+json"
},
{
"value": "https://rir.example/ip/2001:db8::/32",
"rel": "rdap-base-down",
"href": "https://rdap.holder.example/"
}
]
}
¶
A holder-designated service is an ordinary RDAP service. It answers for subordinate resources of the covering object and for nothing else.¶
Because the registry operator redirects every lookup below the covering object, the holder's service will receive lookups for resources it holds nothing more specific for. It MUST NOT invent registration data for them, and it MUST NOT redirect the client back to the registry operator, which would be a redirect loop as defined in [I-D.ietf-regext-rdap-extensions]. Instead:¶
Each object it returns for a subordinate resource SHOULD carry an "rdap-related-up" link [I-D.ietf-regext-rdap-referrals] whose target is the lookup URL of the covering object itself at the registry operator, so the hierarchy can be walked back up across the authority boundary. That target MUST NOT be a lookup for the subordinate resource at the registry operator, which would redirect straight back and form a loop. The service MAY also carry an "rdap-base-up" link to the registry operator's base URL.¶
The holder-designated service can find the registry operator's base URL for those links in the bootstrap registries [RFC9224], by resolving the covering resource, and builds the covering object's lookup URL from it. The links then stay correct if the registry operator moves its service. Where the bootstrap is not specific enough, the registry operator can give the base URL to the holder when the designation is set up. Neither way needs a private arrangement to keep the links current.¶
Each such object SHOULD also carry a notice (Section 4.3 of [RFC9083]) stating that its data is published by the holder, for resources subordinate to the covering object, so that a person reading a response that arrived through a redirect can see whose data it is.¶
The "rdap-related" relations of [I-D.ietf-regext-rdap-referrals] point at an object. The relations in this section point at a service. They mirror the four relations of [RFC9910], so the pattern reads the same, and the only thing that changes is the kind of target.¶
Section 5.2 of [I-D.ietf-regext-rdap-extensions] requires an extension to state any processing a client must apply to a link before using it. For every relation in this family:¶
The directional relations make the direction explicit where the link is used. This document treats the [RFC9910] relations as navigation within the data of a single service and does not change them. A link that crosses to another authority uses one of the relations in this section, or one of the "rdap-related" relations when the target is an object.¶
Delegation can nest. A holder may itself delegate part of its space to a customer that runs its own RDAP service, and for names a registry may run further registries below its top level, under which a registered domain designates its own service. Each level that holds a covering object states its own boundary on that object, much as each zone in the DNS states its own delegation. A client reaches the right service by following those boundaries level by level, without falling back on heuristics such as a public suffix list to guess where they are. In the common case of one covering object and one holder-designated service, it is one hop.¶
The loop rules of [I-D.ietf-regext-rdap-extensions] apply to the redirects and links in this document: servers MUST NOT issue responses that cause redirect or referral loops, and clients MUST stop processing a query when they detect one.¶
Clients MUST also bound the number of holder-designated referrals they follow while resolving a single query. The bound should allow for the levels of nesting a client expects to cross (Section 6).¶
Because "rdap-base-down" names a kind of target and not a role, it fits wherever one RDAP response needs to point a client at another RDAP service holding more specific or delegated data:¶
The "rdap-bootstrap" relation of [I-D.ietf-regext-rdap-referrals] complements these. It reaches the service that can be derived from the bootstrap registries; "rdap-base-down" reaches a service that, by construction, cannot be, because the data it serves is not in the bootstrap.¶
How a holder designates a service to the registry operator is out of scope. It could be a portal, an attribute on the registered object, or a future EPP extension for domain registrations; a registry operator might also show the designation in its other query interfaces, so that users who do not use RDAP can see where the detail is kept.¶
The mandatory redirect changes one failure mode. Before designation, a lookup for an address inside the covering network returns the covering object, and a lookup for a name below a registered domain returns not found. After designation, the same lookup is redirected, and if the holder-designated service is down the client gets an error instead. Broken referrals are a known problem in deployed registration services, and they are worse than none. A registry operator therefore:¶
A client that gets an error after a redirect can ask again with "noRedirects0", and a server that honours it returns the covering object.¶
Data from a holder-designated service is asserted by the holder, not maintained by the registry operator. For registration data used in abuse handling and law enforcement, that difference matters. A client that follows the redirect may not notice that it crossed an authority boundary; the notice in Section 4 and the "rdap-base-down" link on the covering object are how the boundary stays visible. Clients that present such data SHOULD distinguish it from registry-maintained data.¶
A holder-designated service can only speak for subordinate resources. Clients MUST NOT treat it as a source for any other resource. A client SHOULD check that an object received from it lies within the covering object, for example that the address range is contained in the covering network or that the name is below the registered domain, and discard anything that does not.¶
Queries for subordinate resources reach the holder's infrastructure, so the holder can see interest in its own resources, much as the operator of a DNS zone sees queries for it. A client that does not want this can ask for "noRedirects0", which a server may or may not honour, and need not follow the links.¶
The security considerations of [RFC7480], [RFC7481], and [I-D.ietf-regext-rdap-referrals] apply.¶
IANA is requested to register the following values in the "Link Relation Types" registry [RFC8288]. These registrations are a holding position (Section 1.1). If the working group moves this family to [I-D.ietf-regext-rdap-extensions], they move with it and are removed from this document.¶
This section is to be removed before publishing as an RFC.¶
A holder-designated service is in production at rdap.whisper.online. It is a purpose-built implementation serving per-name and per-address objects for subordinate names and IPv6 /128 assignments that are created and retired programmatically inside 2a04:2a01::/32, announced by AS219419. Its responses already link back to the RIPE NCC. Today that link uses "rdap-up" and targets the lookup for the address itself; it will change to "rdap-related-up" with the covering object's own lookup URL as its target, as Section 4 requires, before any registry-side redirect is in place.¶
The registry side does not exist yet. A proposal for the RIPE Database to support a holder-designated service for number resources was raised on the RIPE Database Working Group list in July 2026, and has been submitted for that working group's session at RIPE 93 (Sofia, 29 October 2026).¶
This section is to be removed before publishing as an RFC.¶
This section is to be removed before publishing as an RFC.¶
Jasdip Singh suggested naming the relation for the base URL it targets, then splitting it by direction, and reviewed the definitions on the list. Tom Harrison held the design to backwards compatibility, which is why the registry still redirects. Andy Newton saw that an object pointer and a service pointer are different things, which is what turned one relation into two families. Pawel Kowalik raised the multi-level case for names and the question of how a registry learns of a designation. Gavin Brown and Andy Newton wrote the redirect mechanism this builds on. On the RIPE Database Working Group list, Leo Vegoda asked why a holder would not simply synchronise its data into the registry, and Radu Anghel asked about lifetimes, availability requirements and broken referrals; the operational considerations reflect that discussion.¶