Strona główna › Poradniki

Monitorowanie czarnych list: skrypty, API i alerty webhook

Opublikowano 2026-11-03 ／ Zaktualizowano 2026-11-03 ／ Autor Yuki Nakazawa

Monitorowanie czarnych list polega na cyklicznym odpytywaniu kilku list blokujących DNS (DNSBL) o adresy IP i domeny nadawcze oraz wysyłaniu alertu tylko wtedy, gdy wynik się zmieni. Wykrycie wpisu w chwili jego pojawienia się, a nie dopiero wtedy, gdy klienci zgłaszają odrzucaną pocztę, daje czas na ustalenie przyczyny i złożenie wniosku o usunięcie, zanim szkody się rozprzestrzenią.

Są dwa praktyczne sposoby: samodzielne uruchamianie niewielkiego skryptu z dig i cron albo powierzenie sprawdzeń usłudze przez API i webhooki. W obu przypadkach o tym, czy monitor mówi prawdę, decydują dwa szczegóły: zapytania wysyłane przez publiczne resolvery są odrzucane przez listy takie jak Spamhaus i dają mylące odpowiedzi, a kodów błędów nigdy nie wolno liczyć jako wpisów.

Przytoczone tu zasady operatorów list opierają się na ich oficjalnych stronach według stanu na listopad 2026. Zasady się zmieniają, dlatego przed oparciem się na danej konfiguracji warto je potwierdzić. Podstawy działania DNSBL wyjaśnia artykuł czym jest DNSBL (RBL).

Ustal, co monitorować i które listy odpytywać

Zacznij od spisania obiektów, które faktycznie trzeba obserwować.

• Adresy IP nadawcze. To adresy, z których rzeczywiście wysyła pocztę Twój serwer pocztowy lub dostawca poczty. Witryna i poczta często wychodzą z różnych maszyn, dlatego potwierdź adres w nagłówkach Received wysłanej wiadomości. Jeśli wysyłasz przez IPv6, monitoruj również te adresy.
• Domeny. Domena w adresie From oraz wszystkie domeny pojawiające się w linkach w wiadomościach. Domeny sprawdza się na listach blokujących domeny, które są oddzielne od list IP.

Format zapytania definiuje RFC 5782. W przypadku IPv4 odwraca się kolejność oktetów i dopisuje strefę listy, więc 192.0.2.99 na danej liście staje się 99.2.0.192 z dopisaną nazwą strefy. W przypadku IPv6 adres zapisuje się jako 32 półbajty (nibble) szesnastkowe w odwrotnej kolejności. Domenę po prostu umieszcza się przed strefą. Wpisany obiekt zwraca rekord A, zgodnie z konwencją z zakresu 127.0.0.0/8; niewpisany zwraca NXDOMAIN. RFC zaznacza też, że listy powinny publikować rekord TXT wyjaśniający powód wpisu.

Warto obserwować kilka list, a nie jedną, ponieważ odbiorcy nie korzystają z tych samych list. Znaczenie poszczególnych kodów odpowiedzi zależy od operatora; najczęstsze omawia nasz poradnik o kodach odpowiedzi DNSBL.

Dlaczego publiczne resolvery dają błędne odpowiedzi

Częstym błędem w samodzielnie budowanym monitoringu jest wysyłanie zapytań przez publiczny resolver, taki jak Google Public DNS (8.8.8.8) lub Cloudflare (1.1.1.1). Oficjalne FAQ Spamhaus dotyczące korzystania z DNSBL wyjaśnia, co się wtedy dzieje:

• Bezpłatne korzystanie z list DNSBL Spamhaus wymaga, aby użycie było niekomercyjne i aby zapytania nie pochodziły z publicznego lub otwartego resolvera ani z adresu IP z generycznym odwrotnym DNS.
• Przy zapytaniach przez bezpłatne otwarte resolvery, takie jak Google Public DNS, w większości przypadków otrzymuje się odpowiedź „brak wpisu” (NXDOMAIN). Innymi słowy, wpisany adres IP może wyglądać na czysty.
• Zapytania przez publiczny resolver mogą też otrzymać 127.255.255.254. To kod błędu, a nie wpis. Podobnie 127.255.255.252 oznacza literówkę w nazwie DNSBL, a 127.255.255.255 nadmierną liczbę zapytań. Spamhaus podaje, że kodów tych nie wolno traktować jako oznaki, że odpytywany obiekt jest wpisany.
• Resolvery podmieniające odpowiedzi NXDOMAIN zwracają zamiast tego adres IP, więc poprawnej odpowiedzi NXDOMAIN nigdy się nie zobaczy.

Główne zalecenie FAQ to uruchomienie własnego resolvera DNS. Użytkownikom, którzy muszą pozostać przy publicznym resolverze, Spamhaus wskazuje swoją usługę Data Query Service (DQS); w jej warunkach należy sprawdzić, co jest bezpłatne. Aby zobaczyć, z którego resolvera faktycznie korzystasz, FAQ sugeruje dig txt whoami.fastly.net.

RFC 5782 dodaje wbudowany test poprawności: lista IPv4 musi zawierać wpis dla 127.0.0.2 i nie może zawierać 127.0.0.1, a klienci powinni okresowo sprawdzać te wpisy testowe, aby potwierdzić, że lista działa. W przykładzie Spamhaus 2.0.0.127.zen.spamhaus.org zwraca 127.0.0.10, 127.0.0.4 i 127.0.0.2, a 1.0.0.127.zen.spamhaus.org zwraca NXDOMAIN. Monitor powinien najpierw wykonać ten test i odrzucić cały przebieg, jeśli test się nie powiedzie.

Opcja 1: skrypt z dig i cron

Oto minimalny skrypt, który sprawdza jeden adres IPv4 na Spamhaus ZEN i SpamCop (bl.spamcop.net, który według dokumentacji SpamCop zwraca 127.0.0.2 dla wpisanego IP). Zastąp adres i strefy własnymi.

#!/bin/sh
# Odpytuj własny resolver rekurencyjny (np. unbound na tym samym hoście), nigdy publiczny
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # Jeśli wpis testowy 127.0.0.2 nie zwraca kodu wpisu, nie ufaj temu przebiegowi
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

Co robi skrypt:

• Za czysty uznawany jest wyłącznie status NXDOMAIN, 127.255.255.x to błąd, a każda inna odpowiedź 127.x to wpis. Wszystko spoza 127.0.0.0/8 jest traktowane jako anomalia, np. resolver podmieniający odpowiedzi.
• Przekroczenie limitu czasu powoduje, że dig kończy się kodem różnym od zera, natomiast SERVFAIL i REFUSED kończą się kodem 0. Żadna z tych sytuacji nie jest traktowana jako czysta; skrypt zapisuje błąd.
• Kody odpowiedzi są specyficzne dla list. Niektóre listy używają na przykład 127.0.0.1 na oznaczenie odrzuconego zapytania, dlatego przeczytaj dokumentację każdej dodawanej listy i w razie potrzeby rozbuduj instrukcję case.

Następnie niech cron porównuje każdy przebieg z poprzednim i wysyła wiadomość tylko wtedy, gdy coś się zmieniło:

# Przykład: uruchamiaj co godzinę, wysyłaj wiadomość tylko, gdy wynik różni się od poprzedniego
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

Interwał godzinowy to tylko przykład. Spamhaus oferuje bezpłatny dostęp przy niewielkim, niekomercyjnym użyciu, a klienci przekraczający jego próg liczby zapytań potrzebują opcji płatnej; w miarę wzrostu liczby monitorowanych adresów IP sprawdzaj warunki każdej listy. FAQ zaleca też kilkukrotne wykonanie poleceń, aby potwierdzić, że wyniki się nie zmieniają.

Opcja 2: API wsadowe DNSBL Checker i webhooki

Jeśli wolisz nie utrzymywać resolvera i reguł interpretacji dla każdej listy, możesz powierzyć sprawdzanie usłudze. Poniżej opisano API v1 tej witryny w zakresie tego, co faktycznie robi implementacja po stronie serwera. Dokumentacja znajduje się pod adresem /en/api-docs, a klucze wydaje się na stronie konta pod adresem /account. Rejestracja wymaga tylko adresu e-mail, a logowanie odbywa się za pomocą linku wysyłanego e-mailem.

Uwierzytelnianie i limity

• Klucze zaczynają się od dnsbl_ i są wyświetlane jednorazowo, zaraz po wydaniu; przechowywany jest tylko skrót (hash). Ponowne wydanie klucza unieważnia poprzedni.
• Klucz przesyłaj w nagłówku X-API-Key przy każdym żądaniu. Wyłącznie HTTPS; zwykłe http:// jest przekierowywane na https://, więc od początku wywołuj https://.
• Limity to 1 000 sprawdzeń dziennie (jeden cel liczy się jako jedno), 100 celów na jedno zlecenie wsadowe i 50 rejestracji monitorów. Po przekroczeniu limitu dziennego otrzymasz 429 z daily_limit_exceeded i znacznikiem czasu resets_at.

Sprawdzenia wsadowe

Wyślij tablicę targets z nazwami domen lub adresami IP do POST /api/v1/batch:

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

Jeśli któryś cel wymaga jeszcze sprawdzenia, odpowiedzią jest 202 z batch_id. Odpytuj GET /api/v1/batch/{batch_id} co kilka sekund, aż status przyjmie wartość done (przykład skrócony; liczby i nazwa listy są poglądowe, a nie rzeczywistym wynikiem):

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

• verdict ma wartość listed, jeśli co najmniej jedna lista zgłasza wpis, w przeciwnym razie clean. Listy, które przekroczyły limit czasu lub odpowiedziały kodem błędu, takim jak 127.255.255.x, są liczone w error_count i nigdy jako wpisy.
• Zlecenie wsadowe zwraca zapisany wynik, jeśli istnieje wynik z ostatnich 30 dni. Przy cyklicznym monitorowaniu zawsze sprawdzaj checked_at.
• Nieprawidłowe cele wracają w rejected wraz z powodem i nie są liczone. Jeśli przekażesz URL, używana jest tylko nazwa hosta. Zakresy przeznaczone wyłącznie do dokumentacji, takie jak 192.0.2.0/24, są odrzucane, więc testuj na rzeczywistym adresie IP nadawczym.

Monitorowanie z webhookami

Zarejestruj target i callback_url za pomocą POST /api/v1/monitors. Każdy zarejestrowany cel jest wtedy sprawdzany raz dziennie z pominięciem pamięci podręcznej (pierwsze sprawdzenie następuje w ciągu około doby od rejestracji), a JSON metodą POST jest wysyłany na Twój URL tylko przy pierwszym sprawdzeniu (monitor.initial) oraz wtedy, gdy werdykt zmienia się między listed a clean (monitor.status_changed).

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

• signing_secret w odpowiedzi jest wyświetlany tylko raz. Każde doręczenie zawiera nagłówek X-DNSBL-Signature: sha256=..., czyli HMAC-SHA256 surowej treści z tym sekretem jako kluczem. Weryfikuj go po swojej stronie.
• callback_url musi używać https na porcie 443 i wskazywać na publiczny adres IP; przekierowania nie są obsługiwane, a limit czasu wynosi 10 sekund, więc cięższe zadania umieszczaj w kolejce i odpowiadaj szybko.
• Jeśli Twój endpoint zwróci cokolwiek innego niż 2xx lub połączenie się nie powiedzie, doręczenie jest ponawiane przy następnym dziennym sprawdzeniu. Powód widać jako last_delivery_error w GET /api/v1/monitors, a DELETE /api/v1/monitors/{monitor_id} usuwa monitor.

import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))

Projektowanie alertów: częstotliwość, wiele list i fałszywe alarmy

Monitor jest przydatny tylko wtedy, gdy po kilku miesiącach ludzie nadal czytają jego alerty. Taki, który alarmuje bez przerwy, szybko zaczyna być ignorowany.

Częstotliwość

• Oddziel częstotliwość odpytywania od częstotliwości powiadomień. Odpytuj według harmonogramu, ale powiadamiaj tylko o zmianie stanu. Codzienna wiadomość „wszystko w porządku” zagłusza ten jeden alert, który ma znaczenie.
• RFC 5782 mówi, że TTL list powinny odzwierciedlać tempo zmian listy i że listy źródeł spamu mogą stosować TTL rzędu minut. Wybierając interwał, pamiętaj, że niektóre wpisy pojawiają się i wygasają szybko.
• Intensywne odpytywanie może naruszać warunki korzystania z listy albo skutkować odpowiedzią 127.255.255.255 (nadmierna liczba zapytań) zamiast rzeczywistych odpowiedzi.

Kilka list

• W każdym alercie podawaj nazwę listy. Listy różnią się liczbą korzystających z nich odbiorców, więc możesz alarmować natychmiast w przypadku list najważniejszych dla Twoich odbiorców, a pozostałe zbierać w zbiorcze podsumowanie.
• Opisany wyżej webhook wyzwala się tylko wtedy, gdy werdykt zmienia się między listed a clean. Jeśli cel jest już wpisany, a następnie pojawi się na drugiej liście, zdarzenie nie zostanie wysłane. Aby wychwycić taki przypadek, obserwuj last_listed_count w GET /api/v1/monitors albo uruchom zlecenie wsadowe i odczytaj listed_on.

Fałszywe alarmy i odpowiedzi przejściowe

• Zapisuj błędy oddzielnie od wpisów. Spamhaus ostrzega operatorów, aby nie odrzucali ani nie filtrowali poczty na podstawie jego kodów błędów; ta sama logika dotyczy monitorowania. Przekroczenie limitu czasu lub odpowiedź 127.255.255.x nigdy nie powinny wyzwalać alertu o wpisie.
• Aby nie reagować na pojedynczy nietypowy wynik, alarmuj dopiero po dwóch kolejnych identycznych wynikach albo przed wysłaniem czegokolwiek ponów zapytanie po kilku minutach.
• Jeśli błędy się utrzymują, podejrzewaj zmianę resolvera lub zmianę po stronie listy i najpierw sprawdź wynik wpisu testowego.
• Domowy adres IP w Spamhaus PBL to wpis wynikający z zasad, a nie oskarżenie: oznacza, że z tego adresu poczta nie powinna być wysyłana bezpośrednio. Dla każdej listy ustal, co uznajesz za powód alertu (zob. usuwanie ze Spamhaus).

Co zrobić po wykryciu wpisu

1. Potwierdź go. Sprawdź stronę sprawdzania prowadzoną przez operatora i zanotuj nazwę listy, czas oraz ewentualny podany powód.
2. Najpierw usuń przyczynę. Szukaj przejętych kont, nadużytych formularzy WWW, zainfekowanych maszyn, zaniedbanych list adresowych oraz niezgodnego odwrotnego DNS (PTR) lub nazw HELO. Wniosek o usunięcie złożony, gdy przyczyna nadal istnieje, zwykle prowadzi do nowego wpisu.
3. Postępuj zgodnie z procedurą usuwania danej listy. Decyzja o usunięciu należy do operatora każdej listy, a złożenie wniosku nie gwarantuje zdjęcia wpisu. Jeśli nie kontrolujesz adresu IP, jak w przypadku hostingu współdzielonego, skontaktuj się z dostawcą hostingu lub ISP.
4. Pozwól monitorowi potwierdzić wynik. Odbiorcy stosują też własne filtry, więc po powrocie werdyktu do clean nadal obserwuj dostarczanie.

Do jednorazowego sprawdzenia adresu IP lub domeny użyj narzędzia do sprawdzania czarnych list. Jeśli ustalenie przyczyny lub obsługa wniosków przerasta Twoje możliwości, możesz poprosić nas o pomoc. Pełną ścieżkę diagnostyczną przy odrzucanej poczcie opisuje artykuł poczta blokowana przez czarne listy.

Najczęściej zadawane pytania

Wykorzystane strony oficjalne

Fakty podane w tym artykule zostały sprawdzone w momencie publikacji na poniższych stronach oficjalnych. Zasady i działanie usług mogą się zmienić bez uprzedzenia, dlatego przed podjęciem ważnych decyzji warto sprawdzić strony oficjalne.

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Using our public mirrors? Check your return codes now
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?

Powiązane poradniki

Wszystkie poradniki →