Czy robot jest tym, za kogo się podaje? Reverse DNS i publikowane zakresy IP

User-agent to ciąg znaków, który może zadeklarować dowolny klient HTTP. Skrypt przedstawiający się jako „Googlebot” albo „GPTBot” nie jest ani jednym, ani drugim, dopóki tego nie sprawdzimy. Pytanie liczy się w obie strony: żeby nie zablokować prawdziwego robota wyszukiwarki w przekonaniu, że blokuje się naśladowcę, i żeby nie przepuścić scrapera, który podszywa się pod szanowaną nazwę. Wielcy dostawcy robotów publikują metodę weryfikacji, każdy swoją, i metody te się różnią.

Dwie rodziny weryfikacji

Pierwsza metoda to reverse DNS: bierze się adres IP żądania, pyta DNS o powiązaną nazwę hosta, sprawdza, czy nazwa ta należy do domeny ogłoszonej przez dostawcę, następnie rozwiązuje tę nazwę na adres IP i sprawdza, czy wraca się do adresu wyjściowego. To podwójne rozwiązanie nazwy uniemożliwia osobie trzeciej powoływanie się na domenę, której nie kontroluje, nawet gdy panuje nad reverse DNS swojego adresu.

Druga metoda to publikowana lista adresów: dostawca utrzymuje plik, zwykle w formacie JSON, z zakresami IP, z których wychodzą jego roboty. Sprawdza się po prostu, czy adres żądania należy do jednego z tych zakresów. Jest to szybsze w automatyzacji i nie zależy od DNS, ale listę trzeba regularnie odświeżać.

Kto co publikuje

Pliki te mają niemal wszystkie ten sam schemat, spopularyzowany przez Google: tablicę prefiksów IPv4 i IPv6 wraz z datą utworzenia. Skrypt, który umie odczytać jeden, umie odczytać pozostałe. Datę utworzenia warto przeczytać: mówi, kiedy listę wytworzono po raz ostatni. Lista sprzed kilku miesięcy nie jest przez to fałszywa (zakresy wielkich dostawców zmieniają się powoli), ale uzasadnia weryfikację przez reverse DNS, gdy pojawia się wątpliwość co do adresu spoza listy.

Pułapki spotykane w praktyce

1. Dobry adres URL, zła odpowiedź. Niektóre strony dokumentacji odpowiadają kodem 200 i zwracają HTML, choć oczekiwano formatu JSON, bo adres się zmienił albo przekierowanie prowadzi na stronę główną. Skrypt, który testuje wyłącznie kod HTTP, uzna, że ma aktualną listę. Trzeba sprawdzać typ zawartości i obecność tablicy prefiksów.
2. Nie wszędzie jest IPv6. Niektórzy dostawcy publikują wyłącznie zakresy IPv4. Żądanie przychodzące z adresu IPv6 z właściwym user-agent nie może wtedy zostać potwierdzone przez listę, co nie czyni z niego podszycia. Ten przypadek trzeba przewidzieć, zamiast domyślnie blokować.
3. Firewall przed serwerem. Jeśli CDN albo firewall aplikacyjny filtruje ruch przed serwerem, adres widoczny w logach może być adresem CDN, a nie robota, chyba że jakiś nagłówek niesie adres źródłowy. Wielkie sieci CDN wstawiają taki nagłówek domyślnie, ale warstwa pośrednia może go nadpisać. Wracamy do tego w artykule o martwym polu blokad na brzegu sieci.

Metoda, krok po kroku

Aby ręcznie sprawdzić podejrzane żądanie:

1. Odnotować adres IP i user-agent z loga.
2. Jeśli dostawca publikuje listę, pobrać bieżący plik JSON i sprawdzić przynależność adresu do jednego z prefiksów. Adres spoza listy z user-agent dostawcy to podszycie, z wyjątkiem nieobjętego listą przypadku IPv6.
3. Jeśli dostawca korzysta z reverse DNS, rozwiązać adres na nazwę hosta, sprawdzić domenę, następnie rozwiązać tę nazwę na adres i porównać. Oba rozwiązania nazwy muszą się zgadzać.
4. Zapisać wynik. Rejestr wykrytych podszyć przydaje się do ustawienia firewalla i do uzasadnienia swojej decyzji w dniu, w którym operator robota zakwestionuje blokadę.

Przy automatyzacji lepiej odświeżać listy codziennie, zachowywać poprzednią wersję na wypadek nieudanego pobrania i nigdy nie blokować adresu spoza listy bez sprawdzenia go przez reverse DNS: zakresy się zmieniają, a prawdziwy robot przychodzący z nowego zakresu zostałby wzięty za oszusta.

Co te listy mówią również o rolach

OpenAI publikuje po jednej liście na robota: jedną dla OAI-SearchBot, jedną dla ChatGPT-User, jedną dla GPTBot. Podział ten nie jest szczegółem organizacyjnym. Pozwala wiedzieć, adres po adresie, czy żądanie pochodziło z indeksowania wyszukiwarki, z odczytu zamówionego przez użytkownika w rozmowie, czy ze zbierania danych do trenowania. Trzy zastosowania, które wydawca może chcieć traktować odmiennie, a które zwykły filtr na słowo „GPT” zlewa w jedno. Anthropic grupuje swoje roboty w jednym pliku, ale rozróżnia w nim role w ten sam sposób. Log crawlowania, który zachowuje wyłącznie nazwę robota, traci tę informację; rejestr, który zachowuje adres, pozwala ją odtworzyć po fakcie.

Co zrobić z oszustem

Klient podszywający się pod robota Googlebot nie musi być złośliwy: narzędzia SEO, sondy monitorujące i wewnętrzne skrypty robią tak dla wygody. Zużywa jednak zasoby i zniekształca statystyki crawlowania. Można go przepuścić, licząc osobno w raportach, spowolnić albo zablokować na poziomie firewalla. Wybór zależy od tego, co witryna publikuje, i od obserwowanego obciążenia. Serwis medialny, który sprzedaje informację, ma powody, by blokować; serwis, który żyje ze swojej widoczności, ma powody, by przepuszczać i mierzyć. Czego robić nie należy, to blokować całą sygnaturę, na przykład wszystko, co zawiera „bot”, ryzykując wykluczenie prawdziwych robotów, które chciało się właśnie przyjąć.

Dlaczego serwis medialny musi się tym zająć

Witryna wizytówkowa może zignorować to pytanie. Serwis medialny, który celuje w cytowanie przez silniki generatywne, nie może. Pierwszy powód jest defensywny: podszycia pod roboty AI są częste, a źle ustawiona blokada wymierzona w nie trafia zwykle również w prawdziwe. Drugi powód jest analityczny: pomiar tego, co AI naprawdę robi z witryną, zakłada wiedzę, żądanie po żądaniu, jaki robot przyszedł, w jakiej roli i czy był autentyczny. Bez tej weryfikacji krzywa „wizyt robotów AI” liczy również naśladowców. Lekturę logów, która pozwala na ten pomiar, opisujemy w artykule „Czytanie access logu w 30 minut”, a listę samych robotów w artykule „robots.txt i AI”.