Bot-Erkennung: IP-Listen und kryptografische Signaturen im Vergleich
Apple hat den Adressbestand hinter dem Applebot im August 2026 vergrößert. Berichtet wird ein Sprung von rund 2.400 Adressen über zwölf Präfixe auf etwa 7.056 über dreiunddreißig, und die veröffentlichte Bereichsliste gilt dort weiterhin als unvollständig. Jeder Auftritt, der diesen Crawler gegen eine gespeicherte Kopie der Liste prüft, musste eine neue holen – oder hat stillschweigend angefangen, einen berechtigten Crawler für einen Hochstapler zu halten.
Das ist kein Mangel dieser einen Ausgabe. Es ist die kennzeichnende Eigenschaft eines Identitätsnachweises über die Adresse, und sie lohnt einen Vergleich mit der Alternative mehr als eine Beschwerde.
Der Adressbeleg und seine selbstpflegende Spielart
Die einfachste Form ist eine Liste von Bereichen, die der Betreiber veröffentlicht und jeder Auftritt herunterlädt. Sie trägt, weil sich eine Absenderadresse über einen abgeschlossenen TCP-Handschlag nicht fälschen lässt – das macht sie zu einem echten Herkunftsbeleg statt zu einer Behauptung.
Vorwärts bestätigtes Reverse DNS ist derselbe Beleg mit verlagerter Pflege. Statt die Bereiche vorzuhalten, löst ein Auftritt die Adresse rückwärts auf, löst den erhaltenen Namen wieder vorwärts auf und prüft, ob er auf der Adresse landet, von der er ausging.
Adresse in der Anfrage 17.241.75.12
Rueckwaertsaufloesung -> irgendein.applebot.apple.com
Endungspruefung endet auf einer Domain des Betreibers
Vorwaertsaufloesung -> 17.241.75.12
Vergleich gleiche Adresse, also traegt die Angabe
faellt sicher aus: ein gefaelschter Rueckwaertseintrag
ueberlebt die Vorwaertsaufloesung nicht, weil der Angreifer
die Vorwaertszone des Betreibers nicht kontrolliertDiese Spielart kostet ein bis zwei DNS-Umläufe je neuer Adresse, danach zwischengespeichert, und sie veraltet nicht, wenn der Bestand wächst. Ein Adressbeleg bleibt sie trotzdem, mit allem, was daraus folgt.
Was eine Erweiterung tatsächlich kostet
Ein Bestand, der sich fast verdreifacht, erzeugt zwei Fehlerarten, und nur eine davon ist laut. Die laute ist ein blockierter Crawler, bemerkt binnen eines Tages, weil Inhalte nicht mehr aufgenommen werden. Die leise ist die schlimmere: Ein Auftritt, der ungeprüften Verkehr wie gewöhnlichen menschlichen Verkehr behandelt, hat jetzt Crawler-Aktivität im Umfang mehrerer tausend Adressen als Sitzungen in seiner Auswertung stehen.
Keine der beiden Fehlerarten meldet sich als Listenproblem. Beide sehen nach etwas anderem aus, und genau deshalb gehört der Erneuerungstakt für jede veröffentlichte Bereichsliste in einen geplanten Auftrag und nicht in jemandes Gedächtnis.
Der Schlüsselbeleg
Der andere Weg verlagert den Nachweis in die Anfrage. Der Betreiber hält ein Schlüsselpaar, veröffentlicht die öffentliche Hälfte unter einer Domain, die er kontrolliert, und unterschreibt jede ausgehende Anfrage; der Auftritt prüft die Signatur am veröffentlichten Schlüssel. HTTP-Nachrichtensignaturen nach RFC 9421 sind der Mechanismus, Web Bot Auth ist die auf Agenten gerichtete Ausprägung davon.
Sein Vorteil gegenüber einer Adresse ist struktureller Art. Ein Schlüssel folgt dem Betreiber, nicht der Maschine – neue Kapazität unterschreibt am Tag ihrer Inbetriebnahme mit demselben Schlüssel, und keine Liste irgendwo muss angefasst werden. Er übersteht außerdem gemietete Infrastruktur, wo eine Adresse wirklich nicht weiterhilft: Der Adressblock gehört einem Rechenzentrumsanbieter, und das sagt niemandem, wer ihn in diesem Monat mietet.
Der Preis dafür ist, dass es ihn nur gibt, wo ein Betreiber sich dafür entschieden hat. Ein Adressbeleg wirkt gegen jeden Crawler, der Bereiche veröffentlicht, und das sind fast alle etablierten; ein Schlüsselbeleg wirkt gegen die Teilmenge, die unterschreibt, und die ist heute klein.
Welcher, und wann
In der Praxis konkurrieren die beiden nicht. Eine Adressprüfung beantwortet eine Frage, die eine Signatur nicht beantworten kann: ob Verkehr, der sich für einen bekannten Crawler ausgibt, tatsächlich dort herkommt, wo dieser Crawler wohnt. Eine Signatur beantwortet eine Frage, die eine Adresse nicht beantworten kann: welcher von mehreren Betreibern in einem gemeinsamen Rechenzentrum das hier geschickt hat.
Sinnvoll ist deshalb, die Adressprüfung zuerst laufen zu lassen, weil sie billig ist und die etablierten Crawler abdeckt, und eine gültige Signatur als unabhängigen zweiten Weg für die Betreiber zu akzeptieren, die einen anbieten. Was keiner von beiden liefert, ist ein Urteil darüber, wozu die Anfrage dient. Beide klären, wer fragt. Was mit der Antwort geschieht, steht in keinem der beiden Belege.
Passend dazu
