Summary

  • RFC 9910 permits a single-result rdap-up or rdap-top relation to point either to its search URL or to a lookup URL that produced the same response when the first response was generated.
  • If registry state changes before that link is followed, the later target can differ. Preserve the original response, relation context and target, then record every dereference as a separate observation.

The investigation package looked complete. It held a child network response, a retrieval time and an rdap-up link to a parent handle. Several hours later an analyst followed that link and saved the resulting parent object. The two records fitted together neatly, so the reporting system described them as one historical hierarchy.

There was only one problem: nobody had saved what the parent endpoint returned when the child response was captured. The later response could establish what the server said later. It could not reconstruct the earlier parent representation or prove that the hierarchy had remained unchanged between the two requests.

This is a hypothetical control failure, not a report about any registry. It matters because RFC 9910 deliberately gives RDAP relation links a temporal boundary that a compact dashboard can easily erase.

The RFC adds basic, relation and reverse searches for IP networks and autonomous-system numbers. For hierarchy navigation, rdap-up finds the least-specific object above the supplied resource and rdap-top finds the most general covering object. These are single-result searches. A successful answer looks like a direct object lookup; no result yields HTTP 404.

That shape differs from the multiple-result relations rdap-down and rdap-bottom. The distinction matters here only as a boundary. This Article does not reinterpret bottom results as a list of descendants, nor does it repeat an observed ARIN prefix example. Its subject is the single link that seems to name one parent and the evidence lost when time is hidden.

RFC 9910 allows a server to include relation links in an RDAP response. A link can use the corresponding search URL. It may also use another URL that yields the same response as the search at the time of the request. For a single-result relation, that second option can be the ordinary lookup URL for the object found.

The convenience is sound. If the search and lookup resolve to the same parent now, the shorter canonical lookup can be a better navigation target. But equivalence at response generation is not an indefinite promise. RFC 9910 explicitly notes that, if database state changes before the link is resolved, the lookup URL may produce a different result from the search URL.

The difference is easy to miss because the href survives. A target URL can remain byte-for-byte identical while the selected representation behind it changes. The link therefore records a route to a target, not a copy of the target's contents. Saving only the URL preserves an address and discards an observation.

The underlying Web-link model reinforces the point. RFC 9083 requires an RDAP link to carry value, rel and href: context, relation and target. RFC 8288 defines a link as a typed connection between a context resource and a target resource. A relation describes that connection. It does not freeze every future representation retrieved from the target.

Nor does service discovery supply the missing history. RFC 9224 tells a client how to find the authoritative RDAP service for an IP address, prefix or ASN. That authority answers where the request should go for the scope. It does not turn an answer into an immutable registry snapshot.

Time therefore belongs in the data model. The child response is one observation. The parent response obtained immediately, if one was obtained, is another. A response retrieved hours later is a third. Each needs its own raw bytes, hash, request URL, receipt time, HTTP status, message Date, validators, conformance declarations and authenticated endpoint. They can be related without being merged.

HTTP metadata helps, but only when read precisely. RFC 9110 defines Date as the message's origination time. ETag and Last-Modified, when present, describe or validate a selected representation. They can make comparison stronger. They are not registry transaction identifiers and may be absent or weak.

RFC 9111 adds another boundary. Cache age and freshness describe reuse within HTTP caching. They do not explain the history of the registry database. A fresh response can reflect changed registry state; a cached response can be older than the decision an investigator is trying to reconstruct. “Not stale” is not the same claim as “historically identical.”

Filters complicate the apparent hierarchy further. RFC 9910's status parameter treats objects lacking the requested status as though they had been removed before the relation is calculated. An active query can therefore skip an otherwise closer covering object and select a different layer. The resulting rdap-up link is a filtered relationship, not an unqualified parent claim.

Support must also be observed. A server can reject unsupported status filtering with HTTP 501. Relation links inside responses are optional. Their absence does not prove that a corresponding explicit search would have no result. An evidence system that converts “no link” into “no parent” quietly turns optional presentation into negative registry evidence.

The safest capture sequence is small. Preserve the original response before following anything. Parse the link without discarding its context or relation tokens. Record the exact target and any status parameter. If policy requires immediate resolution, fetch the target as a new observation and bind it to the first response by time and hash. Later checks should append records rather than update the original row.

Conditional requests can help compare representations where validators exist. A returned 304 can support a statement about validator semantics for that selected representation. It still does not prove that an unqueried search URL, a differently filtered query or an earlier uncaptured result would be identical. Evidence improves when claims remain no broader than the request that produced it.

The same discipline prevents institutional overreach. A relation result can demonstrate what an authoritative RDAP service exposed about resource hierarchy at a stated time and under stated query semantics. It does not by itself prove routing origin, RPKI authorization, account control, operational use, legal title or the reason for a registry change.

Heng Lu's Running-Code Primacy is relevant because an RFC relation becomes operational only through real server state, client behavior and preserved output. The specification defines the interoperable question; the captured response records one answer.

Minimum Initial Specification argues for a narrow shared core with later decisions kept local and verifiable. Here, the shared core is the relation vocabulary. Archival duration, comparison policy and escalation thresholds belong to accountable operators, not to an inflated reading of the link.

Reality Layers explains why the mistake feels attractive. A typed relation is a precise symbolic fact, while database history and operational use live in other layers. Precision in one layer does not confer authority over the others. Data Sovereignty adds that control of an authoritative record and practical control of networks are connected without becoming the same thing.

RFC 9910 makes RDAP hierarchy navigation more expressive. The correct response is not suspicion of links, but better preservation. Keep the child response. Keep the first parent response. Keep the later dereference. Name the query and filter. Then the link can do its proper job: connect observations without pretending that time never passed.

Sources