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

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: 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 , 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.

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. 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 . This document defers the choice between a dedicated relation and reuse of existing relations to working group discussion.

Hierarchy Consistency and Loop Avoidance A holder-designated server SHOULD include, in each response for a subordinate resource, a link with relation "up" (for domain objects) or "rdap-up" (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.

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 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 . If existing relations and the extension machinery of that document are reused instead, this document makes no new requests of IANA.

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

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. The referral mechanics here deliberately build on the work of Gavin Brown and Andy Newton in .