Is een bot echt wie hij beweert te zijn? Reverse DNS en gepubliceerde IP-reeksen

Een user-agent is een tekenreeks die elke HTTP-client kan opgeven. Een script dat zich voordoet als "Googlebot" of "GPTBot" is in onze ogen geen van beide zolang het niet is geverifieerd. De vraag telt in twee richtingen: om geen echte zoekbot te blokkeren in de veronderstelling dat je een nabootser blokkeert, en om geen scraper door te laten die een respectabele naam misbruikt. De grote aanbieders van bots publiceren allemaal een verificatiemethode, en die methoden verschillen.

Twee families van verificatie

De eerste methode is reverse DNS: je neemt het IP-adres van de request, vraagt het DNS om de bijbehorende hostnaam, controleert of die naam bij een domein hoort dat de aanbieder heeft aangekondigd, en lost die naam daarna op naar een IP-adres om na te gaan of je op het beginadres uitkomt. Die dubbele resolutie belet een derde partij om zich op een domein te beroepen dat zij niet beheert, ook al heeft zij de reverse DNS van haar eigen adres in handen.

De tweede methode is de gepubliceerde adreslijst: de aanbieder onderhoudt een bestand, meestal in JSON, met de IP-reeksen waaruit zijn bots vertrekken. Je gaat simpelweg na of het adres van de request in een van die reeksen valt. Dat is sneller te automatiseren en hangt niet van het DNS af, maar de lijst moet regelmatig worden ververst.

Wie wat publiceert

Die bestanden volgen bijna allemaal hetzelfde schema, populair gemaakt door Google: een reeks IPv4- en IPv6-prefixen met een aanmaakdatum. Een script dat er één kan lezen, kan ze allemaal lezen. Die aanmaakdatum verdient het om gelezen te worden: hij zegt wanneer de lijst voor het laatst is geproduceerd. Een lijst van enkele maanden oud is daarom nog niet fout (de reeksen van de grote aanbieders evolueren traag), maar hij rechtvaardigt wel een verificatie via reverse DNS bij twijfel over een adres dat er niet in staat.

De valkuilen die we in de praktijk tegenkwamen

1. De juiste URL, het verkeerde antwoord. Sommige documentatiepagina's antwoorden 200 met HTML terwijl je JSON verwachtte, omdat het adres is veranderd of omdat een redirect naar een homepage leidt. Een script dat alleen de HTTP-code test, denkt een actuele lijst te hebben. Je moet het contenttype controleren en nagaan of de reeks prefixen aanwezig is.
2. Niet overal IPv6. Sommige aanbieders publiceren alleen IPv4-reeksen. Een request die van een IPv6-adres komt met de juiste user-agent, kan dan niet door de lijst worden bevestigd, wat er nog geen vervalsing van maakt. Je moet dat geval voorzien in plaats van standaard te blokkeren.
3. De firewall vóór de server. Filtert een CDN of een applicatiefirewall het verkeer vóór de server, dan kan het adres dat je in de logs ziet dat van het CDN zijn en niet dat van de bot, tenzij een header het oorspronkelijke IP meedraagt. De grote CDN's zetten er standaard een, maar een tussenliggende laag kan die overschrijven. We komen erop terug in het artikel over de blinde vlek van blokkades aan de edge.

De methode, stap voor stap

Om een verdachte request met de hand te verifiëren:

1. Noteer het IP-adres en de user-agent uit het log.
2. Publiceert de aanbieder een lijst, download dan de JSON van die dag en test of het adres onder een van de prefixen valt. Een adres buiten de lijst met de user-agent van een aanbieder is een vervalsing, behalve in het niet-gedekte IPv6-geval.
3. Gebruikt de aanbieder reverse DNS, los het adres dan op naar een hostnaam, controleer het domein, los die naam vervolgens op naar een adres en vergelijk. De twee resoluties moeten overeenkomen.
4. Leg het resultaat vast. Een register van vastgestelde vervalsingen is nuttig om de firewall af te stellen en om je te verantwoorden op de dag dat de exploitant van een bot een blokkade betwist.

Voor de automatisering kun je de lijsten beter dagelijks verversen, de vorige versie bewaren voor het geval het downloaden mislukt, en nooit een adres blokkeren dat niet in een lijst staat zonder het via reverse DNS te hebben geverifieerd: de reeksen evolueren, en een echte bot die uit een nieuwe reeks komt, zou voor een bedrieger worden aangezien.

Wat die lijsten ook over de rollen zeggen

OpenAI publiceert één lijst per bot: één voor OAI-SearchBot, één voor ChatGPT-User, één voor GPTBot. Die scheiding is geen organisatorisch detail. Ze maakt het mogelijk om adres per adres te weten of een request van de indexering voor de zoekfunctie kwam, van een leesactie die een gebruiker in een gesprek had gevraagd, of van een verzameling voor de training. Drie toepassingen die een uitgever verschillend kan willen behandelen, en die een simpel filter op het woord "GPT" op één hoop gooit. Anthropic bundelt zijn bots in één bestand, maar onderscheidt de rollen daarin op dezelfde manier. Een crawllog dat alleen de naam van de bot bewaart, verliest die informatie; een log dat het adres bewaart, maakt het mogelijk om haar achteraf te reconstrueren.

Wat doen met een bedrieger

Een client die zich voor Googlebot uitgeeft, is niet per se kwaadwillig: SEO-tools, monitoringsondes en interne scripts doen het uit gemak. Maar hij verbruikt resources en vertekent de crawlstatistieken. Je kunt hem doorlaten en apart tellen in de rapporten, hem afremmen, of hem op de firewall blokkeren. De keuze hangt af van wat de site publiceert en van de waargenomen belasting. Een mediasite die informatie verkoopt, heeft redenen om te blokkeren; een mediasite die van haar zichtbaarheid leeft, heeft redenen om door te laten en te meten. Wat je niet moet doen, is een hele signatuur blokkeren, bijvoorbeeld alles wat "bot" bevat, met het risico dat je juist de echte bots uitsluit die je wilde ontvangen.

Waarom een mediasite zich hierom moet bekommeren

Een bedrijfssite kan de vraag negeren. Een mediasite die op citatie door generatieve engines mikt, kan dat niet. De eerste reden is defensief: vervalste AI-bots komen vaak voor, en een slecht afgestelde blokkade die daarop mikt, raakt vaak ook de echte. De tweede reden is analytisch: meten wat de AI's werkelijk met een site doen, veronderstelt dat je per request weet welke bot langskwam, met welke rol, en of hij authentiek was. Zonder die verificatie telt een curve van "bezoeken van AI-bots" ook de nabootsers mee. Het lezen van de logs dat die meting mogelijk maakt, wordt beschreven in "Een access log lezen in 30 minuten", en de lijst van de bots zelf in "robots.txt en AI".