RDAP : lire les données d’un domaine en enquête

RDAP fournit des données structurées sur l’enregistrement d’un domaine. Pour une enquête de sécurité, son intérêt est de conserver des observations comparables : événements datés, statuts, bureau d’enregistrement et serveurs de noms. Il ne révèle pas automatiquement l’auteur d’un site ni l’origine d’une campagne.

La méthode suivante part d’un domaine découvert dans un message suspect. Elle produit une fiche d’enquête avec des faits datés, des limites explicites et un interlocuteur adapté. Elle complète la lecture des données WHOIS en investigation en se concentrant sur le traitement du JSON RDAP.

Choisir l’objet et le service interrogé

Conservez d’abord l’URL reçue et son nom d’hôte exact dans votre dossier. La recherche d’enregistrement porte généralement sur le domaine enregistré, qui n’est pas nécessairement le nom complet du service. Gardez cette relation : une observation sur connexion.example.com et une fiche pour example.com ne décrivent pas exactement le même objet.

Utilisez un service de recherche reconnu ou un client RDAP qui découvre le serveur compétent. Notez l’URL du serveur interrogé, l’heure et le résultat HTTP avec la réponse. Le point d’information ICANN pour les utilisateurs RDAP présente le protocole et son outil de consultation pour les noms de domaine.

Ne considérez pas tous les résultats comme équivalents. Une réponse du registre, une réponse du registrar et un agrégateur peuvent avoir des périmètres différents. Si votre outil fusionne plusieurs sources, conservez leur provenance au lieu d’attribuer toutes les valeurs à une source unique.

Sauvegarder les faits avant de leur donner un sens

Exportez la réponse complète dans le dossier, puis construisez une vue courte pour l’analyste. Cette séparation permet de retrouver un champ omis lors du premier triage. Elle évite aussi de perdre les notices qui expliquent une restriction de diffusion ou une donnée absente.

Pour chaque valeur retenue, ajoutez sa source et sa date de consultation. Si vous calculez un âge de domaine, conservez l’événement utilisé pour ce calcul. Un simple entier « 12 jours » devient ambigu une semaine plus tard et masque les cas où aucune date pertinente n’était disponible.

Voici un extrait JSON fictif, limité aux champs nécessaires à l’exercice. Il ne représente pas une réponse complète ni un domaine réellement interrogé.

{
  "objectClassName": "domain",
  "ldhName": "portail-fournisseur.example",
  "status": ["client transfer prohibited"],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2024-04-12T09:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2026-09-28T15:20:00Z"
    }
  ],
  "nameservers": [{ "ldhName": "ns1.dns-prestataire.example" }]
}

La RFC 9083 définit ces structures : événements avec action et date, statuts, entités avec rôles et informations de domaine. Un tableau peut contenir plusieurs événements. Votre lecteur doit donc choisir l’action pertinente, sans prendre arbitrairement la première date rencontrée.

Reconstituer une chronologie sans inventer le changement

Dans l’exemple, l’enregistrement remonte à 2024 et l’objet a été modifié récemment. Cela ne démontre ni une vente ni un piratage. Le résultat ne donne pas, à lui seul, la différence entre l’ancienne et la nouvelle configuration.

Cherchez alors une observation antérieure comparable. Si votre équipe conserve des réponses RDAP, comparez les champs en tenant compte de leur origine. Si vous disposez d’un historique DNS, examinez séparément les changements de délégation ou de résolution. Les deux chronologies peuvent se compléter sans raconter exactement le même événement.

Supposons que le fournisseur confirme une migration le jour de la modification et que les nouveaux serveurs de noms correspondent au changement approuvé. Cette concordance explique une partie du dossier. Elle ne valide pas tous les liens envoyés au nom de ce fournisseur : l’URL et la demande reçues restent à vérifier.

À l’inverse, si personne ne reconnaît le changement et qu’un portail de connexion inhabituel apparaît, augmentez la priorité de l’enquête. Décrivez les deux observations séparément, puis l’hypothèse qu’elles motivent. Cette formulation reste révisable si une pièce ultérieure apporte une autre explication.

Interpréter les statuts comme des opérations

Un verrouillage de transfert est souvent une mesure de gestion normale. Il n’atteste pas la sécurité du contenu web. Un statut de suspension DNS décrit, lui, un effet technique ; il ne révèle pas nécessairement le motif de la suspension.

La table ICANN des codes EPP et de leurs libellés RDAP permet de lire ces valeurs. Par exemple, clientTransferProhibited correspond à une interdiction de transfert demandée côté registrar. Ne le traduisez pas par « domaine malveillant bloqué ».

Dans votre fiche, séparez la valeur brute, sa signification opérationnelle et votre interprétation. Cette présentation évite qu’une étiquette technique devienne un verdict de réputation dans un export destiné au SOC ou au support.

Distinguer les contacts et leurs rôles

Le registrar gère l’enregistrement ; le fournisseur DNS héberge la zone ; l’hébergeur sert le contenu. Une même société peut exercer plusieurs rôles, mais il faut le vérifier. Envoyer une demande au premier nom d’entreprise rencontré dans le JSON risque d’allonger le traitement.

Si vous préparez un signalement, réunissez le domaine, les URL concernées, les heures et les preuves de l’abus constaté. Vérifiez ensuite le canal de contact du service responsable. Ne transmettez que les informations nécessaires, sans joindre automatiquement tout le dossier d’incident.

L’absence de nom de titulaire ne constitue pas une preuve d’opacité malveillante. Notez « identité non publique dans cette réponse ». Une enquête peut rester pertinente grâce au contenu observé, aux journaux et à la chronologie, même sans attribution personnelle.

Choisir l’étape suivante selon la preuve manquante

Si la question concerne l’activité d’un utilisateur, recherchez les événements locaux. Si elle concerne le changement de service, contactez son propriétaire par un canal connu. Si elle concerne une infrastructure suspecte, comparez les observations d’enregistrement aux indicateurs techniques disponibles, en conservant leurs dates.

Le suivi des changements de réputation d’un domaine aide à prolonger cette fiche dans le temps. Évitez une règle automatique fondée uniquement sur l’âge, le pays du registrar ou un contact masqué : ces champs décrivent des caractéristiques, pas une compromission démontrée.

Terminez la fiche par l’action, son responsable et la limite restante. Par exemple : « modification récente confirmée ; migration non validée par le fournisseur ; accès au portail suspendu dans l’attente de vérification ». Pour compléter le contexte du domaine, consultez un rapport IsMalicious, puis associez ce résultat daté aux données RDAP et aux observations qui motivent votre décision.