Wykrywanie botów: listy adresów IP a podpisy kryptograficzne

Apple powiększył w sierpniu 2026 pulę adresów stojącą za Applebotem. Zgłaszane liczby to skok z około 2400 adresów w dwunastu prefiksach do mniej więcej 7056 w trzydziestu trzech, a opublikowana lista zakresów jest tam nadal nazywana niepełną. Każda witryna sprawdzająca tego robota wobec zapisanej kopii listy musiała pobrać nową – albo po cichu zaczęła brać uprawnionego robota za oszusta.

Nie jest to wada tego jednego wydania. To cecha definiująca dowód tożsamości przez adres i bardziej zasługuje na zestawienie z alternatywą niż na narzekanie.

Dowód adresowy i jego samoutrzymująca się odmiana

Najprostsza postać to lista zakresów, którą operator publikuje, a każda witryna pobiera. Działa, bo adresu nadawcy nie da się podrobić przez zakończone uzgodnienie TCP – to czyni z niego prawdziwy dowód pochodzenia, a nie twierdzenie.

Potwierdzone w przód reverse DNS to ten sam dowód z przeniesionym utrzymaniem. Zamiast trzymać zakresy, witryna rozwiązuje adres wstecz, potem rozwiązuje otrzymaną nazwę znów w przód i sprawdza, czy trafia na adres, od którego zaczęła.

adres w zadaniu              17.241.75.12

  rozwiazanie wsteczne       -> jakis.applebot.apple.com
  sprawdzenie koncowki       konczy sie domena operatora
  rozwiazanie w przod        -> 17.241.75.12
  porownanie                 ten sam adres, wiec twierdzenie trzyma

  psuje sie bezpiecznie: podrobiony wpis wsteczny nie przezyje
  rozwiazania w przod, bo napastnik nie kontroluje strefy
  w przod nalezacej do operatora

Ta odmiana kosztuje jeden do dwóch obiegów DNS na nowy adres, potem buforowanych, i nie starzeje się, gdy pula rośnie. Dowodem adresowym pozostaje mimo to, ze wszystkim, co z tego wynika.

Ile naprawdę kosztuje rozszerzenie

Pula, która niemal się potraja, tworzy dwa rodzaje usterek, a głośny jest tylko jeden. Głośny to zablokowany robot, zauważony w ciągu dnia, bo treści przestają być indeksowane. Cichy jest gorszy: witryna traktująca niezweryfikowany ruch jak zwykły ruch ludzki ma teraz aktywność robota z kilku tysięcy adresów zapisaną w analityce jako sesje.

Żaden z tych rodzajów nie zgłasza się jako problem z listą. Oba wyglądają na coś innego i właśnie dlatego rytm odświeżania każdej opublikowanej listy zakresów należy do zaplanowanego zadania, a nie do czyjejś pamięci.

Dowód kluczowy

Druga droga przenosi dowód do żądania. Operator trzyma parę kluczy, publikuje połowę publiczną pod kontrolowaną przez siebie domeną i podpisuje każde wychodzące żądanie; witryna sprawdza podpis wobec opublikowanego klucza. Mechanizmem są podpisy wiadomości HTTP według RFC 9421, a Web Bot Auth to ich odmiana wycelowana w agentów.

Przewaga nad adresem jest strukturalna. Klucz idzie za operatorem, nie za maszyną – nowa pojemność podpisuje tym samym kluczem w dniu uruchomienia i żadna lista nigdzie nie wymaga ruszania. Znosi też wynajętą infrastrukturę, gdzie adres naprawdę nie pomaga: blok adresowy należy do dostawcy serwerowni, a to nikomu nie mówi, kto go wynajmuje w tym miesiącu.

Ceną jest to, że istnieje tylko tam, gdzie operator się na to zdecydował. Dowód adresowy działa wobec każdego robota publikującego zakresy, a to prawie wszystkie ugruntowane; dowód kluczowy działa wobec podzbioru, który podpisuje, a ten jest dziś mały.

Który i kiedy

W praktyce te dwa nie konkurują. Sprawdzenie adresu odpowiada na pytanie, na które podpis odpowiedzieć nie może: czy ruch podający się za znanego robota naprawdę pochodzi stamtąd, gdzie ten robot mieszka. Podpis odpowiada na pytanie, na które nie może odpowiedzieć adres: który z kilku operatorów dzielących serwerownię to wysłał.

Rozsądnie jest więc puścić najpierw sprawdzenie adresu, bo jest tanie i pokrywa ugruntowane roboty, a ważny podpis przyjmować jako niezależną drugą drogę dla operatorów, którzy go oferują. Czego nie daje żaden z nich, to ocena, czemu żądanie służy. Oba ustalają, kto pyta. O tym, co dzieje się z odpowiedzią, nie mówi żaden z dwóch dowodów.