En bref. Baidu documente *.baidu.com et *.baidu.jp pour les vérifications par DNS inverse de Baiduspider.

Définition : Baidu indique *.baidu.com et *.baidu.jp comme modèles de noms d’hôte obtenus par DNS inverse (reverse DNS) pour Baiduspider. Sa vérification d’authenticité commence par une résolution inverse de l’adresse IP de la requête et considère tout nom d’hôte qui ne correspond à aucun de ces modèles comme une usurpation d’identité.

Points clés

Baidu décrit Baiduspider comme le programme automatique de son moteur de recherche qui visite les pages web et constitue une base de données d’indexation. La présentation de Baiduspider par Baidu donne cette définition.
La page indique *.baidu.com et *.baidu.jp comme modèles de noms d’hôte pour Baiduspider et qualifie d’usurpation d’identité tout nom d’hôte qui ne correspond à aucun des deux modèles.
Baidu documente les commandes de résolution inverse host pour Linux, nslookup pour Windows ou IBM OS/2 et dig pour macOS.
La RFC 1035 définit le domaine IN-ADDR.ARPA pour associer des adresses Internet à des noms d’hôte et indique que les enregistrements PTR pointent vers des noms d’hôte principaux.
La RFC 1912 recommande la concordance des enregistrements PTR et A, l’enregistrement PTR devant pointer vers un enregistrement A valide.

Quels suffixes de nom d’hôte Baidu indique-t-il ?

La page de Baidu, datée du 24 avril 2013, donne les deux modèles suivants dans sa section consacrée à l’identification d’un faux robot d’exploration :

*.baidu.com
*.baidu.jp

L’astérisque et le point font partie des modèles présentés par Baidu. La page indique qu’un nom d’hôte de Baiduspider suit l’un de ces deux formats et qu’un nom d’hôte qui ne correspond à aucun des deux relève de l’usurpation d’identité. Les deux exemples de la page montrent un nom de robot sous crawl.baidu.com et un autre sous crawl.baidu.jp :

baiduspider-123-125-66-120.crawl.baidu.com.
BaiduMobaider-119-63-195-254.crawl.baidu.jp.

Le second exemple conserve l’orthographe figurant dans la sortie de commande de Baidu. Le point final est également présent dans cette sortie.

Comment fonctionne la vérification par DNS inverse ?

Le DNS inverse associe une adresse IP à un nom d’hôte au moyen d’une recherche d’enregistrement PTR. La RFC 1035 décrit IN-ADDR.ARPA comme un domaine spécial destiné à associer les adresses Internet aux noms d’hôte. Les étiquettes de l’adresse suivent la structure d’adressage Internet dans l’ordre inverse, et la RFC donne 52.0.2.10.IN-ADDR.ARPA pour l’adresse 10.2.0.52. Les enregistrements PTR pointent du nœud correspondant à l’adresse vers un nom d’hôte principal.

Les commandes documentées par Baidu sont les suivantes :

host 123.125.66.120
nslookup xxx.xxx.xxx.xxx
dig xxx.xxx.xxx.xxx

La page associe la première commande à Linux, la deuxième à Windows ou IBM OS/2 et la troisième à macOS. Le résultat de la recherche fournit le nom d’hôte à comparer aux deux modèles de Baidu.

La RFC 1035 distingue également cette méthode des requêtes DNS de type « inverse query ». Elle indique que ces requêtes ne constituent pas une méthode acceptable pour associer les adresses d’hôte aux noms d’hôte et demande aux implémentations d’utiliser IN-ADDR.ARPA.

Quelle seconde vérification les recommandations DNS préconisent-elles ?

La page de Baidu précise la comparaison des noms d’hôte. La RFC 1912 ajoute une vérification de cohérence DNS : pour chaque adresse IP, un enregistrement PTR correspondant devrait exister dans in-addr.arpa, et cet enregistrement PTR devrait pointer en retour vers un enregistrement A valide. Cela fournit une seconde recherche à effectuer après qu’un nom d’hôte obtenu correspond à un suffixe de Baidu.

La RFC 1035 avertit que les données de résolution inverse et celles de résolution directe des noms d’hôte peuvent être incohérentes, car elles se trouvent dans des zones différentes. L’examen des journaux peut donc consigner séparément l’adresse IP de la requête, le résultat PTR et le résultat A de la résolution directe. La page de Baidu demande également aux exploitants d’examiner les journaux d’accès pour vérifier si quelqu’un usurpe l’identité de Baiduspider.

Comment un exploitant de site doit-il appliquer la vérification ?

La procédure commence par l’adresse IP figurant dans le journal d’accès. Elle consiste à exécuter la commande de la plateforme, à examiner le nom d’hôte PTR et à comparer le nom complet à *.baidu.com ou *.baidu.jp. Il faut ensuite résoudre ce nom d’hôte et comparer l’enregistrement A obtenu à l’adresse IP consignée, conformément aux recommandations de cohérence de la RFC 1912. La page de Baidu précise les suffixes de nom d’hôte et les commandes ; elle ne fournit ni configuration de résolveur DNS ni procédure DNSSEC.

Termes associés

Questions fréquentes

Quels suffixes Baidu documente-t-il pour Baiduspider ?

Les modèles documentés sont *.baidu.com et *.baidu.jp. Baidu indique qu’un nom d’hôte qui ne correspond à aucun des deux modèles relève de l’usurpation d’identité.

Quelle commande devez-vous utiliser pour une résolution inverse ?

Utilisez host sur Linux, nslookup sur Windows ou IBM OS/2 et dig sur macOS, comme l’indique la page de Baidu.

Faut-il vérifier le résultat PTR par rapport à un enregistrement A ?

Oui. La RFC 1912 recommande que les enregistrements PTR et A concordent et qu’un enregistrement PTR pointe vers un enregistrement A valide. La page de Baidu fournit la comparaison des suffixes qui ouvre la vérification.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Quels suffixes de nom d’hôte Baidu documente-t-il pour le DNS inverse de son robot ?