Redirecting RDAP Queries to Holder-Designated Servers for Subordinate Resources
draft-ranjbar-regext-rdap-subordinate-referrals-01

Network Working Group                                         K. Ranjbar
Internet-Draft                                          Whisper Security
Intended status: Standards Track                            21 July 2026
Expires: 22 January 2027

 Redirecting RDAP Queries to Holder-Designated Servers for Subordinate
                               Resources
           draft-ranjbar-regext-rdap-subordinate-referrals-01

Abstract

   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.

Status of This Memo

   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.

Ranjbar                  Expires 22 January 2027                [Page 1]
Internet-Draft         RDAP Subordinate Referrals              July 2026

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Referral to a Holder-Designated Server  . . . . . . . . . . .   4
   4.  Applicability Beyond Subordinate Referrals  . . . . . . . . .   5
   5.  Hierarchy Consistency and Loop Avoidance  . . . . . . . . . .   6
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   10. Changes from -00  . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   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

Ranjbar                  Expires 22 January 2027                [Page 2]
Internet-Draft         RDAP Subordinate Referrals              July 2026

   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.

2.  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 [RFC2119] [RFC8174] 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

Ranjbar                  Expires 22 January 2027                [Page 3]
Internet-Draft         RDAP Subordinate Referrals              July 2026

      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.

3.  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
   [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.

Ranjbar                  Expires 22 January 2027                [Page 4]
Internet-Draft         RDAP Subordinate Referrals              July 2026

   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.

4.  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.
      [I-D.ietf-regext-rdap-rpki] 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 [RFC2167] 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
   [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

Ranjbar                  Expires 22 January 2027                [Page 5]
Internet-Draft         RDAP Subordinate Referrals              July 2026

   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.

5.  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" [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.

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

Ranjbar                  Expires 22 January 2027                [Page 6]
Internet-Draft         RDAP Subordinate Referrals              July 2026

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

8.  IANA Considerations

   This document registers the following two relations in the "Link
   Relation Types" registry maintained under [RFC8288]:

   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 [RFC9910], which remains
      for navigation within a single authority.

   Reference:  This document

   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.

Ranjbar                  Expires 22 January 2027                [Page 7]
Internet-Draft         RDAP Subordinate Referrals              July 2026

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

10.  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 [RFC9910] 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 Section 4 describing use beyond subordinate referrals:
      delegated and hybrid RPKI (relating to the "rdap-help" relation of
      [I-D.ietf-regext-rdap-rpki]) and RWhois/SWIP modernisation.

Ranjbar                  Expires 22 January 2027                [Page 8]
Internet-Draft         RDAP Subordinate Referrals              July 2026

   *  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
      [I-D.ietf-regext-rdap-referrals] (bootstrap-derivable versus
      downstream-delegated), reinforcing the case for defining both in
      that document.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/info/rfc8288>.

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7480, DOI 10.17487/RFC7480, March 2015,
              <https://www.rfc-editor.org/info/rfc7480>.

   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", STD 95, RFC 9082,
              DOI 10.17487/RFC9082, June 2021,
              <https://www.rfc-editor.org/info/rfc9082>.

   [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 9083, DOI 10.17487/RFC9083, June 2021,
              <https://www.rfc-editor.org/info/rfc9083>.

Ranjbar                  Expires 22 January 2027                [Page 9]
Internet-Draft         RDAP Subordinate Referrals              July 2026

   [RFC9910]  Harrison, T. and J. Singh, "Registration Data Access
              Protocol (RDAP) Regional Internet Registry (RIR) Search",
              RFC 9910, DOI 10.17487/RFC9910, January 2026,
              <https://www.rfc-editor.org/info/rfc9910>.

   [I-D.ietf-regext-rdap-referrals]
              Brown, G. and A. Newton, "Explicit RDAP Redirects", Work
              in Progress, Internet-Draft, draft-ietf-regext-rdap-
              referrals-04, 1 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-regext-
              rdap-referrals-04>.

11.2.  Informative References

   [RFC9224]  Blanchet, M., "Finding the Authoritative Registration Data
              Access Protocol (RDAP) Service", STD 95, RFC 9224,
              DOI 10.17487/RFC9224, March 2022,
              <https://www.rfc-editor.org/info/rfc9224>.

   [RFC2167]  Williamson, S., Kosters, M., Blacka, D., Singh, J., and K.
              Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
              RFC 2167, DOI 10.17487/RFC2167, June 1997,
              <https://www.rfc-editor.org/info/rfc2167>.

   [I-D.ietf-regext-rdap-rpki]
              Singh, J. and A. Newton, "Registration Data Access
              Protocol (RDAP) Extension for Resource Public Key
              Infrastructure (RPKI) Registration Data", Work in
              Progress, Internet-Draft, draft-ietf-regext-rdap-rpki-04,
              12 June 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-regext-rdap-rpki-04>.

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
   [I-D.ietf-regext-rdap-referrals].

Ranjbar                  Expires 22 January 2027               [Page 10]
Internet-Draft         RDAP Subordinate Referrals              July 2026

Author's Address

   Kaveh Ranjbar
   Whisper Security
   Email: kaveh@whisper.security

Ranjbar                  Expires 22 January 2027               [Page 11]