Résumé

  • La RFC 9910, Proposed Standard de l’IETF en janvier 2026, ajoute des capacités de recherche RDAP propres aux RIR pour les réseaux IP, les numéros de système autonome et leurs plages, ainsi que les objets DNS inversés.
  • Une recherche de base et une recherche de relation ne posent pas la même question sur une hiérarchie de registre. Un lien de résultat peut conserver la recherche ou pointer vers une consultation unique : il faut donc conserver requête, réponse et heure d’observation.
  • Une relation retournée atteste de ce qu’un service RDAP autorisé a déclaré à un moment donné. Elle ne prouve ni propriété, ni titre juridique, ni permanence, ni exhaustivité des données, ni déploiement universel chez les RIR.

Le mécanisme

RDAP fournit déjà les conventions de consultation structurée et de réponse. La RFC 9910 ajoute une surface de recherche propre aux registres Internet régionaux, avec des segments de chemin explicites et l’identifiant enregistré rirSearch1. Elle couvre les recherches de réseaux IP, de numéros autonomes ou de plages d’ASN, ainsi que d’objets DNS inversés. Selon la classe d’objet, l’entrée est une adresse IP ou une paire CIDR, un nom de domaine, ou un ASN unique ou une plage d’ASN.

Une recherche de base demande au registre des objets correspondant à la classe de ressource sélectionnée. Une recherche de relation demande des objets placés par rapport à une autre ressource dans la hiérarchie des ressources de numérotation. Le sens de la hiérarchie compte : la réponse peut décrire un parent, un enfant ou une autre relation définie relativement à l’objet de départ. Les types de relation définis et les filtres de statut facultatifs précisent la question, sans transformer la réponse en registre général de propriété.

Liens de recherche et ensembles de résultats

Il faut distinguer l’URL de recherche de l’URL de consultation. La première conserve la requête qui a produit un ensemble de résultats. Si le serveur ne trouve qu’un résultat, la RFC 9910 permet qu’un lien remplace cette recherche par une URL de consultation directe. Ce raccourci change la situation opérationnelle : le client ultérieur peut récupérer l’objet par son identifiant au lieu de répéter la recherche initiale. Si l’état du registre évolue entre les deux requêtes, la consultation et le résultat initial peuvent diverger.

Il faut traiter la réponse comme un ensemble de résultats borné par une heure. Conservez le chemin et les paramètres exacts, les types et le sens de relation, le filtre de statut, l’autorité du registre, les octets de réponse, le lien retourné et l’heure d’observation. Une URL de consultation conservée facilite la navigation, mais ne remplace pas l’URL de recherche ni la réponse capturée. Si la décision exige l’état actuel, relancez la recherche.

La RFC 9082 fournit les sémantiques de base des chemins de consultation et des requêtes ; la RFC 9083 décrit les réponses JSON RDAP et les objets de lien. La RFC 9910 gouverne les chemins de recherche propres aux RIR, le vocabulaire des relations et le comportement des résultats. La RFC 7481 maintient les limites opérationnelles : authentification, autorisation, confidentialité, vie privée, limitation de débit et contraintes réglementaires restent applicables. Une recherche plus large ne contourne ni la politique d’accès du serveur ni le droit applicable dans une juridiction.

Registre de preuves au moment de l’observation

  • Observé le : 2026-09-06T07:55:55.126Z, heure de gel du paquet de sources.
  • Autorité à consigner : le serveur RDAP ou le point d’accès RIR ayant fourni la réponse ; le paquet n’établit pas le déploiement actuel par chaque RIR.
  • Preuve de requête : classe d’objet, IP/CIDR, domaine, ASN ou plage, sens et type de relation, filtre de statut.
  • Preuve de réponse : octets bruts, forme de l’ensemble de résultats, relation du lien, URL de recherche, éventuelle URL de consultation et métadonnées autorisées.
  • Limite : le registre consigne une observation, non un titre juridique, une hiérarchie permanente, une donnée complète ou une vérité intemporelle.

Parcours de décision pour l’acceptation opérateur

  1. Définir la question. Choisir recherche de base ou de relation, classe d’objet, direction hiérarchique et filtre de statut éventuel.
  2. Vérifier l’autorité. Confirmer le point d’accès, l’autorisation, la base de confidentialité, la limitation de débit et la permission juridictionnelle avant l’appel.
  3. Capturer la source. Conserver l’URL de recherche, la réponse, la classe de résultat, la relation et l’heure. Ne pas conserver seulement le raccourci de consultation.
  4. Évaluer la décision. Accepter le résultat comme preuve de registre limitée dans le temps. Pour l’état actuel, relancer et comparer ; en cas de refus ou d’ambiguïté, arrêter ou faire remonter le cas plutôt que déduire.
  5. Consigner le changement. Tout changement de lien, de statut ou de position hiérarchique est une nouvelle observation avec sa conséquence opérationnelle.

Theo March — analyse : la RFC 9910 rend la découverte des hiérarchies plus interrogeable, mais la responsabilité dépend de la conservation du comment et du quand. Le contrôle concret n’est pas la confiance dans une URL : c’est la capture disciplinée des preuves, dans les limites d’autorité et de confidentialité de RDAP.

Sources