| Internet-Draft | RDAP Subordinate Referrals | July 2026 |
| Ranjbar | Expires 22 January 2027 | [Page] |
Registration Data Access Protocol (RDAP) queries can be resolved from the IANA bootstrap registries down to the most specific object held by a registry operator's RDAP service. Where the holder of a registered resource maintains registration data for resources subordinate to it, such as DNS names below a registered domain or more-specific networks below an address allocation, and operates a conformant RDAP service for that data, there is currently no discoverable referral from the registry's response to the holder's service. This document describes an optional, holder-designated referral for subordinate resources, carried by a pair of directional RDAP link relations, "rdap-base-down" and "rdap-base-up", whose targets are the base URL of a downstream RDAP service and the base URL of the covering registry service, respectively. The holder-designated subordinate referral is the primary application, but the same relations serve related base-URL discovery needs, including delegated and hybrid RPKI referrals. It is written as input to draft-ietf-regext-rdap-referrals and its content may be merged into that document.¶
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 22 January 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] allows a client to discover the authoritative server for a resource using the IANA bootstrap registries [RFC9224] and to navigate object hierarchies, including with the search and link relations defined in [RFC9910]. In current deployments this walk terminates at the most specific object the registry operator's database holds: the registered domain object at a domain registry or registrar, or the covering allocation or aggregated assignment object at a Regional Internet Registry (RIR).¶
Resource holders increasingly maintain large, dynamic sets of subordinate resources with meaningful registration data of their own. Examples include DNS names below a registered domain that are provisioned and retired programmatically, and more-specific networks or individual addresses below an allocation that are assigned at machine speed. Registry databases deliberately do not hold this per-subordinate detail; aggregation conventions exist at RIRs precisely to keep it out of the central database. A holder may instead operate a conformant RDAP service that serves this data directly from the system where it is maintained.¶
Today such a holder-operated service is undiscoverable: a client walking from the bootstrap has no indication that a more specific answer exists or where to find it. This document describes an optional referral from the registry operator's RDAP response to a holder-designated RDAP server, scoped strictly to resources subordinate to the referring object. Nothing is mandatory on either side beyond the redirection a registry already performs: a holder that designates no server, and a client that follows no referral, observe exactly today's behaviour.¶
The referral is carried by a pair of directional RDAP link relations, "rdap-base-down" and "rdap-base-up" (Section 3), naming the downstream and reverse directions explicitly so that the "rdap-up" relation of [RFC9910] is left unchanged. Their targets are, respectively, the base URL of a downstream RDAP service and the base URL of the covering registry service. Holder-designated subordinate referral is the primary application and the focus of this document, but the same relations address related base-URL discovery needs; Section 4 describes several.¶
This document is written as input to [I-D.ietf-regext-rdap-referrals], which defines the underlying explicit redirect mechanism, and the author's preference is for the substance of this document to be merged into that work rather than progressing independently.¶
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's RDAP server that knows a holder-designated server for a registered resource MAY include, in responses for that resource, a link whose context is the object itself and whose target is the base URL of the holder-designated server. The link SHOULD use the relations and behaviour defined in [I-D.ietf-regext-rdap-referrals] so that a client can either follow the link opportunistically or request an explicit redirect for a subordinate resource.¶
Where the holder has registered such a pointer with the registry, a registry operator's server MUST still redirect a lookup for a subordinate resource to the holder-designated server, so that an unchanged client continues to receive the most-specific record with no change on its side. The "rdap-base-down" link is additive discovery, not a replacement for that redirect: a client that does not recognise the link keeps receiving the most-specific record by redirection exactly as it does today, and a client that does may additionally follow the link to enumerate the delegation and cross the authority boundary deliberately. A client that prefers the registry's own record as well as the holder's can decline the redirect, using a redirect-suppression control of the kind under discussion for [I-D.ietf-regext-rdap-referrals].¶
A registry operator's server SHOULD include this link in both lookup and search responses for the context object, for domain objects and for number resources alike, so that a client following either query type can discover the downstream service by the same means it uses to follow the "up" and "rdap-up" relations today.¶
For example, a lookup or search at a domain registry for example.com may carry an "rdap-base-down" referral to https://rdap.example.com/ designated by the registrant, and a lookup for a name subordinate to example.com is redirected to the corresponding object on that server, unless the client has asked to suppress the redirect. A lookup at an RIR for an allocation may likewise carry a referral for its more-specifics.¶
The referral target MUST be an HTTPS URL. A holder-designated server is a candidate source of registration data only for resources subordinate to the referring object, and clients MUST NOT treat it as authoritative for any other resource.¶
This referral is carried by a pair of dedicated RDAP link relations, "rdap-base-down" and "rdap-base-up", defined and registered by this document (Section 8). The target of an "rdap-base-down" link is the base URL of a downstream RDAP service that holds registration data subordinate to, or otherwise delegated below, the context object; an "rdap-base-up" link is its reverse, carried by an object on the downstream service and pointing to the base URL of the covering registry service. Naming the relations for the base URL they target, and for the direction of the crossing, rather than for the resource-holder role, keeps them reusable for the related cases in Section 4 and leaves the "rdap-up" relation of [RFC9910] unchanged for navigation within a single authority.¶
Because "rdap-base-down" names a downstream RDAP base URL rather than a role, it is useful wherever one RDAP response needs to point a client at another RDAP service that holds more-specific or delegated data. Besides the holder-designated subordinate referral that motivates this document, the following cases share that need:¶
In each case the relation semantics are defined by the link target, a downstream RDAP base URL, and not by the role of either endpoint, so the same relation applies without special-casing.¶
The "rdap-bootstrap" relation defined in [I-D.ietf-regext-rdap-referrals] is complementary to "rdap-base-down" rather than overlapping. "rdap-bootstrap" points to the authoritative service that can be derived from the IANA bootstrap registries [RFC9224]; "rdap-base-down" points to a downstream service that, by construction, cannot be so derived, because the subordinate or delegated data it serves is not present in the bootstrap. Together they give a client both directions: outward to the bootstrap-authoritative service and downward to the holder's own service. This complementarity is a further reason to define both relations in the same document.¶
A holder-designated server SHOULD include, in each response for a subordinate resource, an "rdap-base-up" link whose target is the base URL of the covering registry operator's service, so that the hierarchy remains navigable in both directions. This reverse link crosses the authority boundary from the holder's service back to the registry, which is why it uses "rdap-base-up" rather than the within-authority "up" and "rdap-up" [RFC9910] relations.¶
A holder-designated server can determine the base URL of the registry operator's service, needed for that reverse link, from the IANA RDAP bootstrap registries [RFC9224]: resolving the covering domain or number resource yields the authoritative service for the parent object, and the reverse link stays correct even if the registry operator later changes its service URL. Where bootstrap is not sufficiently granular, the registry operator can supply its base URL to the holder at the time the holder-designated server is configured. In neither case does the holder need a private arrangement with the registry to keep the reverse link correct.¶
Clients MUST bound the number of holder-level referrals they follow for a single query resolution. A single hop from the registry operator's service to a holder-designated server is sufficient for the use cases described here.¶
How a holder communicates its designated server to the registry operator is a matter for that operator (for example a registry or registrar portal, or a future EPP extension for domain registrations) and is out of scope for this document. Registry operators SHOULD validate that a designated server responds with conformant RDAP for the holder's resources before emitting referrals to it.¶
Referrals shift availability for subordinate data to the holder. A holder-designated server that is unreachable affects only the additional, subordinate data it would have served; the registry operator's own responses are unaffected.¶
Data served by a holder-designated server is asserted by the holder, not by the registry operator. Clients presenting such data SHOULD distinguish its provenance from registry-held data. The strict subordination rule in Section 3 prevents a holder from asserting data about resources it does not hold.¶
Because queries for subordinate resources reach the holder's infrastructure, the holder can observe interest in its own resources. This is comparable to the visibility a DNS operator already has for its own zones, but clients with confidentiality requirements can decline to follow referrals.¶
The security considerations of [RFC7480] and [I-D.ietf-regext-rdap-referrals] apply.¶
This document registers the following two relations in the "Link Relation Types" registry maintained under [RFC8288]:¶
If the working group prefers to define these relations in [I-D.ietf-regext-rdap-referrals], or to reconcile "rdap-base-down" with the "rdap-help" relation of [I-D.ietf-regext-rdap-rpki], the registrations can move accordingly.¶
[RFC Editor: please remove this section before publication.]¶
A holder-side implementation is in production operation. The registrant of whisper.online and holder of an IPv6 allocation operates a conformant RDAP service (rdap.whisper.online), a purpose-built implementation rather than an off-the-shelf server, serving per-name and per-address objects for programmatically provisioned subordinate names and IPv6 /128 assignments. Each response already carries a reverse link to the covering registry object, whose base URL is resolved from the IANA bootstrap registries as described in Section 5; that link predates the "rdap-base-up" relation defined here and will be updated to it. The registry-side referral described in this document is the missing hop; a proposal for the number-resource side was posted to the RIPE Database Working Group in July 2026.¶
[RFC Editor: please remove this section before publication.]¶
The number-resource half of this idea was first discussed on the RIPE Database Working Group mailing list, and the author thanks the participants in that thread. Jasdip Singh proposed naming the relation for the base URL it targets, which shaped the "rdap-base" framing and its applicability to RPKI referrals, and later proposed splitting it into the directional "rdap-base-down" and "rdap-base-up" relations so that direction is explicit at the point of use and RFC 9910's "rdap-up" is left unchanged. Tom Harrison pressed the backwards-compatibility case that a registry must continue to redirect for unchanged clients, and corrected the author's reasoning about how HTTP clients handle redirect bodies. Andy Newton provided early guidance. The referral mechanics here deliberately build on the work of Gavin Brown and Andy Newton in [I-D.ietf-regext-rdap-referrals].¶