Um robot é mesmo quem diz ser? Reverse DNS e gamas de IP publicadas

Um user-agent é uma cadeia de caracteres que qualquer cliente HTTP pode declarar. Um script que se apresenta como «Googlebot» ou «GPTBot» não é nem um nem outro aos nossos olhos enquanto não o tivermos verificado. A questão conta nos dois sentidos: para não bloquear um verdadeiro robot de pesquisa julgando bloquear um imitador, e para não deixar passar um scraper que usurpa um nome respeitável. Os grandes fornecedores de robots publicam todos um método de verificação, e esses métodos diferem.

Duas famílias de verificação

O primeiro método é o reverse DNS: pega-se no endereço IP do pedido, pergunta-se ao DNS o nome de host associado, verifica-se que esse nome pertence a um domínio anunciado pelo fornecedor, depois resolve-se esse nome num endereço IP e verifica-se que se volta ao endereço de partida. Esta dupla resolução impede um terceiro de se reclamar de um domínio que não controla, mesmo que domine o reverse DNS do seu endereço.

O segundo método é a lista de endereços publicada: o fornecedor mantém um ficheiro, em regra em JSON, com as gamas de IP de onde partem os seus robots. Verifica-se simplesmente que o endereço do pedido pertence a uma dessas gamas. É mais rápido de automatizar e não depende do DNS, mas obriga a refrescar a lista com regularidade.

Quem publica o quê

Estes ficheiros seguem quase todos o mesmo esquema, popularizado pela Google: uma lista de prefixos IPv4 e IPv6 com uma data de criação. Um script que sabe ler um sabe ler os outros. A data de criação merece ser lida: diz quando a lista foi produzida pela última vez. Uma lista datada de vários meses não fica falsa por isso (as gamas dos grandes fornecedores evoluem devagar), mas justifica uma verificação por reverse DNS em caso de dúvida sobre um endereço ausente.

As armadilhas encontradas na prática

1. O URL certo, a resposta errada. Certas páginas de documentação respondem 200 com HTML quando se esperava JSON, porque o endereço mudou ou porque um redirecionamento leva a uma página de entrada. Um script que testa apenas o código HTTP julgará ter uma lista atualizada. Há que verificar o tipo de conteúdo e a presença da lista de prefixos.
2. Nem sempre há IPv6. Certos fornecedores só publicam gamas IPv4. Um pedido vindo de um endereço IPv6 com o user-agent certo não pode então ser confirmado pela lista, o que não faz dele uma usurpação. Há que prever este caso em vez de bloquear por omissão.
3. A firewall a montante. Se um CDN ou uma firewall aplicacional filtra o tráfego antes do servidor, o endereço visto nos logs pode ser o do CDN e não o do robot, salvo se um cabeçalho transportar o IP de origem. Os grandes CDN colocam um por omissão, mas uma camada intermédia pode sobrescrevê-lo. Voltamos ao assunto no artigo sobre o ponto cego dos bloqueios em edge.

O método, passo a passo

Para verificar à mão um pedido suspeito:

1. Anotar o endereço IP e o user-agent no log.
2. Se o fornecedor publica uma lista, descarregar o JSON do dia e testar a pertença do endereço a um dos prefixos. Um endereço fora da lista com um user-agent de fornecedor é uma usurpação, salvo no caso IPv6 não coberto.
3. Se o fornecedor usa o reverse DNS, resolver o endereço num nome de host, verificar o domínio, depois resolver esse nome num endereço e comparar. As duas resoluções têm de concordar.
4. Registar o resultado. Um registo das usurpações detetadas é útil para afinar a firewall e para se justificar, no dia em que o operador de um robot conteste um bloqueio.

Para automatizar, mais vale refrescar as listas todos os dias, guardar a versão anterior em caso de falha de descarregamento, e nunca bloquear um endereço ausente de uma lista sem o ter verificado por reverse DNS: as gamas evoluem, e um verdadeiro robot que chegasse de uma gama nova passaria por impostor.

O que estas listas dizem também dos papéis

A OpenAI publica uma lista por robot: uma para o OAI-SearchBot, uma para o ChatGPT-User, uma para o GPTBot. Esta separação não é um pormenor de organização. Permite saber, endereço a endereço, se um pedido vinha da indexação da pesquisa, de uma leitura pedida por um utilizador numa conversa, ou de uma recolha para o treino. São três usos que um editor pode querer tratar de forma diferente, e que um simples filtro sobre a palavra «GPT» confunde. A Anthropic reúne os seus robots num único ficheiro, mas distingue neles os papéis da mesma maneira. Um log de crawl que só conserva o nome do robot perde esta informação; um registo que conserva o endereço permite reconstituí-la depois.

Que fazer com um impostor

Um cliente que se faz passar por Googlebot não é forçosamente malicioso: ferramentas de SEO, sondas de monitorização e scripts internos fazem-no por facilidade. Mas consome recursos e falseia as estatísticas de crawl. Pode deixar-se passar, contando-o à parte nos relatórios, abrandar-se ou bloquear-se ao nível da firewall. A escolha depende do que o site publica e da carga observada. Um meio de comunicação que vende informação tem razões para bloquear; um que vive da sua visibilidade tem razões para deixar passar e medir. O que não se deve fazer é bloquear uma assinatura inteira, por exemplo tudo o que contém «bot», com o risco de excluir os verdadeiros robots que justamente se queria acolher.

Por que razão um meio de comunicação deve preocupar-se com isto

Um site institucional pode ignorar a questão. Um meio de comunicação que visa a citação pelos motores generativos não pode. Uma primeira razão é defensiva: as usurpações de robots de IA são correntes, e um bloqueio mal afinado que as vise atinge muitas vezes também os verdadeiros. Uma segunda é analítica: medir o que as IA fazem realmente de um site supõe saber, pedido a pedido, que robot veio, com que papel, e se era autêntico. Sem essa verificação, uma curva de «visitas de robots de IA» conta também os imitadores. A leitura dos logs que permite esta medição está descrita em «Ler um access log em 30 minutos», e a lista dos próprios robots em «robots.txt e IA».