Ist ein Bot wirklich der, für den er sich ausgibt? Reverse DNS und veröffentlichte IP-Bereiche

Ein User-Agent ist eine Zeichenkette, die jeder HTTP-Client angeben kann. Ein Skript, das sich als „Googlebot“ oder „GPTBot“ ausgibt, ist für uns weder das eine noch das andere, solange es nicht überprüft wurde. Die Frage zählt in beide Richtungen: um keinen echten Such-Bot zu sperren im Glauben, einen Nachahmer zu sperren, und um keinen Scraper durchzulassen, der sich einen respektablen Namen anmaßt. Die großen Bot-Anbieter veröffentlichen alle eine Prüfmethode, und diese Methoden unterscheiden sich.

Zwei Familien der Überprüfung

Die erste Methode ist das Reverse DNS: Man nimmt die IP-Adresse der Anfrage, fragt das DNS nach dem zugehörigen Hostnamen, prüft, ob dieser Name zu einer vom Anbieter angekündigten Domain gehört, löst dann diesen Namen in eine IP-Adresse auf und prüft, ob man wieder bei der Ausgangsadresse landet. Diese doppelte Auflösung hindert einen Dritten daran, sich auf eine Domain zu berufen, die er nicht kontrolliert, selbst wenn er das Reverse DNS seiner Adresse beherrscht.

Die zweite Methode ist die veröffentlichte Adressliste: Der Anbieter pflegt eine Datei, meist im JSON-Format, mit den IP-Bereichen, aus denen seine Bots kommen. Man prüft schlicht, ob die Adresse der Anfrage zu einem dieser Bereiche gehört. Das ist schneller zu automatisieren und hängt nicht vom DNS ab, aber die Liste muss regelmäßig aufgefrischt werden.

Wer was veröffentlicht

Diese Dateien folgen fast alle demselben Schema, das Google bekannt gemacht hat: ein Array von IPv4- und IPv6-Präfixen mit einem Erstellungsdatum. Ein Skript, das eine davon lesen kann, kann auch die anderen lesen. Das Erstellungsdatum verdient einen Blick: Es sagt, wann die Liste zuletzt erzeugt wurde. Eine mehrere Monate alte Liste ist deshalb nicht falsch (die Bereiche der großen Anbieter ändern sich langsam), aber sie rechtfertigt eine Überprüfung per Reverse DNS, wenn eine fehlende Adresse Zweifel weckt.

Die Fallen aus der Praxis

1. Die richtige URL, die falsche Antwort. Manche Dokumentationsseiten antworten mit 200 und HTML, wo JSON erwartet wurde, weil die Adresse sich geändert hat oder eine Weiterleitung auf eine Startseite führt. Ein Skript, das nur den HTTP-Code prüft, glaubt, eine aktuelle Liste zu haben. Zu prüfen sind der Inhaltstyp und das Vorhandensein des Präfix-Arrays.
2. Nicht überall IPv6. Manche Anbieter veröffentlichen nur IPv4-Bereiche. Eine Anfrage von einer IPv6-Adresse mit dem richtigen User-Agent lässt sich dann über die Liste nicht bestätigen, was sie noch nicht zu einer Fälschung macht. Dieser Fall gehört eingeplant, statt standardmäßig zu sperren.
3. Die vorgelagerte Firewall. Filtert ein CDN oder eine Application-Firewall den Traffic vor dem Server, kann die in den Logs sichtbare Adresse die des CDN sein und nicht die des Bots, sofern kein Header die Ursprungs-IP transportiert. Die großen CDN setzen einen solchen Header standardmäßig, aber eine Zwischenschicht kann ihn überschreiben. Darauf kommen wir im Artikel über den blinden Fleck der Blockaden am Edge zurück.

Die Methode, Schritt für Schritt

Um eine verdächtige Anfrage von Hand zu prüfen:

1. Die IP-Adresse und den User-Agent im Log erfassen.
2. Veröffentlicht der Anbieter eine Liste, das JSON des Tages herunterladen und prüfen, ob die Adresse zu einem der Präfixe gehört. Eine Adresse außerhalb der Liste mit dem User-Agent eines Anbieters ist eine Fälschung, außer im nicht abgedeckten IPv6-Fall.
3. Nutzt der Anbieter das Reverse DNS, die Adresse in einen Hostnamen auflösen, die Domain prüfen, dann diesen Namen in eine Adresse auflösen und vergleichen. Die beiden Auflösungen müssen übereinstimmen.
4. Das Ergebnis festhalten. Ein Protokoll der erkannten Fälschungen hilft beim Einstellen der Firewall und bei der eigenen Rechtfertigung an dem Tag, an dem der Betreiber eines Bots eine Sperre bestreitet.

Zur Automatisierung empfiehlt es sich, die Listen täglich aufzufrischen, die vorherige Fassung für den Fall eines fehlgeschlagenen Downloads aufzubewahren und nie eine Adresse zu sperren, die in einer Liste fehlt, ohne sie per Reverse DNS überprüft zu haben: Die Bereiche ändern sich, und ein echter Bot aus einem neuen Bereich würde für einen falschen gehalten.

Was diese Listen auch über die Rollen sagen

OpenAI veröffentlicht eine Liste je Bot: eine für OAI-SearchBot, eine für ChatGPT-User, eine für GPTBot. Diese Trennung ist kein Organisationsdetail. Sie erlaubt, Adresse für Adresse zu erkennen, ob eine Anfrage von der Indexierung für die Suche kam, von einem Abruf, den ein Nutzer in einem Gespräch verlangt hat, oder von einer Sammlung für das Training. Drei Verwendungen, die ein Herausgeber unterschiedlich behandeln möchte und die ein einfacher Filter auf das Wort „GPT“ vermengt. Anthropic fasst seine Bots in einer einzigen Datei zusammen, unterscheidet die Rollen darin aber genauso. Ein Crawl-Log, das nur den Namen des Bots aufbewahrt, verliert diese Information; ein Protokoll, das die Adresse aufbewahrt, erlaubt sie im Nachhinein zu rekonstruieren.

Was tun mit einem falschen Bot

Ein Client, der sich als Googlebot ausgibt, ist nicht zwangsläufig bösartig: SEO-Werkzeuge, Monitoring-Sonden und interne Skripte tun es aus Bequemlichkeit. Aber er verbraucht Ressourcen und verfälscht die Crawl-Statistiken. Man kann ihn durchlassen und in den Berichten getrennt zählen, ihn ausbremsen oder ihn auf Firewall-Ebene sperren. Die Wahl hängt davon ab, was die Website veröffentlicht, und von der beobachteten Last. Ein Medium, das Information verkauft, hat Gründe zu sperren; ein Medium, das von seiner Sichtbarkeit lebt, hat Gründe durchzulassen und zu messen. Was man nicht tun sollte, ist eine ganze Signatur zu sperren, zum Beispiel alles, was „bot“ enthält, auf die Gefahr hin, gerade die echten Bots auszuschließen, die man empfangen wollte.

Warum ein Medium sich darum kümmern muss

Eine Unternehmenswebsite kann die Frage übergehen. Ein Medium, das die Zitierung durch generative Engines anstrebt, kann es nicht. Der erste Grund ist defensiv: Fälschungen von KI-Bots sind verbreitet, und eine schlecht eingestellte Sperre gegen sie trifft oft auch die echten. Der zweite Grund ist analytisch: Zu messen, was KI-Dienste wirklich mit einer Website machen, setzt voraus zu wissen, Anfrage für Anfrage, welcher Bot gekommen ist, in welcher Rolle, und ob er echt war. Ohne diese Überprüfung zählt eine Kurve der „Besuche von KI-Bots“ auch die Nachahmer mit. Das Lesen der Logs, das diese Messung erlaubt, ist in „Ein Access-Log in 30 Minuten lesen“ beschrieben, die Liste der Bots selbst in „robots.txt und KI“.