Lire un enregistrement RDAP d’adresse IP

Une fiche de registre n’est que le début de l’enquête

RDAP donne accès à ce qu’un registre consigne sur une ressource. Pour une équipe réseau, la question suivante est tout aussi importante : ces informations correspondent-elles aux routes, aux autorisations et aux responsabilités réelles ? Ce guide permet de passer de la lecture des champs à un contrôle reproductible.

Les adresses, organismes et dates des exemples servent à expliquer le format. Ce ne sont pas des observations en temps réel. Les extraits JSON d’origine restent inchangés.

Ce qu’un enregistrement RDAP permet de comprendre

Le Registration Data Access Protocol, ou RDAP, fournit des données d’enregistrement structurées pour les plages IPv4, les préfixes IPv6 et les numéros de système autonome (ASN). Il utilise des requêtes web normalisées et des réponses JSON. Savoir lire le résultat compte davantage que connaître le développement du sigle.

Une réponse peut indiquer la plage concernée, le registre interrogé, un identifiant, un nom de réseau, une classification, un état, des organismes et contacts associés, des événements, un réseau parent et des informations complémentaires. On l’utilise pour les inventaires, le dépannage, les enquêtes de sécurité, les transferts IPv4 ou les acquisitions d’entreprises.

Reconnaît-on l’entité indiquée ? Les contacts techniques, administratifs et de traitement des abus sont-ils encore joignables ? Les données concordent-elles avec l’inventaire interne ? RDAP aide à poser ces questions ; il ne décrit pas à lui seul tout ce qui arrive au préfixe.

RDAP et WHOIS : deux accès aux données, des formats différents

WHOIS renvoie surtout du texte dont la présentation varie selon le registre. RDAP apporte une structure JSON, des requêtes normalisées, HTTP/HTTPS, des redirections entre services et une meilleure prise en charge de l’internationalisation. RIPE NCC et APNIC proposent notamment ces services.

L’automatisation et l’intégration à une API s’en trouvent facilitées. Une structure commune n’efface cependant pas les différences de classification ou de politique entre registres. Conservez la valeur reçue, puis interprétez-la dans son contexte.

Trouver le service compétent pour l’adresse

Une requête IP prend généralement la forme /ip/{IP-address} ou /ip/{CIDR-prefix}. Les chemins /ip/192.0.2.1 et /ip/192.0.2.0/24 illustrent respectivement une adresse et un préfixe. Une recherche portant sur une seule adresse peut renvoyer la plage qui la contient.

Les registres d’amorçage RDAP de l’IANA associent les plages aux services correspondants : un client peut ainsi trouver le service faisant autorité sans deviner le RIR. Les interfaces de recherche des RIR offrent une autre entrée. RIPE NCC documente par exemple https://rdap.db.ripe.net/ip/{address}. Notez aussi l’URL du service et l’heure de consultation.

Une réponse simplifiée pour se repérer

L’exemple rassemble les limites de la plage, son nom, son état, des entités et des événements. Le préfixe 192.0.2.0/24 et les noms EXAMPLE sont illustratifs. Une réponse réelle peut contenir davantage de champs, ou omettre des membres facultatifs selon les règles du service et les droits d’accès.

{
  "objectClassName": "ip network",
  "handle": "NET-192-0-2-0-1",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.255",
  "ipVersion": "v4",
  "name": "EXAMPLE-NET",
  "type": "DIRECT ALLOCATION",
  "country": "ZZ",
  "status": [
    "active"
  ],
  "entities": [
    {
      "handle": "EXAMPLE-ORG",
      "roles": [
        "registrant"
      ]
    },
    {
      "handle": "EXAMPLE-ABUSE",
      "roles": [
        "abuse"
      ]
    }
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2020-01-01T00:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2026-01-15T00:00:00Z"
    }
  ]
}

1. objectClassName : vérifier la nature de l’objet

La classe d’un réseau IP est ip network. autnum désigne un ASN, entity un organisme ou un contact, domain un objet de domaine et nameserver un serveur de noms. Avant d’interpréter une réponse sur un préfixe, assurez-vous de lire le réseau lui-même et non une entité associée.

"objectClassName": "ip network"

2. startAddress et endAddress : retenir toute la plage

Ces champs fixent les bornes de l’enregistrement. Une recherche sur 192.0.2.45 peut renvoyer la plage allant de 192.0.2.0 à 192.0.2.255. Les renseignements portent alors sur ce bloc, pas uniquement sur l’hôte saisi.

Pour un audit, consignez les deux limites. Vous pourrez ensuite les comparer aux préfixes internes, aux délégations et aux annonces observées, dont les périmètres ne sont pas nécessairement identiques.

"startAddress": "192.0.2.0",
"endAddress": "192.0.2.255"

3. ipVersion : ne pas mélanger les familles d’adresses

v4 indique IPv4 et v6 indique IPv6. Ce repère simple évite des erreurs de format ou de traitement lors de l’analyse d’un grand nombre d’enregistrements.

"ipVersion": "v4"

4. handle : identifier la fiche

Le handle est l’identifiant unique de l’objet dans le système du registre. Ce n’est pas l’adresse IP. Il sert à suivre une fiche, relier des objets, documenter un audit, consulter des liens ou comparer des états historiques.

Son rôle d’identification n’en fait pas un certificat de propriété. Les questions de droits exigent d’autres éléments.

"handle": "NET-192-0-2-0-1"

5. name : un nom de réseau peut avoir une histoire

Le champ name fournit un identifiant de réseau lisible par une personne. Il ne coïncide pas forcément avec la raison sociale actuelle : changement de nom, acquisition ou ancien libellé technique peuvent expliquer un écart.

Lors d’une vérification approfondie, comparez ce nom aux entités, aux renseignements sur l’organisme, aux documents sociaux et aux autres données du registre.

"name": "EXAMPLE-NET"

6. type : lire la classification du RIR concerné

type correspond à une classification propre au modèle du registre. DIRECT ALLOCATION est un exemple, pas un vocabulaire dont le sens serait identique partout.

Relevez d’abord la valeur exacte, puis consultez la terminologie et les politiques du RIR. Ne déduisez pas automatiquement des droits d’un simple libellé.

"type": "DIRECT ALLOCATION"

7. country : distinguer enregistrement et géolocalisation

Un code pays ne localise pas chaque serveur ni chaque utilisateur. Une plage associée à un organisme d’un pays peut être routée ailleurs, servir des clients internationaux, être annoncée depuis plusieurs sites ou utilisée dans le cloud. Les bases GeoIP commerciales peuvent encore donner une autre indication.

Une enquête sur la localisation demande donc des preuves complémentaires. ZZ est ici une valeur d’exemple, pas le résultat d’une mesure géographique.

"country": "ZZ"

8. status : active ne démontre pas la joignabilité

status décrit l’état de l’objet enregistré. Pour les réseaux et ASN, la définition IANA d’active renvoie à une allocation ou une affectation destinée à un réseau opérationnel. Elle ne remplace pas une observation du réseau.

Ce statut ne prouve ni une annonce BGP actuelle, ni la joignabilité, ni l’autorisation d’un ASN, ni l’existence d’un ROA valide, ni le bon fonctionnement du DNS inverse, ni l’usage en production. Vérifiez séparément le registre, le routage, RPKI, IRR et DNS.

"status": [
  "active"
]

9. parentHandle : remonter au réseau parent

parentHandle identifie l’enregistrement parent. Un petit bloc peut relever d’une allocation plus large ; la relation aide à comprendre les affectations en aval, les réseaux clients, l’historique et les liens entre organismes.

Suivre le parent peut révéler un contexte absent de la première réponse. Cela reste une relation de registre à examiner, et non une conclusion automatique sur les responsabilités.

"parentHandle": "PARENT-NET"

10. entities : savoir qui figure dans la réponse

Une entité peut représenter un organisme, une personne ou un contact associé au registre. Elle peut avoir un handle, des coordonnées, des rôles, d’autres entités, des événements, des remarques et des liens.

La présence d’un nom ne suffit pas à déterminer sa responsabilité. Le champ roles précise le rapport de l’entité avec la ressource.

"entities": [
  {
    "handle": "EXAMPLE-ORG",
    "roles": [
      "registrant"
    ]
  }
]

11. roles : trouver le bon interlocuteur

Les rôles courants comprennent registrant, administrative, technical, abuse, noc et billing. abuse désigne un contact pour les signalements d’abus, technical un contact technique. Une entité peut avoir plusieurs rôles.

Vérifiez que l’organisme est identifiable, les contacts administratifs toujours habilités, le contact technique actuel et le canal de signalement utilisable. Des coordonnées périmées compliquent incidents, transferts, dépannage et récupération d’un compte.

"roles": [
  "abuse"
]

"roles": [
  "technical"
]

12. vcardArray : des coordonnées parfois partielles

vcardArray structure les renseignements de contact : nom d’organisme, personne ou fonction, adresse, courriel, téléphone. Toutes les réponses ne rendent pas tous ces éléments publics.

Le contenu dépend du service, des politiques de confidentialité, des droits d’accès, des occultations, du type de ressource et des règles applicables. En cas d’absence, lisez remarks et notices avant de conclure que le registre ne dispose d’aucune information.

13. events : dater les changements sans leur prêter une cause

Chaque événement associe eventAction à eventDate. On peut trouver registration, last changed, expiration ou deletion. Dans un audit, la date d’enregistrement et celle de dernière modification constituent de premiers repères.

Une modification récente peut concerner un contact, une restructuration, une maintenance, un transfert ou une correction. Elle n’est pas suspecte par nature. Inversement, une date ancienne ne démontre pas un abandon. Il faut expliquer les dates avec l’historique disponible.

"events": [
  {
    "eventAction": "registration",
    "eventDate": "2020-01-01T00:00:00Z"
  },
  {
    "eventAction": "last changed",
    "eventDate": "2026-01-15T00:00:00Z"
  }
]

14. remarks : lire les précisions sur l’objet

Les remarques peuvent exposer une particularité, une restriction, une occultation, un historique ou une information propre au registre. Leur position en fin de JSON ne les rend pas secondaires.

Dans une vérification préalable, elles peuvent modifier la manière de comprendre les autres champs. Prenez le temps de les examiner.

"remarks": [
  {
    "description": [
      "Additional registration information."
    ]
  }
]

15. notices : comprendre les conditions de la réponse

Les notices concernent généralement l’ensemble de la réponse et se placent au niveau supérieur. Elles peuvent traiter des conditions d’utilisation, de confidentialité, de droits d’auteur, d’occultation ou de limites de requêtes.

Un traitement automatisé ne devrait pas les jeter : elles peuvent expliquer des données manquantes ou les conditions dans lesquelles utiliser la réponse, alors que remarks vise un objet particulier.

16. links : poursuivre la lecture dans les objets liés

Les liens peuvent viser l’objet courant, un parent, une entité, une autre représentation ou une ressource du registre. rel précise la relation, par exemple self ou up, et href la destination.

L’extrait historique ci-dessous est volontairement partiel. Pour constituer un objet lien conforme au RFC 9083, il faut aussi le membre value. Il illustre une relation ; ce n’est pas un modèle complet à copier dans une implémentation.

"links": [
  {
    "rel": "self",
    "href": "https://example.net/rdap/ip/192.0.2.0/24"
  }
]

Une première lecture dans un ordre utile

Commencez par les bornes et la version IP. Identifiez ensuite la fiche, son nom, sa classification et son état, puis les entités, les rôles et les événements. Terminez par les remarques, les notices et les relations vers les parents ou objets liés.

Le tableau donne un fil de lecture rapide. Cette première passe ne dispense pas de vérifier le routage, les autorisations, la réputation et les dépendances métier.

Six questions auxquelles RDAP ne répond pas seul

Routage actuel : une plage enregistrée peut être absente de BGP. Vérifiez l’annonce, l’ASN d’origine, la stabilité et la longueur du préfixe dans des données de routage.

Autorisation : le nom du titulaire ne dit pas automatiquement quel ASN peut annoncer la plage. Examinez ROA et validation RPKI, objets IRR, lettres d’autorisation pertinentes et annonces BGP, sans attribuer à ces sources la même force probante.

Droits juridiques ou contractuels : la fiche est une pièce du dossier. Accords, documents de transfert, actes sociaux, politiques, historique, droit applicable et décisions pertinentes peuvent également compter.

Localisation : country ne remplace pas une enquête GeoIP ou réseau. Réputation : listes de blocage, spam, logiciels malveillants, abus passés et réputation commerciale nécessitent leurs propres contrôles.

DNS inverse : vérifiez-le indépendamment, en particulier pour la messagerie, l’hébergement, les services d’entreprise et les opérations de sécurité.

Relier les couches plutôt que choisir une base unique

Le registre renseigne l’enregistrement ; BGP, les annonces observées ; les éléments d’autorisation, l’origine attendue ; DNS, le nommage et la délégation inverse.

Ajoutez la sécurité des objets RPKI et des accès, la réputation, les documents expliquant l’obtention et l’administration de la ressource, puis la capacité à poursuivre cette administration quand des personnes, fournisseurs ou structures changent.

Un inventaire de référence interne relie ces faits et leurs sources. Aucun champ isolé ne doit être chargé de décrire tout l’état opérationnel d’une ressource.

Intégrer RDAP à un audit en sept étapes

1. Constituez l’inventaire des préfixes IPv4, IPv6 et ASN importants. Incluez les réserves, ressources inutilisées, déléguées, anciennes et prévues pour la continuité ; les seules configurations actives sont insuffisantes.

2. Interrogez chaque ressource. Gardez plage, registre, handle, nom, type, statut, organismes, contacts administratifs, techniques et d’abus, dates d’enregistrement et de modification, avec la source et l’heure de consultation.

3. Confrontez ces résultats aux dossiers internes : identité de l’organisme, habilitation des contacts, périmètre, historique et accès au compte du registre. Expliquez les écarts au lieu de désigner d’emblée une base comme correcte.

4. Contrôlez BGP séparément : ASN d’origine, préfixe annoncé, visibilité, transit attendu et annonces inattendues. Une réponse RDAP réussie n’atteste pas la santé opérationnelle.

5. Examinez les ROA, l’ASN, le préfixe, la longueur maximale, la validation RPKI et IRR. Recommencez après une migration de routage ou un changement d’ASN.

6. Recensez les dépendances : DNS inverse, API, listes d’autorisation des clients, VPN, pare-feu, SaaS, paiements, messagerie et documents de conformité.

7. Documentez les exceptions : écart, explication, responsable, correction éventuelle et risque de continuité. Un successeur doit pouvoir reprendre le dossier.

Lors d’un transfert IPv4, élargir la vérification

Avant une transaction, identifiez le RIR, la plage réellement enregistrée, les entités, le parent, les dernières modifications et le contexte des remarques ou notices. Comparez le tout aux pièces de la transaction.

La diligence couvre aussi les procédures applicables, les documents de transfert et de société, l’historique BGP, RPKI, IRR, le DNS inverse, la réputation et le déploiement prévu. La référence de l’article aux conséquences de données WHOIS/RDAP périmées reste accessible dans les lectures complémentaires.

Quand l’administratif devient un enjeu de continuité

Le contact technique a quitté l’entreprise depuis trois ans ; celle-ci a changé de nom ; personne ne sait qui contrôle le compte ; des centaines de clients ont autorisé le bloc dans leurs systèmes ; une migration approche. L’exactitude du registre cesse alors d’être une simple question documentaire.

Les ressources importantes ont besoin de données à jour, d’accès maîtrisés, de responsabilités internes claires, d’un historique, d’une visibilité BGP/RPKI et de procédures de récupération. Le registre doit être une couche fiable de cet ensemble.

Faire correspondre les dossiers au réseau qui en dépend

RDAP montre ce que le registre consigne, BGP ce qui est observé, RPKI la concordance d’une origine avec une autorisation publiée, DNS le nommage et la délégation inverse. Les dossiers sociaux et transactionnels éclairent l’histoire de la ressource.

Ne confondez pas enregistrement et routage, pays et emplacement, entité et titre juridique, active et usage effectif. Pour une organisation dépendante d’IPv4, d’IPv6 ou d’ASN, une revue périodique doit vérifier que ces couches restent exactes, compréhensibles et cohérentes avec l’exploitation.

Six questions fréquentes

Qu’est-ce qu’un enregistrement RDAP ?

Une réponse structurée sur l’enregistrement d’une ressource : plage, identifiant, état, entités, contacts, événements et autres informations du registre.

Que signifie RDAP ?

Registration Data Access Protocol : le protocole d’accès aux données d’enregistrement.

Peut-on rechercher une adresse IPv4 ?

Oui, ainsi qu’une adresse IPv6 ou un préfixe CIDR. RDAP permet aussi des recherches d’ASN avec la requête correspondante. La réponse peut couvrir une plage plus large que l’adresse saisie.

Quel avantage sur WHOIS ?

Les requêtes normalisées, JSON, HTTPS et les redirections facilitent l’intégration et l’automatisation. WHOIS reste familier aux opérateurs ; les données exigent toujours une interprétation contextualisée.

À quoi sert handle ?

À identifier l’objet de manière unique dans le registre et à relier les données. Ce n’est pas un titre de propriété.

active signifie-t-il que le réseau fonctionne ?

Non : il décrit un état d’enregistrement, pas une preuve de routage actuel, de joignabilité ou de validation RPKI.

Article d’origine et notes éditoriales

Ann Yong a publié et mis à jour l’article le 26 août 2026. Cette édition reprend l’ensemble des sujets, 16 extraits JSON, deux tableaux et six réponses ; cinq réponses répétées dans l’ancien accordéon sont réunies avec leurs équivalents. Les précisions sur active et sur le membre value absent de l’exemple links sont des notes de cette édition. La date d’origine est conservée.

Normes et lectures complémentaires

• Auditer les ressources numériques
• Inventaire réseau de référence
• Risques de la couche registre
• Vérifier l’origine BGP
• RFC 9082
• RFC 9083
• RFC 9224
• IANA : valeurs RDAP
• IANA : amorçage IPv4
• Données périmées lors d’un transfert IPv4

Choisir la suite à partir des faits

NRS Shield propose un accompagnement lorsque la vérification révèle un risque pour un membre. Un POA constitue une décision distincte de représentation : examinez son périmètre, sa durée, les pouvoirs de décision et la révocation. Lire cet article ou demander de l’aide ne confère aucun mandat.

Découvrir NRS Shield · Comprendre le POA et la représentation · Consulter les actions en cours