Summary

  • RFC 9910, an IETF Proposed Standard from January 2026, adds RIR-specific RDAP search capabilities for IP networks, autonomous system numbers and ranges, and reverse DNS objects.
  • Basic and relation searches expose different questions about a registry hierarchy. A result link can retain the search or point to a single-result lookup, so operators should preserve the query, response and observation time together.
  • A returned relationship is evidence of what an authorized RDAP service reported at a particular time. It does not prove ownership, legal title, permanent hierarchy, dataset completeness or universal RIR deployment.

The mechanism

RDAP already provides structured lookup and response conventions. RFC 9910 adds a regional Internet registry search surface using explicit path segments and the registered rirSearch1 identifier. Its scope covers searches for IP networks, autonomous system numbers or ASN ranges, and reverse DNS objects. The input depends on the selected object class: an IP address or CIDR pair, a domain name, or one ASN or ASN range.

A basic search asks the registry to find objects matching the selected resource class. A relation search asks for objects positioned relative to another resource in the Internet number-resource hierarchy. The direction matters: the result can describe a parent, child, or another defined relationship relative to the starting object. Defined relation types and optional status filters narrow the question, but they do not turn a registry response into a general-purpose ownership register.

Search links and result sets

The useful distinction is between a search URL and a lookup URL. A search link preserves the query that produced a result set. If the server has one result, RFC 9910 permits a result link to replace that search with a direct lookup URL. That shortcut is operationally different: a later client may now retrieve the object by identity rather than repeat the original search. If registry state changes between the original response and the later request, the lookup response and the earlier search result may diverge.

Treat the response as a result set with a time boundary. Record the exact path, query inputs, relation type, status filter, registry authority, response bytes, returned link and observation time. A stored lookup URL is useful for navigation, but it is not a substitute for preserving the original search URL and captured response. Re-query when the decision depends on current state.

RFC 9082 supplies baseline query and lookup path semantics; RFC 9083 describes RDAP JSON responses and link objects. RFC 9910 controls the RIR-specific search paths, relation vocabulary and result behavior. RFC 7481 keeps the operational boundary visible: authentication, authorization, confidentiality, privacy, rate limits and regulatory constraints still apply. Broader search capability does not override a server's access policy or a jurisdiction's rules.

Evidence ledger at observation time

  • Observed at: 2026-09-06T07:55:55.126Z, the frozen source-packet time.
  • Authority to record: the RDAP server or RIR endpoint that supplied the response; the packet does not establish current deployment by any RIR.
  • Query evidence: exact object class, IP/CIDR, domain, ASN or ASN range, relation direction, relation type, and status filter.
  • Response evidence: raw response bytes, result-set shape, link relation, search URL, any replacement lookup URL, and HTTP metadata permitted by policy.
  • Boundary: the ledger records an observation, not legal title, permanent hierarchy, complete data, or a timeless fact.

Operator acceptance decision path

  1. Define the question. Choose a basic or relation search, object class, hierarchy direction, and any status filter.
  2. Check authority. Confirm the endpoint, authorization, privacy basis, rate limit and jurisdictional permission before issuing the request.
  3. Capture the source. Preserve the exact search URL, response, result class, relation and observation time. Do not keep only a convenient lookup shortcut.
  4. Assess the decision. Accept the result only as time-bound registry evidence. If the action requires current state, re-query and compare; if access is denied or the result is ambiguous, stop or escalate rather than infer.
  5. Record change. Treat changed links, statuses or hierarchy positions as a new observation and document the operational consequence.

Theo March — analysis: RFC 9910 makes hierarchy discovery more queryable, but accountability depends on retaining how and when the answer was obtained. The practical control is not confidence in a URL; it is disciplined evidence capture under the authority and privacy limits of RDAP.

Sources