Summary

  • draft-ranjbar-regext-rdap-subordinate-referrals-01 proposes directional links and redirects from a registry-held object to an RDAP service designated by its holder for subordinate names, networks or addresses.
  • The downstream data is asserted by the holder, not by the registry operator. Strict subordination, a reverse link and a one-hop limit bound where the referral can speak, while the holder gains visibility into queries that reach it.
  • RDAP clients should preserve an authority seam: display the registry’s covering-object assertion and the holder’s subordinate assertion as separate layers, together with the designation, redirect, retrieval, privacy and fallback evidence that connects them.

The normal RDAP path has a reassuring shape. A client starts with IANA bootstrap information, reaches the service responsible for a top-level domain or number-resource range, and asks for the most specific record that service holds. The chain feels authoritative because each step narrows the question inside a recognized registration hierarchy.

That chain also has a deliberate stopping point. A domain registry may hold the registered domain but not every programmatically created name beneath it. An RIR may hold a covering allocation or aggregated assignment but not every more-specific network or individual address assigned inside it. The missing detail is not necessarily an error. Keeping volatile subordinate data out of a central registry can be an intentional division of responsibility.

The new individual draft tries to make the next source discoverable. A resource holder that maintains subordinate data could designate an RDAP server operated by it or on its behalf. The registry operator’s response could point down to that service. The holder’s response could point back up to the covering registry service. A client would gain a route to useful detail without forcing the central registry to ingest a fast-changing subordinate database.

The engineering gain is clear. The governance cost appears when an interface removes the seam.

Direction is not inheritance of authority

Revision 01 names two proposed link relations. rdap-base-down points from an RDAP object to the base URL of a downstream service holding subordinate or delegated data. rdap-base-up points back from that downstream service to the base URL of the covering registry service. The names describe a direction across services, not a promotion of the downstream operator into a registry.

The draft makes the limit explicit. A holder-designated server is a candidate source only for resources wholly subordinate to the referring object. Its target must use HTTPS. Clients must not treat it as authoritative for anything outside that boundary. The reverse link preserves a route to the parent authority, and clients must bound the number of holder-level referrals they follow. One such hop is sufficient for the use cases described.

Those rules stop one holder from claiming a sibling prefix, a parent allocation or an unrelated domain through the same referral. They do not prove that every subordinate assertion is correct. Authority over a bounded namespace is still an assertion made by the holder. The registry operator’s act is narrower: it records or emits the designation and may check that the target behaves as conformant RDAP for the holder’s resources.

A referral therefore conveys two propositions, not one. The registry says, in effect, “this is the service this holder designated for data beneath this object.” The holder then says, “this is the subordinate record I maintain.” A client that labels the combined result simply “registry data” turns the first proposition into an endorsement of the second.

Backward compatibility can make the crossing invisible

The proposal is designed not to strand older clients. When a holder pointer is registered, the registry server would still redirect a subordinate lookup to the designated service. A client that does not understand the new link relation can continue to receive the most-specific answer. A capable client can discover rdap-base-down and cross the boundary deliberately. A client that wants the registry’s own covering record can use the redirect-suppression idea under discussion in the companion explicit-referrals draft.

This is a practical compatibility design. It is also why provenance cannot be left to protocol enthusiasts. The user of an unchanged client may never see the covering record or the point at which the responding institution changed. Standard HTTP redirects are visually quiet. Libraries often follow them automatically. A result may retain the appearance of a single lookup even though its source, availability operator, privacy consequences and evidentiary status changed mid-flight.

The companion working-group draft, draft-ietf-regext-rdap-referrals-04, defines a request for an explicit redirect to a related RDAP record. Where one suitable link exists and the client is authorized, the response uses a normal HTTP redirect status and a Location header. It also deals with relation selection, content negotiation, caching and multi-hop limitations. That machinery saves the client and server from exchanging a full record merely to extract a link. It does not decide how a reader should understand the redirected speaker.

The holder becomes both source and observer

The security section states the provenance rule plainly: data served by the holder-designated server is asserted by the holder, not by the registry operator. Clients presenting that data should distinguish the two. This is not a cosmetic attribution. It determines who can correct the record, who bears the continuity obligation, what evidence can be relied on in a dispute and how long a cached result should retain meaning.

The referral also changes query visibility. Once the client reaches the holder’s infrastructure, the holder can observe interest in its own subordinate resources. The draft compares that visibility to what a DNS operator already sees for its zones and says confidentiality-sensitive clients may decline to follow. That option is meaningful only if software exposes it before silently redirecting, and only if the user can still obtain the registry’s covering record.

Availability splits in the same way. If the holder service is unreachable, the additional subordinate data disappears, while the registry operator’s own responses remain unaffected. A client that reports “RDAP unavailable” without naming which layer failed erases a useful distinction. A registry outage, a broken designation and a holder-side outage are different incidents with different owners.

The designation channel is the unstandardized hinge

The draft does not specify how a holder tells the registry operator which server to use. A portal or a future EPP extension is offered only as an example. That omission is reasonable for a focused RDAP document, but it leaves the most consequential administrative step outside the wire format.

Who may create the pointer? Which credential proves the holder’s authority? Can an agent operate the server without gaining the right to change the designation? When does a new target take effect? How is an emergency revocation handled? Does transfer of the parent domain or number resource automatically invalidate the old pointer? What record survives if a malicious or mistaken designation sends queries to the wrong service?

The draft says registry operators should validate conformance before emitting referrals. Conformance is necessary, but it is not ownership. A server can return well-formed RDAP for data it should not control. The registry needs a lifecycle around designation: authenticated creation, scope proof, target validation, activation, renewal, change, revocation and transfer cleanup. The client needs evidence of which version of that lifecycle produced the link it followed.

A reusable relation needs a visible purpose

The proposed relations are deliberately general. Because they name a downstream or covering base URL rather than a “resource holder” role, the same pair could help discover delegated or hybrid RPKI services and modern replacements for RWhois or SWIP. The draft also invites coordination with the relation used in the RDAP RPKI work. That reuse can reduce protocol clutter.

It can also widen interpretive risk. “Downstream” describes topology, not legal mandate, data quality, service level or endorsement. A link for holder-maintained subordinate names and a link for delegated RPKI data may cross different policy agreements. Clients should preserve the relation’s application context rather than assuming that the same link type creates the same trust model everywhere.

RFC 9224 bootstrap answers where to start for a registered resource. RFC 9910 defines relations used to navigate objects within a registry hierarchy. The proposed rdap-base-down and rdap-base-up pair marks a different event: a crossing between services and, often, between speakers. Reusing Web Linking is technically economical only if the crossing remains legible.

Preserve the authority seam

I propose an authority-seam record for every followed holder referral. It is not part of the draft. It is the evidence a client or downstream database needs to keep discovery from becoming silent endorsement.

The first layer records the registry assertion: bootstrap path, covering object, registry service, relation, designated target, designation channel, authenticated principal, activation time, scope and most recent conformance check. If the administrative interface does not expose some of those fields, the record says unknown rather than inventing them.

The second layer records the crossing: lookup path, whether the client followed an ordinary redirect or an explicit relation, redirect status, suppression choice, target URL, TLS result, retrieval time and hop count. It also records whether the user was warned that the holder could observe the query.

The third layer records the holder assertion separately: responding service, subordinate object, response time, applicable conformance tokens, cache lifetime and reverse link to the covering registry. A presentation can show the useful detail and still state “holder asserted.” It can show the parent record beside it rather than replacing one with the other.

The failure path matters just as much. If the holder service is unavailable, the client should retain the covering registry response and identify the failed subordinate layer. If the pointer is revoked or the parent changes holder, cached subordinate claims need a bounded life. If the response crosses the strict scope, the client rejects it instead of laundering it through the referral.

Revision 01 is an active individual Internet-Draft dated 21 July 2026. Datatracker says it has no formal IETF standing, no stream and no intended RFC status, while the rendered header says Standards Track. The author prefers its substance to merge into the REGEXT working-group referrals draft. Its implementation section reports a holder-side service in production but also identifies the registry-side referral as the missing hop. That is useful implementation context, not evidence of broad deployment or adopted consensus.

The proposal addresses a real gap: important subordinate records can exist where the bootstrap hierarchy cannot find them. The durable answer is not to force all data upward. It is to let discovery move downward while authority remains visibly layered. A seamless interface is good design only when it does not make two speakers sound like one.

Sources