¿Es un robot quien dice ser? Reverse DNS y rangos de IP publicados
Un user-agent es una cadena de caracteres que cualquier cliente HTTP puede declarar. Un script que se presenta como «Googlebot» o «GPTBot» no es ni lo uno ni lo otro a nuestros ojos mientras no se haya comprobado. La cuestión cuenta en los dos sentidos: para no bloquear un robot de búsqueda auténtico creyendo bloquear a un imitador, y para no dejar pasar un scraper que suplanta un nombre respetable. Los grandes operadores de robots publican todos un método de verificación, y esos métodos difieren.
Dos familias de verificación
El primer método es el reverse DNS: se toma la dirección IP de la petición, se pide al DNS el nombre de host asociado, se comprueba que ese nombre pertenece a un dominio anunciado por el operador, después se resuelve ese nombre en una dirección IP y se verifica que se vuelve a la dirección de partida. Esa doble resolución impide que un tercero se atribuya un dominio que no controla, aunque domine el reverse DNS de su dirección.
El segundo método es la lista de direcciones publicada: el operador mantiene un fichero, por lo general en JSON, con los rangos de IP desde los que salen sus robots. Basta con comprobar que la dirección de la petición pertenece a uno de esos rangos. Es más rápido de automatizar y no depende del DNS, pero hay que refrescar la lista con regularidad.
Quién publica qué
| Operador | Método | Fuente oficial |
|---|---|---|
| Reverse DNS (dominios googlebot.com, google.com, googleusercontent.com) y listas de IP en JSON | Verificar las peticiones de Google | |
| OpenAI | Listas de IP en JSON, una por robot | Documentación de los robots de OpenAI, con searchbot.json, chatgpt-user.json y los rangos de GPTBot |
| Anthropic | Lista de IP en JSON | claude.com/crawling/bots.json |
| Perplexity | Lista de IP en JSON | perplexitybot.json, descrito en la documentación de los crawlers |
| Bing | Reverse DNS (search.msn.com) y herramienta de verificación | Cómo verificar Bingbot |
| Apple | Reverse DNS (applebot.apple.com) | Acerca de Applebot |
Casi todos estos ficheros siguen el mismo esquema, popularizado por Google: una matriz de prefijos IPv4 e IPv6 con una fecha de creación. Un script que sabe leer uno sabe leer los demás. La fecha de creación merece leerse: dice cuándo se produjo la lista por última vez. Una lista de hace varios meses no es falsa por ello (los rangos de los grandes operadores evolucionan despacio), pero justifica una verificación por reverse DNS en caso de duda sobre una dirección ausente.
Las trampas que aparecen en la práctica
- La URL buena, la respuesta mala. Algunas páginas de documentación responden 200 con HTML cuando se esperaba JSON, porque la dirección ha cambiado o porque una redirección lleva a una página de inicio. Un script que solo prueba el código HTTP creerá tener una lista al día. Hay que comprobar el tipo de contenido y la presencia de la matriz de prefijos.
- No hay IPv6 en todas partes. Algunos operadores solo publican rangos IPv4. Una petición llegada de una dirección IPv6 con el user-agent correcto no puede confirmarse con la lista, y eso no la convierte en una suplantación. Hay que prever ese caso en lugar de bloquear por defecto.
- El cortafuegos por delante. Si un CDN o un cortafuegos aplicativo filtra el tráfico antes que el servidor, la dirección que se ve en los logs puede ser la del CDN y no la del robot, salvo que una cabecera transporte la IP de origen. Los grandes CDN colocan una por defecto, pero una capa intermedia puede sobrescribirla. Volvemos sobre ello en el artículo sobre el punto ciego de los bloqueos en el edge.
El método, paso a paso
Para comprobar a mano una petición sospechosa:
- Anotar la dirección IP y el user-agent en el log.
- Si el operador publica una lista, descargar el JSON del día y probar si la dirección pertenece a alguno de los prefijos. Una dirección fuera de la lista con un user-agent de operador es una suplantación, salvo en el caso IPv6 no cubierto.
- Si el operador usa reverse DNS, resolver la dirección en un nombre de host, comprobar el dominio, después resolver ese nombre en una dirección y comparar. Las dos resoluciones deben concordar.
- Registrar el resultado. Un registro de las suplantaciones detectadas es útil para ajustar el cortafuegos y para justificarse el día en que el operador de un robot discuta un bloqueo.
Para automatizarlo, más vale refrescar las listas cada día, guardar la versión anterior por si falla la descarga y no bloquear nunca una dirección ausente de una lista sin haberla verificado por reverse DNS: los rangos evolucionan, y un robot auténtico llegado desde un rango nuevo pasaría por impostor.
Lo que estas listas dicen también de las funciones
OpenAI publica una lista por robot: una para OAI-SearchBot, una para ChatGPT-User y una para GPTBot. Esa separación no es un detalle de organización. Permite saber, dirección a dirección, si una petición venía de la indexación de la búsqueda, de una lectura pedida por un usuario en una conversación, o de una recopilación para el entrenamiento. Tres usos que un editor puede querer tratar de forma distinta, y que un simple filtro sobre la palabra «GPT» confunde. Anthropic agrupa sus robots en un solo fichero pero distingue en él las funciones de la misma manera. Un log de rastreo que solo conserva el nombre del robot pierde esa información; un registro que conserva la dirección permite reconstruirla después.
Qué hacer con un impostor
Un cliente que se hace pasar por Googlebot no es forzosamente malicioso: herramientas SEO, sondas de supervisión y scripts internos lo hacen por comodidad. Pero consume recursos y falsea las estadísticas de rastreo. Se le puede dejar pasar contándolo aparte en los informes, limitar su ritmo o bloquearlo en el cortafuegos. La elección depende de lo que publique el sitio y de la carga observada. Un medio que vende información tiene razones para bloquear; un medio que vive de su visibilidad tiene razones para dejar pasar y medir. Lo que no hay que hacer es bloquear una firma entera, por ejemplo todo lo que contenga «bot», con el riesgo de excluir a los robots auténticos que justamente se quería acoger.
Por qué un medio debe ocuparse de esto
Un sitio corporativo puede ignorar la cuestión. Un medio que aspira a ser citado por los motores generativos no puede. La primera razón es defensiva: las suplantaciones de robots de IA son frecuentes, y un bloqueo mal ajustado que las persiga alcanza a menudo también a los auténticos. La segunda es analítica: medir lo que las IA hacen realmente con un sitio supone saber, petición a petición, qué robot ha venido, con qué función y si era auténtico. Sin esa verificación, una curva de «visitas de robots de IA» cuenta también a los imitadores. La lectura de los logs que permite esa medición se describe en «Leer un access log en 30 minutos», y la lista de los robots en «robots.txt e IA».
Escrito por
Yann Léguillon
Presidente de Mazette, la editora de Joornal. Acompaña a empresas que construyen su propio medio: estructuración editorial, visibilidad en los buscadores y en las IA, producción a escala.