Méthodes de vérification

Quatre contrôles revêtent une importance particulière dans les outils gratuits : le Forward-confirmed reverse DNS, la vérification par robot d'indexation, la correspondance de préfixes RDAP et les requêtes sur les Blacklists. Chacun d'entre eux comporte un raccourci qui semble correct lors des tests mais produit des réponses erronées en production. Cette page explique ce que font réellement les outils à la place, avec suffisamment de détails pour permettre de reproduire le phénomène.

Forward-confirmed reverse DNS

Un PTR Record ne prouve rien en soi. Celui qui contrôle un bloc d’adresses décide du nom qu’il porte, et rien n’empêche ce nom d’être mail.yourbank.com. La vérification qui a du poids est la confirmation directe : résoudre le nom PTR en arrière et voir si l’adresse d’origine figure parmi les résultats.

Comparez l’ensemble des adresses, et non le premier enregistrement

L’erreur courante consiste à comparer avec le premier enregistrement A renvoyé. Les adresses derrière un nom à rotation aléatoire échouent immédiatement à ce test :

8.8.8.8  ->  PTR dns.google
             ->  A     8.8.8.8, 8.8.4.4
             ->  AAAA  2001:4860:4860::8888, 2001:4860:4860::8844

8.8.4.4  ->  PTR dns.google
             ->  same four addresses

Un outil qui s’arrête à la première réponse signale 8.8.4.4 comme non confirmée, car le DNS a renvoyé 8.8.8.8 en premier. Environ une requête sur deux concernant un nom de type « round-robin » donne un résultat erroné de cette manière. Les ensembles A et AAAA doivent tous deux être résolus et parcourus.

Comparez les adresses sous forme binaire

La deuxième erreur consiste à comparer les adresses sous forme de chaînes de caractères. 2001:db8::1 et 2001:0db8:0000:0000:0000:0000:0000:0001 correspondent à la même adresse et ne partagent aucun caractère ; ::ffff:192.0.2.1 et 192.0.2.1 correspondent à la même adresse dans deux familles. Ces deux comparaisons doivent être effectuées sur la forme compactée renvoyée par la fonction inet_pton() renvoie, jamais sur la forme texte.

Que signifie un échec ?

Essayez avec Reverse DNS.

Vérification d’un robot d’indexation

Un en-tête User-Agent est un texte libre que n’importe quel client peut envoyer, c’est pourquoi tous les grands opérateurs publient une méthode de vérification. Pendant deux décennies, cette méthode consistait en un Forward-confirmed reverse DNS. Ce n’est plus le cas pour la moitié des robots d’indexation qui méritent d’être vérifiés.

La distinction se situe entre les moteurs de recherche classiques et la nouvelle génération de robots d’indexation basés sur l’IA. Les nouveaux opérateurs documentent les plages d’adresses via des fichiers JSON et n’intègrent pas les noms PTR dans leur méthode ; ainsi, une adresse comprise dans la plage publiée par OpenAI pour GPTBot ne comporte absolument aucun enregistrement inverse . Un vérificateur qui ne connaît que la méthode DNS marque chacune d’entre elles comme non confirmée, ce qui est le même verdict que celui qu’il attribue à un faux.

Trois verdicts sont donc distingués :

• Confirmé. Le nom appartient à un robot d’indexation connu et la méthode applicable à cet opérateur correspond.
• Non confirmé. Il n’y a pas de PTR Record, la vérification directe a échoué, ou l’User-Agent revendique un robot d’indexation que les preuves ne corroborent pas. C’est le cas qui nécessite une intervention.
• Non attribuable. Tout se résout correctement, mais l’adresse n’appartient à aucun robot d’indexation connu de cet outil. C’est le résultat normal pour un visiteur ordinaire.

Essayez-le sur la vérification des bots.

Recherche de la Registry responsable via RDAP

Un signalement abuse envoyé au mauvais bloc revient à ne pas envoyer de signalement abuse du tout. Une adresse unique se trouve généralement au sein de l’allocation d’un hébergeur, qui se trouve elle-même au sein de l’allocation d’un fournisseur de transit, laquelle appartient à un Registry régional. Seul l’opérateur le plus en amont peut déconnecter la machine du réseau.

Le fichier bootstrap, et non un redirecteur

Il n’existe pas de répertoire central de l’espace d’adressage. L’IANA publie un fichier de démarrage qui associe chaque préfixe attribué au Registry qui en est responsable, et ce fichier est bien plus petit que ne le suggèrent la plupart des estimations : mesuré le 20 septembre 2026, ipv4.json il faisait 5 629 octets et ipv6.json 1 476 octets. Une copie mise en cache quotidiennement est mise à la disposition de chaque visiteur ; ainsi, la recherche s'effectue directement auprès du Registry au lieu de faire transiter chaque requête par un redirecteur public.

Le préfixe le plus long, et non la première correspondance

Les préfixes se chevauchent. Une petite plage au sein d’une ancienne allocation de grande taille appartient fréquemment à un Registry différent de celui de son parent ; ainsi, le premier préfixe correspondant est souvent le mauvais. La correspondance doit être celle du préfixe le plus long.

Le contact ayant le rôle d’abus

Une réponse RDAP contient plusieurs entités de contact, et la première est généralement administrative plutôt qu'opérationnelle. L’adresse renvoyée par l’outil provient de l’entité qui assume le abuse rôle. Si un réseau n’en publie aucun, le résultat l’indique plutôt que de se rabattre sur un contact sans rapport : le Registry et le détenteur du bloc sont alors les prochains interlocuteurs à contacter.

Essayez cette fonction sur « Contact abuse » et consultez la section « IP Delisting » pour l’autre sens.

Requêtes de Blacklist

Le format de requête

Pour interroger une liste DNSBL, il faut inverser l’adresse et ajouter la zone à la fin. Pour IPv4, il s’agit des octets dans l’ordre inverse ; pour IPv6, la RFC 5782 spécifie le format par nibble, chaque chiffre hexadécimal séparément et à l’envers :

192.0.2.1        ->  1.2.0.192.<zone>
2001:db8::1      ->  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
                     0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.<zone>

Toutes les listes ne répondent pas pour IPv6

Neuf des douze listes gérées publient une zone IPv6 ; trois ne le font pas. L'interrogation d'une zone exclusivement IPv4 pour une adresse IPv6 renvoie NXDOMAIN, ce qui est impossible à distinguer d'un résultat « propre ». Ces trois listes ne sont donc pas interrogées du tout pour IPv6 et sont signalées comme non applicables ; ainsi, une réponse vide n'est jamais présentée comme un résultat positif.

La réponse des listes est vérifiée plutôt que supposée : chaque zone de l’ensemble répond à l’entrée de test RFC 5782 provenant du résolveur de ce serveur. Les listes qui, de par leur structure, ne peuvent pas être interrogées à partir d’un résolveur partagé sont exclues, parmi lesquelles Spamhaus ZEN, qui répond à un résolveur public par un code de blocage au lieu d’un résultat.

Interprétation du code de retour

Un résultat positif est signalé par un enregistrement A dans 127.0.0.0/8, et sa valeur exacte indique la raison. Une plage de codes ne correspond pas du tout à une liste : les codes 127.255.255.0/24 sont réservés aux erreurs de requête, à un résolveur public bloqué, à un dépassement de la Rate Limit ou à une requête mal formée. Les interpréter comme un résultat positif transforme un problème d’infrastructure en une fausse accusation.

Essayez-le sur DNSBL Blacklist Check. Notre propre zone est documentée sous la rubrique Zone DNSBL / RBL Zone.

Récupération d’une page en toute sécurité

La vérification des en-têtes est le seul outil qui récupère l'URL indiquée par le visiteur, ce qui en fait une vulnérabilité à la falsification de requêtes côté serveur. La récupération est donc restreinte :

• Uniquement http et https, uniquement les ports 80 et 443.
• Le nom d’hôte est résolu et chaque adresse renvoyée est vérifiée par rapport aux plages privées, de bouclage, locales de liaison, CGNAT et de multidiffusion, dans les deux familles d’adresses.
• Quatre notations contiennent une adresse IPv4 à l’intérieur d’une adresse IPv6, et toutes les quatre sont déballées avant la vérification des plages plutôt qu’après : v4-mapped, v4-compatible, NAT64 et 6to4. Un filtre qui ne vérifie que la forme textuelle les laisse passer, car 2002:7f00:1:: et 127.0.0.1 ne se ressemblent en rien bien qu’elles désignent le même hôte.
• Les redirections sont suivies manuellement, au maximum trois fois, la vérification complète étant répétée à chaque saut.
• Un délai d’expiration strict est appliqué, et seuls les premiers kilo-octets du corps sont lus.
• La requête utilise GET plutôt que HEAD, car un certain nombre de serveurs répondent à HEAD avec un ensemble d’en-têtes différent.

Testez-le sur les Security Headers. La manière dont les résultats sont convertis en un score est décrite dans la section « Notation de l’outil ».

Dernière mise à jour: 20. septembre 2026 · Maintenu par l’équipe ReportedIP