Un robot est-il bien celui qu'il prétend être ? Reverse DNS et plages d'IP publiées

Un user-agent est une chaîne de caractères que n'importe quel client HTTP peut déclarer. Un script qui se présente comme « Googlebot » ou « GPTBot » n'est ni l'un ni l'autre à nos yeux tant qu'on ne l'a pas vérifié. La question compte dans les deux sens : pour ne pas bloquer un vrai robot de recherche en croyant bloquer un imitateur, et pour ne pas laisser passer un scraper qui usurpe un nom respectable. Les grands éditeurs de robots publient tous une méthode de vérification, et ces méthodes diffèrent.

Deux familles de vérification

La première méthode est le reverse DNS : on prend l'adresse IP de la requête, on demande au DNS le nom d'hôte associé, on vérifie que ce nom appartient à un domaine annoncé par l'éditeur, puis on résout ce nom en une adresse IP et on vérifie qu'on retombe sur l'adresse de départ. Cette double résolution empêche un tiers de se réclamer d'un domaine qu'il ne contrôle pas, même s'il maîtrise le reverse DNS de son adresse.

La seconde méthode est la liste d'adresses publiée : l'éditeur maintient un fichier, en général en JSON, avec les plages d'IP d'où partent ses robots. On vérifie simplement que l'adresse de la requête appartient à l'une de ces plages. C'est plus rapide à automatiser et cela ne dépend pas du DNS, mais il faut rafraîchir la liste régulièrement.

Qui publie quoi

Ces fichiers suivent presque tous le même schéma, popularisé par Google : un tableau de préfixes IPv4 et IPv6 avec une date de création. Un script qui sait lire l'un sait lire les autres. La date de création mérite d'être lue : elle dit quand la liste a été produite pour la dernière fois. Une liste datée de plusieurs mois n'est pas fausse pour autant (les plages des grands éditeurs évoluent lentement), mais elle justifie une vérification par reverse DNS en cas de doute sur une adresse absente.

Les pièges rencontrés en pratique

1. La bonne URL, la mauvaise réponse. Certaines pages de documentation répondent 200 avec du HTML alors qu'on attendait du JSON, parce que l'adresse a changé ou qu'une redirection mène vers une page d'accueil. Un script qui teste seulement le code HTTP croira avoir une liste à jour. Il faut vérifier le type de contenu et la présence du tableau de préfixes.
2. Pas d'IPv6 partout. Certains éditeurs ne publient que des plages IPv4. Une requête venue d'une adresse IPv6 avec le bon user-agent ne peut alors pas être confirmée par la liste, ce qui n'en fait pas une usurpation. Il faut prévoir ce cas plutôt que de bloquer par défaut.
3. Le pare-feu en amont. Si un CDN ou un pare-feu applicatif filtre le trafic avant le serveur, l'adresse vue dans les logs peut être celle du CDN et non celle du robot, sauf si un en-tête transporte l'IP d'origine. Les grands CDN en posent un par défaut, mais une couche intermédiaire peut l'écraser. Nous y revenons dans l'article sur l'angle mort des blocages en edge.

La méthode, pas à pas

Pour vérifier une requête suspecte à la main :

1. Relever l'adresse IP et le user-agent dans le log.
2. Si l'éditeur publie une liste, télécharger le JSON du jour et tester l'appartenance de l'adresse à l'un des préfixes. Une adresse hors liste avec un user-agent d'éditeur est une usurpation, sauf cas IPv6 non couvert.
3. Si l'éditeur utilise le reverse DNS, résoudre l'adresse en un nom d'hôte, vérifier le domaine, puis résoudre ce nom en une adresse et comparer. Les deux résolutions doivent concorder.
4. Consigner le résultat. Un journal des usurpations détectées est utile pour régler le pare-feu et pour se justifier, le jour où l'exploitant d'un robot conteste un blocage.

Pour automatiser, mieux vaut rafraîchir les listes chaque jour, garder la version précédente en cas d'échec de téléchargement, et ne jamais bloquer une adresse absente d'une liste sans l'avoir vérifiée par reverse DNS : les plages évoluent, et un vrai robot arrivant d'une nouvelle plage serait pris pour un imposteur.

Ce que ces listes disent aussi des rôles

OpenAI publie une liste par robot : une pour OAI-SearchBot, une pour ChatGPT-User, une pour GPTBot. Cette séparation n'est pas un détail d'organisation. Elle permet de savoir, adresse par adresse, si une requête venait de l'indexation de la recherche, d'une lecture demandée par un utilisateur dans une conversation, ou d'une collecte pour l'entraînement. Trois usages qu'un éditeur peut vouloir traiter différemment, et qu'un simple filtre sur le mot « GPT » confond. Anthropic regroupe ses robots dans un seul fichier mais y distingue les rôles de la même manière. Un log de crawl qui ne conserve que le nom du robot perd cette information ; un journal qui conserve l'adresse permet de la reconstituer après coup.

Que faire d'un imposteur

Un client qui se fait passer pour Googlebot n'est pas forcément malveillant : des outils SEO, des sondes de supervision et des scripts internes le font par facilité. Mais il consomme des ressources et fausse les statistiques de crawl. On peut le laisser passer en le comptant à part dans les rapports, le ralentir, ou le bloquer au niveau du pare-feu. Le choix dépend de ce que le site publie et de la charge observée. Un média qui vend de l'information a des raisons de bloquer ; un média qui vit de sa visibilité a des raisons de laisser passer et de mesurer. Ce qu'il ne faut pas faire, c'est bloquer une signature entière, par exemple tout ce qui contient « bot », au risque d'exclure les vrais robots qu'on voulait justement accueillir.

Pourquoi un média doit s'en préoccuper

Un site vitrine peut ignorer la question. Un média qui vise la citation par les moteurs génératifs ne le peut pas. Vérifier l'identité d'un robot sert à deux choses. La première est défensive : les usurpations de robots d'IA sont courantes, et un blocage mal réglé qui les vise atteint souvent aussi les vrais. La seconde est analytique : mesurer ce que les IA font réellement d'un site suppose de savoir, requête par requête, quel robot est venu, avec quel rôle, et s'il était authentique. Sans cette vérification, une courbe de « visites de robots d'IA » compte aussi les imitateurs. La lecture des logs qui permet cette mesure est décrite dans « Lire un access log en 30 minutes », et la liste des robots eux-mêmes dans « robots.txt et IA ».