Головна › Посібники

Моніторинг чорних списків: скрипти, API та сповіщення через вебхуки

Опубліковано 2026-11-03 ／ Оновлено 2026-11-03 ／ Автор Yuki Nakazawa

Моніторинг чорних списків — це регулярні за розкладом запити до кількох DNS-списків блокування (DNSBL) щодо ваших IP-адрес і доменів відправника зі сповіщенням лише тоді, коли результат змінюється. Якщо помітити запис у списку одразу, а не тоді, коли клієнти скаржаться на повернені листи, у вас буде час знайти причину й подати запит на видалення, перш ніж шкода пошириться.

Практичних способів два: самому запускати невеликий скрипт на dig і cron або передати перевірки сервісу через API та вебхуки. У будь-якому разі дві деталі визначають, чи казатиме монітор правду: запити, надіслані через публічні резолвери, такі списки, як Spamhaus, відхиляють, і відповіді вводять в оману, а коди помилок ніколи не можна вважати записами в списку.

Наведені тут правила операторів списків ґрунтуються на їхніх офіційних сторінках станом на листопад 2026 року. Правила змінюються, тому перевірте їх, перш ніж покладатися на своє налаштування. Основи роботи DNSBL див. у статті що таке DNSBL (RBL).

Безкоштовно перевірте, чи є ваш домен або IP-адреса в одному з приблизно 345 чорних списків.

Визначте, за чим стежити і які списки запитувати

Почніть із того, що запишіть об’єкти, за якими вам справді потрібно стежити.

Формат запиту визначено в RFC 5782. Для IPv4 октети записують у зворотному порядку й додають зону списку, тож 192.0.2.99 у списку перетворюється на 99.2.0.192, за яким іде ім’я зони. Для IPv6 адресу записують як 32 шістнадцяткові nibble у зворотному порядку. Домен просто ставлять перед зоною. Для внесеного до списку елемента повертається запис A, за домовленістю з діапазону 127.0.0.0/8; для відсутнього — NXDOMAIN. RFC також зазначає, що списки мають публікувати запис TXT із поясненням причини внесення.

Стежте за кількома списками, а не за одним, бо одержувачі використовують не однакові. Значення кожного коду відповіді залежить від оператора; поширені коди описано в нашому посібнику про коди відповідей DNSBL.

Чому публічні резолвери дають неправильні відповіді

Поширена помилка саморобного моніторингу — надсилати запити через публічний резолвер, як-от Google Public DNS (8.8.8.8) або Cloudflare (1.1.1.1). Офіційний FAQ Spamhaus щодо використання DNSBL пояснює, що відбувається:

Головна рекомендація FAQ — використовувати власний DNS-резолвер. Тим, хто змушений залишатися на публічному резолвері, Spamhaus пропонує свій Data Query Service (DQS); що в ньому безкоштовне, дивіться в його умовах. Щоб побачити, яким резолвером ви насправді користуєтеся, FAQ пропонує команду dig txt whoami.fastly.net.

RFC 5782 передбачає вбудовану перевірку справності: список IPv4 повинен містити запис для 127.0.0.2 і не повинен містити 127.0.0.1, а клієнтам слід періодично перевіряти ці тестові записи, щоб переконатися, що список працює. У прикладі Spamhaus 2.0.0.127.zen.spamhaus.org повертає 127.0.0.10, 127.0.0.4 і 127.0.0.2, а 1.0.0.127.zen.spamhaus.org — NXDOMAIN. Монітор має спершу перевіряти це й відкидати запуск, якщо перевірка не пройшла.

Варіант 1: скрипт на dig і cron

Ось мінімальний скрипт, який перевіряє одну адресу IPv4 за Spamhaus ZEN і SpamCop (bl.spamcop.net; за документацією SpamCop, для IP-адреси зі списку він відповідає 127.0.0.2). Замініть адресу та зони на власні.

#!/bin/sh
# Надсилайте запити до власного рекурсивного резолвера (наприклад, unbound на тому самому хості), ніколи не до публічного
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
  # Якщо тестовий запис 127.0.0.2 не повертає код внесення до списку, цьому запуску не довіряйте
  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

Що робить скрипт:

Далі нехай cron порівнює кожен запуск із попереднім і надсилає лист лише тоді, коли щось змінилося:

# Приклад: запуск щогодини, лист надсилається лише тоді, коли вивід відрізняється від попереднього запуску
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

Інтервал в одну годину — лише приклад. Spamhaus надає безкоштовний доступ для некомерційного використання з невеликим обсягом запитів, а клієнтам, що перевищують його поріг обсягу запитів, потрібен платний варіант; зі зростанням кількості IP-адрес під моніторингом перевіряйте умови кожного списку. FAQ також радить виконати команди кілька разів, щоб переконатися, що результати не змінюються.

Варіант 2: пакетний API DNSBL Checker і вебхуки

Якщо ви не хочете підтримувати резолвер і правила розбору для кожного списку, перевірки можна доручити сервісу. Нижче описано API v1 цього сайту — лише те, що справді робить серверна реалізація. Довідка розміщена за адресою /en/api-docs, а ключі видаються на сторінці учасника /account. Для реєстрації потрібна лише адреса електронної пошти, а вхід виконується за посиланням, надісланим поштою.

Автентифікація та ліміти

Пакетні перевірки

Надішліть масив targets з доменними іменами або IP-адресами на 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"]}'

Якщо якусь ціль ще треба перевірити, відповідь буде 202 з batch_id. Опитуйте GET /api/v1/batch/{batch_id} кожні кілька секунд, доки status не стане done (скорочений приклад; числа й назва списку наведені для ілюстрації, це не справжній результат):

{
  "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" }
      ]
    }
  ]
}

Моніторинг через вебхуки

Зареєструйте target і callback_url через POST /api/v1/monitors. Після цього кожна зареєстрована ціль перевіряється раз на день без використання кешу (перша перевірка відбувається приблизно протягом доби після реєстрації), а JSON-запит POST надсилається на ваш URL лише під час першої перевірки (monitor.initial) і коли вердикт змінюється між listed і 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"}'
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", ""))

Налаштування сповіщень: частота, кілька списків і хибні тривоги

Монітор корисний лише тоді, коли його сповіщення читають і через кілька місяців. Той, що спрацьовує постійно, швидко починають ігнорувати.

Частота

Кілька списків

Хибні спрацювання та тимчасові відповіді

Що робити, коли виявлено запис у списку

  1. Підтвердьте його. Перевірте на власній сторінці перевірки оператора й запишіть назву списку, час і вказану причину, якщо вона є.
  2. Спершу усуньте причину. Шукайте зламані акаунти, зловживання вебформами, заражені машини, погану гігієну списків розсилання та невідповідність зворотного DNS (PTR) чи імен HELO. Запит на видалення, поки причина залишається, зазвичай призводить до нового внесення.
  3. Дотримуйтеся процедури видалення відповідного списку. Рішення про видалення ухвалює оператор кожного списку, і подання запиту не гарантує, що запис знімуть. Якщо ви не керуєте IP-адресою, як на віртуальному хостингу, зверніться до хостинг-провайдера або ISP.
  4. Нехай монітор підтвердить результат. Одержувачі також застосовують власні фільтри, тож стежте за доставленням і після того, як вердикт знову стане clean.

Для разової перевірки IP-адреси чи домену скористайтеся сервісом перевірки чорних списків. Якщо пошук причини або робота із запитами вам не під силу, ви можете звернутися до нас по допомогу. Повний порядок діагностики, коли листи повертаються, див. у статті листи, заблоковані через чорні списки.

Якщо ви не хочете займатися цим самостійно

Ми рекомендуємо підрядників, які беруться за запити на видалення зі списків, консультації та поради (від JPY 50,000). Рішення про видалення ухвалює оператор кожного списку, тому гарантувати його неможливо.

Отримати допомогу

Цей сайт може отримувати винагороду за рекомендацію від зазначених підрядників. About

Поширені запитання

Я перевірив через 8.8.8.8 і запису не знайшов. Мене немає в списках?

Не обов’язково. У FAQ Spamhaus сказано, що запити через безкоштовні відкриті резолвери, як-от Google Public DNS, у більшості випадків отримують відповідь «немає в списку» (NXDOMAIN), тож IP-адреса зі списку може виглядати чистою. Надсилайте запити з власного резолвера або скористайтеся сторінкою перевірки оператора.

Я отримав 127.255.255.254. Це означає, що я в списку?

Ні. Це код помилки, який повертається на запити через публічний або відкритий резолвер, і Spamhaus наголошує, що він не означає наявності об’єкта в списку. Зафіксуйте його як помилку й не надсилайте сповіщення про внесення.

Чи можна просто щодня викликати пакетний API як монітор?

Пакет може повернути збережений результат давністю до 30 днів, тож це не завжди сьогоднішній стан. Перевіряйте checked_at або скористайтеся моніторингом через вебхуки (POST /api/v1/monitors), який щодня виконує нову перевірку.

Чи варто подавати запит на видалення, щойно спрацювало сповіщення?

Спершу усуньте причину. Запит, поданий, поки проблема залишається, зазвичай закінчується новим внесенням. Рішення завжди за оператором списку.

Використані офіційні сторінки

Факти в цій статті на момент публікації звірено з наведеними нижче офіційними сторінками. Правила й поведінка сервісів можуть змінюватися без попередження, тож перш ніж покладатися на щось важливе, перевірте офіційні сторінки.

Схожі посібники

Коди відповідей DNSBL: 127.0.0.2, 127.255.255.x і NXDOMAIN

Як читати коди відповідей DNSBL: що означає 127.0.0.2 за RFC 5782, коди Spamhaus, SpamCop і UCEPROTECT, коди помилок, різниця між NXDOMAIN і SERVFAIL.

Видалення зі Spamhaus: як вивести IP-адресу чи домен зі списку

Потрапили до Spamhaus? З’ясуйте, у якому ви списку (ZEN, PBL, XBL, CSS, SBL, DBL), що означають коди відповіді та як вийти з кожного списку.

Пошта в чорному списку? Як прочитати повернення і вийти зі списку

Листи блокує чорний список? Прочитайте код повернення, перевірте причини по черзі, з’ясуйте, які списки важливі, і правильно подайте запит на видалення.

Усі посібники →