Whisper Security

kaveh@whisper.security

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.

Introduction RDAP allows a client to discover the authoritative server for a resource using the IANA bootstrap registries and to navigate object hierarchies, including with the search and link relations defined in . 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" (), naming the downstream and reverse directions explicitly so that the "rdap-up" relation of 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; describes several. This document is written as input to , 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.

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Subordinate resource:

A resource wholly contained within a registered resource: a DNS name below a registered domain name, or a network or address contained within a registered or allocated network.

Holder-designated server:

An RDAP server operated by or for the holder of a registered resource, designated by the holder to answer queries for subordinate resources of that registered resource.

Downstream RDAP service:

An RDAP service, distinct from the one returning a response, that holds registration data subordinate to, or otherwise delegated below, the context object.

Referral to a Holder-Designated Server 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 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 . 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 (). 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 and leaves the "rdap-up" relation of unchanged for navigation within a single authority.

Applicability Beyond Subordinate Referrals 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:

• Delegated and hybrid RPKI: an RDAP response for a number resource can point to the RDAP service of a downstream organisation that operates delegated or hybrid RPKI for that resource. identifies the same base-URL discovery need and addresses it with an "rdap-help" relation; a single general "rdap-base-down" relation could serve both, and this document invites alignment with that work.
• Modernising RWhois and SWIP: as operators replace holder-side RWhois with RDAP, a registry response for a number resource can carry an "rdap-base-down" link to the holder's RDAP service in place of the legacy referral.

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 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 ; "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.

Hierarchy Consistency and Loop Avoidance 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" 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 : 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.

Operational Considerations 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.

Security Considerations 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 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 and apply.

IANA Considerations This document registers the following two relations in the "Link Relation Types" registry maintained under :

Relation Name:

rdap-base-down

Description:

Refers from an RDAP object to the base URL of a downstream RDAP service that holds registration data subordinate to, or otherwise delegated below, the context object.

Reference:

This document

Relation Name:

rdap-base-up

Description:

Refers from an RDAP object on a downstream RDAP service to the base URL of the covering registry RDAP service from which the context object's parent can be reached. It does not alter the semantics of the "rdap-up" relation of , which remains for navigation within a single authority.

Reference:

This document

If the working group prefers to define these relations in , or to reconcile "rdap-base-down" with the "rdap-help" relation of , the registrations can move accordingly.

Implementation Status [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 ; 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.

Changes from -00 [RFC Editor: please remove this section before publication.]

• Introduced the "rdap-base-down" and "rdap-base-up" link relations as the general, directional carriers for the referral, replacing the placeholder "rdap-resource-holder" name, and reframed the holder-designated subordinate referral as their primary application. This follows two suggestions by Jasdip Singh: first that the relation be named for its target, the base URL of an RDAP service, and then that it be split into explicit downstream and upstream directions so that the "rdap-up" relation of is left unchanged.
• Stated that a registry operator's server MUST still redirect a lookup for a subordinate resource to the holder-designated server, so that an unchanged client keeps receiving the most-specific record; the relation is additive discovery on top of that redirect, not a replacement for it.
• Narrowed the applicability to the off-bootstrap, holder-run-server case, and removed the in-system Regional-to-National Internet Registry (RIR-to-NIR) referral case, which is served by existing bootstrap and redirection and needs no new relation.
• Added describing use beyond subordinate referrals: delegated and hybrid RPKI (relating to the "rdap-help" relation of ) and RWhois/SWIP modernisation.
• Specified that the registry SHOULD carry the relation in both lookup and search responses, for domains and number resources.
• Described how a holder-designated server discovers the registry's base URL for the reverse link, via the IANA bootstrap registries.
• Registered "rdap-base-down" and "rdap-base-up" in the IANA Link Relation Types registry.
• Noted that "rdap-base-down" is complementary to the "rdap-bootstrap" relation being defined in (bootstrap-derivable versus downstream-delegated), reinforcing the case for defining both in that document.

References Normative References Informative References

Acknowledgements 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 .