Un instantané, pas un historique

Une consultation publique WHOIS, RDAP ou DNS signale l'état d'un domaine au moment où il est interrogé. Ce n'est pas un enregistrement historique: elle ne peut pas montrer ce que les données de l'enregistrant indiquaient il y a un an, quels étaient les serveurs de noms avant le changement le plus récent, ou combien de fois un domaine a été réenregistré. Les enquêteurs qui ont besoin de cet historique doivent se tourner vers un ensemble de données DNS historique ou WHOIS historique dédié, maintenu par un fournisseur spécialisé, en comprenant que ces ensembles de données ont leurs propres lacunes de couverture et ne constituent pas une archive complète de chaque domaine à tout moment.

Ce qu'un rapport d'enregistrement ou DNS n'inclut pas

Un rapport de domaine public standard renvoie ce qui est publié sous le nom de domaine lui-même, comme les champs d'enregistrement RDAP et les types d'enregistrement DNS tels que A, AAAA, NS, MX et TXT. Il n'effectue pas de recherche IP inversée pour énumérer d'autres domaines hébergés sur la même adresse, ce qui nécessite soit un ensemble de données IP inversée ou DNS passif spécialisé, soit une coopération directe du fournisseur d'hébergement. Il n'effectue pas non plus de recherche DNS inversée (PTR) d'une adresse IP arbitraire, car il s'agit d'une requête distincte contre la zone in-addr.arpa ou ip6.arpa pour l'adresse plutôt que d'un enregistrement publié par le propriétaire du domaine.

Les preuves d'authentification des courriels ont une limite similaire : un rapport de domaine peut récupérer et évaluer les enregistrements TXT SPF et DMARC publiés pour un domaine, et peut confirmer une politique MTA-STS si elle est publiée, mais il ne découvre pas les sélecteurs DKIM, car il n'existe pas de liste publique et énumérable des sélecteurs qu'un domaine pourrait utiliser. La recherche du sélecteur DKIM réellement utilisé pour un message donné nécessite la lecture de l'en-tête DKIM-Signature de cet e-mail spécifique préservé, qui nomme directement le sélecteur et le domaine de signature.

Anonymisation, services de confidentialité et juridiction

Depuis l'entrée en vigueur de règles de protection des données telles que le RGPD, la plupart des résultats WHOIS et RDAP pour les domaines génériques de premier niveau omettent les détails personnels de l'enregistrant ou les remplacent par un service de confidentialité ou de proxy, que le domaine soit utilisé légitimement ou abusivement. Les domaines de premier niveau nationaux varient considérablement quant à ce qu'ils publient et par quelle méthode d'accès, et certains exigent une présence locale ou une base légale déclarée pour obtenir ne serait-ce que les données du pays de l'enregistrant. Rien de tout cela ne constitue une preuve de dissimulation en soi ; c'est l'état par défaut du registre public pour la grande majorité des domaines aujourd'hui.

Travailler dans les limites

Une enquête sérieuse traite un rapport public WHOIS, RDAP, DNS, de transparence des certificats et RDAP réseau comme une couche de preuve parmi plusieurs, indique clairement les questions auxquelles elle n'a pas pu répondre, et dirige l'enquêteur vers la source spécialisée appropriée, les fournisseurs DNS historiques, les ensembles de données IP inverse ou DNS passif, l'e-mail préservé lui-même pour DKIM, ou une requête PTR directe pour une adresse, plutôt que de deviner ou de traiter une absence de données comme une conclusion en soi.

  • Traitez une consultation comme un instantané horodaté, non comme un historique.
  • Utilisez un fournisseur DNS/WHOIS historique dédié pour les questions d'évolution dans le temps.
  • Utilisez une source spécialisée de recherche IP inversée ou de DNS passif pour trouver les domaines co-hébergés.
  • Lire l'en-tête DKIM-Signature de l'e-mail conservé pour le sélecteur et le domaine.
  • Interroger directement in-addr.arpa/ip6.arpa pour les enregistrements PTR d'une IP spécifique.
  • Attendez-vous à une rédaction (masquage) sur la plupart des enregistrements WHOIS/RDAP et ne considérez pas cela comme suspect en soi.

Sources et lectures complémentaires

ICANN, protocole d'accès aux données d'enregistrementICANN, politique de données d'enregistrementRFC 6376, Signatures DKIM (DomainKeys Identified Mail)RFC 8461, Sécurité stricte du transport MTA SMTP (MTA-STS)
Cette ressource soutient le triage d'enquête. Il ne s'agit pas d'un avis juridique, d'une constatation d'attribution ou d'une certification qu'un site web est sûr.