| Internet-Draft | RDAP Subordinate Referrals | July 2026 |
| Ranjbar | Expires 7 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, building on the explicit redirect mechanism defined for RDAP. 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 7 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: a holder that designates no server, and a client that follows no referral, observe exactly today's behaviour.¶
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.¶
For example, a lookup at a domain registry for example.com may carry a referral to https://rdap.example.com/ designated by the registrant, and a lookup for a name subordinate to example.com may, where the server implements explicit redirects, be redirected to the corresponding object on that server. 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.¶
A dedicated link relation registered with IANA, for example "rdap-resource-holder", may be the cleanest carrier for this referral, mirroring the approach taken for the relations in [RFC9910]. This document defers the choice between a dedicated relation and reuse of existing relations to working group discussion.¶
A holder-designated server SHOULD include, in each response for a subordinate resource, a link with relation "up" (for domain objects) or "rdap-up" [RFC9910] (for number resources) whose target is the corresponding registered object at the registry operator's service, so that the hierarchy remains navigable in both directions.¶
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.¶
If the working group prefers a dedicated link relation for holder referrals (for example "rdap-resource-holder"), that relation would be registered in the IANA Link Relations registry, which requires a specification; the registration could live in this document or in [I-D.ietf-regext-rdap-referrals]. If existing relations and the extension machinery of that document are reused instead, this document makes no new requests of IANA.¶
[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) serving per-name and per-address objects for programmatically provisioned subordinate names and IPv6 /128 assignments, each response carrying an up link to the corresponding parent object at the registry. 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.¶
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. The referral mechanics here deliberately build on the work of Gavin Brown and Andy Newton in [I-D.ietf-regext-rdap-referrals].¶