Whisper Security

kaveh@whisper.security

Applications and Real-Time Registration Protocols Extensions RDAP referral redirect An RDAP query can be followed from the IANA bootstrap registries down to the most specific object a registry operator holds, and no further. When the holder of a registered resource keeps registration data for resources below it, such as names below a registered domain or more-specific networks below an address allocation, and publishes that data from an RDAP service of its own, a client has no in-band way to find that service. This document describes how a registry operator refers clients to such a holder-designated service. The registry redirects lookups for subordinate resources to the holder's service, so an unchanged client receives the most specific record as it would from any other redirect. On top of that, the covering object can advertise the holder's service, so a client that cares can discover the delegation and cross the authority boundary knowingly. The document uses the object relations and the redirect controls of draft-ietf-regext-rdap-referrals, and defines a family of "rdap-base" link relations whose target is the base URL of an RDAP service rather than an object. Discussion of this document takes place on the Registration Protocols Extensions (regext) Working Group mailing list (regext@ietf.org).

Introduction RDAP lets a client find the authoritative service for a resource through the IANA bootstrap registries , and, for Internet number resources, navigate between objects with the link relations of . Where more specific data sits inside the registry system, for example with a National Internet Registry, redirects already carry the client there. Outside that system the walk ends at the most specific object the registry operator holds: the registered domain at a domain registry or registrar, or the covering allocation or aggregated assignment at a Regional Internet Registry (RIR). Below that point, holders increasingly keep registration data of their own: names below a registered domain that are created and retired by software, or individual networks and addresses inside an allocation that are assigned at machine speed. Registries do not hold this detail, and for number resources the aggregation conventions exist precisely to keep it out of the central database. A holder can serve it instead from a conformant RDAP service, straight from the system where it is maintained. Today that service cannot be found in-band. A client walking down from the bootstrap has no sign that a more specific answer exists, or where. Reverse DNS works this way: the registry keeps the covering delegation and points to the holder's name servers for the space below it. This document applies the same idea to registration data. The registry keeps the covering object and points, and the holder answers for what is inside it. Two things are needed, and they are kept apart on purpose. Transport: a client that asks the registry about a subordinate resource should reach the holder's record without changing anything on its side, which an ordinary HTTP redirect already does. Discovery: a client should be able to see that a delegation exists, and where, before it crosses from data the registry maintains to data the holder asserts. Redirects alone give the first and not the second. This document requires the redirect and makes the discovery link additive on top of it.

Relationship to Other Documents defines the "redirects0" extension, through which a client asks a server to redirect it to a related resource, and the "noRedirects0" extension, through which a client asks not to be redirected. It also registers the "rdap-related-up", "rdap-related-down", "rdap-related-top" and "rdap-related-bottom" relations, whose target is an RDAP object. This document uses "noRedirects0" and "rdap-related-up", and redefines nothing. The "noRedirects0" signal is carried in the media type parameter defined in . Discovering a holder-designated service needs a second kind of target: the base URL of an RDAP service, which the client combines with a lookup path, in the way base URLs are used. A redirect cannot carry such a target, because a redirect has to land on an object. This document therefore defines the "rdap-base" family of relations (). The same need appears elsewhere: has to point at the RDAP service of an organisation operating delegated or hybrid RPKI. Because the family is general, it was suggested on the list that it be registered in , which the RPKI work also depends on. Until that is settled, this document carries the registrations as a holding position. If they move, and the matching IANA registrations go with them, and this document keeps only the holder-designated case described in and .

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.

Registry operator:

The operator of the RDAP service that holds the registered resource, such as a domain name registry, a registrar, or an RIR.

Covering object:

The object held by the registry operator for the registered resource: the registered domain, or the allocation or assignment that contains the subordinate resources.

Subordinate resource:

A resource strictly more specific than the covering object: a domain name below the registered domain, or a network or address contained within, and smaller than, the covering network.

Holder-designated service:

An RDAP service operated by or for the holder of the covering object, which the holder has designated to the registry operator to answer for subordinate resources.

Base URL:

A URL to which a client appends an RDAP lookup path to form a query, as defined for the bootstrap registries in . It ends in a "/" character.

Registry Operator Behaviour A registry operator learns of a holder-designated service only because the holder tells it. How that happens is a matter for the registry operator and is out of scope here (). Everything in this section applies only to covering objects for which a holder has done so.

Redirect for Transport When a registry operator's server receives a lookup for a subordinate resource and the most specific object it holds is a covering object with a holder-designated service, it MUST respond with an HTTP redirect () whose Location is the holder-designated service's base URL with the request's lookup path, relative to the registry operator's own base URL, appended. Query parameters are not copied. The one exception is a request carrying "noRedirects0" that the server chooses to honour, described below. An unchanged client therefore lands on the holder's record exactly as it would land on any other redirected record today. This is the backwards-compatible part of the design and it is not optional. Without it, the most specific record would be reachable only by clients that understand the links in . A lookup that names the covering object itself, for example the exact covering network, is never redirected. The registry operator answers it with the covering object. This is what lets the holder's service link back to the covering object without creating a loop (). A client that wants the registry's own covering object can ask for it with the "noRedirects0" extension . A server that honours the request returns the covering object, carrying any links described in . A server is not obliged to honour it, and the client must still be able to follow a redirect.

Advertising the Delegation In addition to the redirect, a registry operator's server MAY include in the covering object an "rdap-base-down" link () whose target is the base URL of the holder-designated service. A server that does so SHOULD include it in responses to both lookups and searches, for domain and number objects alike. This link is discovery, not transport. It tells a client that a delegation exists below the covering object and where the holder's service is, so the client can query that service for subordinate resources, or enumerate them where the service supports searches, and can decide for itself to cross from registry-maintained data to holder-asserted data. A client that ignores the link loses nothing it has today. The following elided example shows an IPv6 allocation with a holder-designated service:

Holder-Designated Service Behaviour A holder-designated service is an ordinary RDAP service. It answers for subordinate resources of the covering object and for nothing else. Because the registry operator redirects every lookup below the covering object, the holder's service will receive lookups for resources it holds nothing more specific for. It MUST NOT invent registration data for them, and it MUST NOT redirect the client back to the registry operator, which would be a redirect loop as defined in . Instead:

• For an IP network lookup, it SHOULD return its own object for the covering network, of which it is the holder, carrying the "rdap-related-up" link and the notice described below. An unchanged client then still receives an object for the covering network, as it did before the designation, together with a pointer to the registry operator's record for it.
• For a domain lookup, it returns a 404 (Not Found) response, as the registry operator would have for a name it does not hold.

Each object it returns for a subordinate resource SHOULD carry an "rdap-related-up" link whose target is the lookup URL of the covering object itself at the registry operator, so the hierarchy can be walked back up across the authority boundary. That target MUST NOT be a lookup for the subordinate resource at the registry operator, which would redirect straight back and form a loop. The service MAY also carry an "rdap-base-up" link to the registry operator's base URL. The holder-designated service can find the registry operator's base URL for those links in the bootstrap registries , by resolving the covering resource, and builds the covering object's lookup URL from it. The links then stay correct if the registry operator moves its service. Where the bootstrap is not specific enough, the registry operator can give the base URL to the holder when the designation is set up. Neither way needs a private arrangement to keep the links current. Each such object SHOULD also carry a notice () stating that its data is published by the holder, for resources subordinate to the covering object, so that a person reading a response that arrived through a redirect can see whose data it is.

The rdap-base Link Relations The "rdap-related" relations of point at an object. The relations in this section point at a service. They mirror the four relations of , so the pattern reads the same, and the only thing that changes is the kind of target.

Processing Section 5.2 of requires an extension to state any processing a client must apply to a link before using it. For every relation in this family:

• The target is a base URL. A client MUST NOT dereference it expecting an object. To use it, the client appends an RDAP lookup path to the target, exactly as it would with a base URL taken from the bootstrap registries .
• Queries built in this way return responses of the "application/rdap+json" media type , which is how this document states the media type that Section 5.2 of asks for. The media type describes those responses and not the base URL itself, so a link in this family SHOULD NOT include a "type" member, which would invite a client to fetch the target directly.
• The target MUST use the "https" scheme.

Definitions

rdap-base

The base URL of the RDAP service for the context object.

rdap-base-up

The base URL of an RDAP service from which the RDAP parent of the context object can be reached.

rdap-base-down

The base URL of an RDAP service that holds RDAP child objects of the context object, including objects delegated below the context object that the covering service does not hold itself.

rdap-base-top

The base URL of an RDAP service from which the topmost RDAP parent of the context object can be reached.

rdap-base-bottom

The base URL of an RDAP service that holds the RDAP child objects of the context object that do not themselves have child objects.

The directional relations make the direction explicit where the link is used. This document treats the relations as navigation within the data of a single service and does not change them. A link that crosses to another authority uses one of the relations in this section, or one of the "rdap-related" relations when the target is an object.

Nested Delegation Delegation can nest. A holder may itself delegate part of its space to a customer that runs its own RDAP service, and for names a registry may run further registries below its top level, under which a registered domain designates its own service. Each level that holds a covering object states its own boundary on that object, much as each zone in the DNS states its own delegation. A client reaches the right service by following those boundaries level by level, without falling back on heuristics such as a public suffix list to guess where they are. In the common case of one covering object and one holder-designated service, it is one hop.

Loops and Hop Limits The loop rules of apply to the redirects and links in this document: servers MUST NOT issue responses that cause redirect or referral loops, and clients MUST stop processing a query when they detect one. Clients MUST also bound the number of holder-designated referrals they follow while resolving a single query. The bound should allow for the levels of nesting a client expects to cross ().

Applicability Beyond Holder-Designated Services Because "rdap-base-down" names a kind of target and not a role, it fits wherever one RDAP response needs to point a client at another RDAP service holding more specific or delegated data:

• Delegated and hybrid RPKI. needs a client to find the RDAP service of an organisation that operates delegated or hybrid RPKI for a resource, and currently uses an "rdap-help" relation for it. "rdap-base-down" carries the same information directly.
• Replacing referral whois. Where holders today publish detail below an allocation through RWhois , the registry's RDAP response can point to the holder's RDAP service with "rdap-base-down" instead.

The "rdap-bootstrap" relation of complements these. It reaches the service that can be derived from the bootstrap registries; "rdap-base-down" reaches a service that, by construction, cannot be, because the data it serves is not in the bootstrap.

Operational Considerations How a holder designates a service to the registry operator is out of scope. It could be a portal, an attribute on the registered object, or a future EPP extension for domain registrations; a registry operator might also show the designation in its other query interfaces, so that users who do not use RDAP can see where the detail is kept. The mandatory redirect changes one failure mode. Before designation, a lookup for an address inside the covering network returns the covering object, and a lookup for a name below a registered domain returns not found. After designation, the same lookup is redirected, and if the holder-designated service is down the client gets an error instead. Broken referrals are a known problem in deployed registration services, and they are worse than none. A registry operator therefore:

• SHOULD check, before it starts redirecting, that the designated service answers conformant RDAP for the holder's subordinate resources;
• SHOULD keep checking afterwards, and withdraw the designation of a service that fails, so that it stops redirecting and advertising it and clients fall back to the covering object as before; and
• MAY set availability expectations for holder-designated services as a condition of designation, and MAY give clients a way to report a failing referral, including one that answers some clients and not others.

A client that gets an error after a redirect can ask again with "noRedirects0", and a server that honours it returns the covering object.

Security Considerations Data from a holder-designated service is asserted by the holder, not maintained by the registry operator. For registration data used in abuse handling and law enforcement, that difference matters. A client that follows the redirect may not notice that it crossed an authority boundary; the notice in and the "rdap-base-down" link on the covering object are how the boundary stays visible. Clients that present such data SHOULD distinguish it from registry-maintained data. A holder-designated service can only speak for subordinate resources. Clients MUST NOT treat it as a source for any other resource. A client SHOULD check that an object received from it lies within the covering object, for example that the address range is contained in the covering network or that the name is below the registered domain, and discard anything that does not. Queries for subordinate resources reach the holder's infrastructure, so the holder can see interest in its own resources, much as the operator of a DNS zone sees queries for it. A client that does not want this can ask for "noRedirects0", which a server may or may not honour, and need not follow the links. The security considerations of , , and apply.

IANA Considerations IANA is requested to register the following values in the "Link Relation Types" registry . These registrations are a holding position (). If the working group moves this family to , they move with it and are removed from this document.

Relation Name: rdap-base

Description: Refers to the base URL of the RDAP service for the context object.
Note: The target is a base URL against which the client constructs queries; it is not dereferenced to obtain an object (see ).
Reference: This document

Relation Name: rdap-base-up

Description: Refers to the base URL of an RDAP service from which the RDAP parent of the context object can be reached.
Note: The target is a base URL against which the client constructs queries; it is not dereferenced to obtain an object (see ).
Reference: This document

Relation Name: rdap-base-down

Description: Refers to the base URL of an RDAP service that holds RDAP child objects of the context object, including objects delegated below the context object that the covering service does not hold itself.
Note: The target is a base URL against which the client constructs queries; it is not dereferenced to obtain an object (see ).
Reference: This document

Relation Name: rdap-base-top

Description: Refers to the base URL of an RDAP service from which the topmost RDAP parent of the context object can be reached.
Note: The target is a base URL against which the client constructs queries; it is not dereferenced to obtain an object (see ).
Reference: This document

Relation Name: rdap-base-bottom

Description: Refers to the base URL of an RDAP service that holds the RDAP child objects of the context object that do not themselves have child objects.
Note: The target is a base URL against which the client constructs queries; it is not dereferenced to obtain an object (see ).
Reference: This document

Implementation Status A holder-designated service is in production at rdap.whisper.online. It is a purpose-built implementation serving per-name and per-address objects for subordinate names and IPv6 /128 assignments that are created and retired programmatically inside 2a04:2a01::/32, announced by AS219419. Its responses already link back to the RIPE NCC. Today that link uses "rdap-up" and targets the lookup for the address itself; it will change to "rdap-related-up" with the covering object's own lookup URL as its target, as requires, before any registry-side redirect is in place. The registry side does not exist yet. A proposal for the RIPE Database to support a holder-designated service for number resources was raised on the RIPE Database Working Group list in July 2026, and has been submitted for that working group's session at RIPE 93 (Sofia, 29 October 2026).

Open Issues

• Where the "rdap-base" family is registered: here as a holding position, or in , as suggested on the list.
• Whether the behaviour in this document should be signalled with an RDAP extension identifier in "rdapConformance", so that a client can tell a server that advertises holder-designated services from one that does not.
• How "rdap-related-down" applies to explicit redirects for a covering object whose child objects are held by a holder-designated service. For transport, the ordinary redirect in already reaches the subordinate object, so this document does not specify it.
• Whether "rdap-base-top" and "rdap-base-bottom" are needed now, or only the directional pair and the undirected form.
• For an address the holder holds nothing more specific for, this document has the holder's service answer with its own object for the covering network rather than redirect back, because defines any redirect back to a server already visited as a loop, even when the second request names a different resource. If the working group would rather allow that one bounded return to the covering object, the registry's own record could be served instead.

Changes from -01

• Rebuilt the document on two families of relations with two kinds of target, as agreed on the list in September 2026: the "rdap-related" relations, which point at an object and are now in , and the "rdap-base" relations, which point at a service.
• Used "rdap-related-up" for the holder's link back to the covering object, in place of the "rdap-base-up" back link of -01, and required its target to be the covering object's own lookup URL so the link cannot loop.
• Specified what the holder's service returns for lookups it holds nothing more specific for: its own object for the covering network for IP lookups, so an unchanged client still receives an object for the covering network, and not found for names, as today. It never redirects back to the registry operator, which would be a loop.
• Stated that the registry operator answers a lookup for the covering object itself directly, so the back link cannot loop.
• Removed the -01 example of explicit redirects with a subordinate lookup path.
• Restored, from -01, that clients must not treat a holder-designated service as a source for resources outside the covering object.
• Moved and to the normative references, and added .
• Left explicit redirects with "rdap-related-down" as an open issue rather than specifying them.
• Replaced the generic redirect-suppression control with the "noRedirects0" extension of .
• Expanded the "rdap-base" family from two relations to five, in line with the four relations of plus the undirected form, and stated the processing rules once for the whole family, as Section 5.2 of requires. Defined the undirected "rdap-base" as the base URL of the service for the context object, without the sentence about authority, at Jasdip Singh's suggestion; crossing an authority boundary is what the directional relations are for.
• With the object relations now in , dropped the -01 aim of merging this document into it. The "rdap-base" registrations are carried here as a holding position and may move to , leaving this document as the holder-designated case only.
• Kept advertising the "rdap-base-down" link as a MAY on top of the mandatory redirect, as agreed on the list in July.
• Added an operational section on the failure mode the mandatory redirect introduces, and on checking, withdrawing and reporting broken referrals.
• Added a section on nested delegation for both names and number resources, a notice identifying holder-published data, and a client check that objects from a holder-designated service lie within the covering object.
• Added an Open Issues section.
• Changed the title to describe the document as it now is.

References Normative References Informative References

Acknowledgements Jasdip Singh suggested naming the relation for the base URL it targets, then splitting it by direction, and reviewed the definitions on the list. Tom Harrison held the design to backwards compatibility, which is why the registry still redirects. Andy Newton saw that an object pointer and a service pointer are different things, which is what turned one relation into two families. Pawel Kowalik raised the multi-level case for names and the question of how a registry learns of a designation. Gavin Brown and Andy Newton wrote the redirect mechanism this builds on. On the RIPE Database Working Group list, Leo Vegoda asked why a holder would not simply synchronise its data into the registry, and Radu Anghel asked about lifetimes, availability requirements and broken referrals; the operational considerations reflect that discussion.