Résumé

  • Pour une relation à résultat unique comme rdap-up ou rdap-top, RFC 9910 autorise l’URL de recherche ou une URL de consultation qui donnait la même réponse au moment de la génération.
  • Une évolution de la base avant l’ouverture du lien peut modifier la représentation obtenue ; il faut donc conserver séparément la réponse d’origine et chaque consultation postérieure.

Un dossier d’analyse contient une réponse RDAP relative à un réseau enfant. Le champ de liens désigne un objet supérieur par la relation rdap-up. Le lendemain, l’enquêteur ouvre l’adresse, reçoit un objet cohérent et complète son graphe historique. L’ensemble paraît solide : un enfant, un parent, deux horodatages.

Mais le second horodatage trahit précisément la lacune. L’objet supérieur n’a pas été capturé en même temps que l’enfant. Sa représentation tardive atteste ce que le service a répondu le lendemain, non ce qu’il aurait répondu la veille. Le lien a été archivé ; l’observation initiale de sa cible ne l’a pas été.

Ce scénario est fictif et ne décrit aucun registre particulier. Il met en lumière la limite temporelle que RFC 9910 inscrit dans les relations de recherche RDAP.

Le texte ajoute des recherches de base, de relation et inverses pour les réseaux IP et les numéros de systèmes autonomes. rdap-up cherche l’objet couvrant le plus proche au-dessus de la ressource fournie ; rdap-top remonte jusqu’à l’objet couvrant le plus général. Ces deux opérations produisent un résultat unique. Elles renvoient l’objet comme lors d’une consultation directe ou un statut HTTP 404 si rien ne correspond.

Les relations rdap-down et rdap-bottom produisent, elles, plusieurs résultats. Cette différence borne l’analyse : il n’est pas question ici de transformer une couverture bottom en liste de descendants ni de reprendre un exemple public d’ARIN. La question est celle du temps caché derrière un lien à résultat unique.

Le serveur peut insérer dans sa réponse l’URL exacte de la recherche de relation. Il peut également indiquer une autre URL donnant une réponse identique au moment de la requête. Pour rdap-up ou rdap-top, ce substitut peut être l’URL ordinaire de l’objet trouvé.

Cette souplesse évite au client une recherche supplémentaire et lui fournit une cible canonique. Elle ne garantit toutefois pas une équivalence permanente. RFC 9910 prévient que, si l’état de la base évolue avant la résolution du lien, l’URL de consultation peut conduire à un résultat différent de celui de la recherche.

Le piège tient à la stabilité apparente de l’adresse. Un href inchangé peut sélectionner une représentation nouvelle. Conserver l’adresse revient à préserver un itinéraire, pas le contenu rencontré à l’arrivée. Une chaîne de preuve qui ne garde que le lien confond donc référence et observation.

RFC 9083 impose à l’objet lien RDAP les chaînes value, rel et href, soit le contexte, la relation et la cible. Dans le modèle général de RFC 8288, le lien est une connexion typée entre une ressource de contexte et une ressource cible. Son type n’engage pas toutes les représentations futures de cette cible.

La sélection du service ne résout pas davantage l’histoire. RFC 9224 permet de découvrir le service RDAP faisant autorité pour une adresse, un préfixe ou un ASN. Il établit où interroger le périmètre ; il ne fige pas la réponse du service.

Il faut alors traiter chaque requête comme une observation autonome. La réponse enfant, la résolution immédiate éventuelle du parent et la résolution du lendemain ont chacune leurs octets, leur empreinte, leur URL, leur heure de réception, leur statut, leur en-tête Date, leurs validateurs, leur ensemble de conformité et leur extrémité authentifiée. Une relation peut les relier sans les fusionner.

Les métadonnées HTTP renforcent une comparaison à condition de respecter leur portée. Selon RFC 9110, Date exprime l’instant d’origine du message. ETag et Last-Modified décrivent ou valident une représentation sélectionnée lorsqu’ils sont disponibles. Ce ne sont ni des numéros de transaction du registre ni une explication du changement.

RFC 9111 sépare également fraîcheur du cache et histoire du registre. Une réponse fraîche peut déjà refléter une modification de la base. Une réponse encore réutilisable peut précéder l’événement étudié. L’absence d’obsolescence HTTP ne démontre aucune continuité historique.

Le filtre status change en outre le sens du parcours. RFC 9910 calcule la relation comme si les objets ne portant pas l’état demandé avaient été retirés. Une recherche active peut ainsi sauter un niveau couvrant plus proche. La relation obtenue est celle d’une hiérarchie filtrée, pas l’affirmation absolue d’un parent.

Il faut observer les capacités plutôt que les deviner. Certaines combinaisons de filtrage peuvent recevoir HTTP 501. L’inclusion des liens dans les réponses reste optionnelle. L’absence de lien ne prouve donc pas qu’une recherche explicite n’aurait aucun résultat. Convertir une présentation facultative en preuve négative fabrique un fait que le protocole n’a pas fourni.

La procédure robuste commence avant le clic : conserver les octets de la réponse courante, puis extraire sans perte le contexte, le type de relation, la cible et le filtre. Si la cible doit être interrogée immédiatement, sa réponse devient une nouvelle pièce liée par empreinte et par temps. Les contrôles suivants ajoutent des observations ; ils ne mettent jamais à jour l’ancienne.

Une requête conditionnelle peut montrer qu’une représentation associée à un validateur n’a pas changé selon les règles HTTP. Elle ne dit rien d’une URL de recherche non interrogée, d’un autre filtre ou d’un état initial jamais capturé. La conclusion doit rester de la taille exacte de la requête qui l’étaye.

Cette limite protège aussi contre les extrapolations institutionnelles. Une réponse RDAP peut attester la hiérarchie publiée par un service faisant autorité, à une heure et avec une sémantique données. Elle n’établit seule ni origine de routage, ni autorisation RPKI, ni contrôle d’un compte, ni exploitation effective, ni titre juridique.

Dans Running-Code Primacy, Heng Lu distingue le texte du comportement effectivement exécuté. La spécification rend la question interopérable ; l’état du serveur et la réponse sauvegardée constituent une réponse vérifiable.

Minimum Initial Specification invite à ne partager que le noyau indispensable. Les relations RDAP appartiennent à ce noyau. La durée d’archivage et les seuils d’alerte restent des décisions locales dont un responsable doit répondre.

Reality Layers aide à ne pas donner à un symbole précis le pouvoir d’un autre plan de réalité. Data Sovereignty rappelle pareillement que la maîtrise d’un enregistrement officiel et la maîtrise pratique d’un réseau ne se confondent pas.

RFC 9910 améliore la navigation. Pour en tirer parti sans réécrire le passé, il suffit de préserver le temps : réponse enfant, première réponse cible, consultations ultérieures, URL et filtres. Le lien peut alors relier les observations sans prétendre qu’elles ont eu lieu ensemble.

Sources