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

Що таке DNSBL (RBL) і як працюють чорні списки DNS

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

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

У цьому посібнику пояснено, як працює запит до DNSBL (IP-адреса у зворотному порядку, записи A і TXT, формат nibble для IPv6), чим відрізняються списки на основі IP і доменні списки, як одержувачі насправді використовують відповіді, чим чорні списки відрізняються від білих, чому адреси потрапляють до списків і яке місце займає запис у списку, коли ваша пошта не доставляється. Посібник ґрунтується на RFC 5782 та офіційній документації провідних операторів списків станом на листопад 2026 року.

Що означають DNSBL і RBL

RFC 5782 «DNS Blacklists and Whitelists» використовує загальний термін DNSxL для зони DNS, записи якої ідентифікують хости зі списку. Чорний список — це DNSBL, білий — DNSWL. Обидва влаштовано однаково. Різниться лише значення, яке одержувач надає збігу.

RBL — це Real-time Blackhole List («список чорних дір у реальному часі»). Згідно з RFC, перший список такого роду започатковано 1997 року, і він став відомий саме під цією назвою. Строго кажучи, RBL означає той первісний список і його наступника, а RFC зазначає, що цей термін є зареєстрованим знаком обслуговування в США. Однак у повсякденному вжитку «RBL» і «DNSBL» уживають майже як синоніми, тож «що таке RBL» і «що таке DNSBL» — фактично одне й те саме запитання.

RFC 5782 — інформаційний документ (Informational), а не інтернет-стандарт. Його підготувала IRTF Anti-Spam Research Group, і він відображає консенсус цієї групи щодо практик, які покращують сумісність між чорними й білими списками DNS. Він не описує й не рекомендує правил додавання чи видалення адрес; RFC передбачає, що це буде висвітлено в окремому документі. На практиці кожен оператор сам визначає власну політику внесення до списку і видалення з нього.

Як працює запит до DNSBL

Запит до DNSBL — звичайний DNS-запит, тож для ручної перевірки не потрібне спеціальне ПЗ: усе, що вміє розв’язувати імена, може надіслати запит до списку. Утім, оператори списків можуть установлювати умови використання. Публічні сервери Spamhaus, наприклад, безкоштовні лише для некомерційного використання з невеликим обсягом запитів, а на запити через публічні резолвери вони відповідають ненадійно (див. нижче).

IPv4: запишіть адресу у зворотному порядку й додайте зону

Для адреси IPv4 запишіть чотири октети у зворотному порядку й додайте ім’я зони списку. Ця структура запозичена зі зворотного DNS. У прикладі з RFC 5782 адресу 192.0.2.99 перевіряють за списком на bad.example.com таким запитом:

99.2.0.192.bad.example.com

Запис A каже «у списку», запис TXT — чому

• Запис A. Кожен елемент списку повинен мати запис A. За домовленістю його значення — 127.0.0.2. Це значення є сигналом, а не адресою, і використовувати його як адресу не можна; списки використовують діапазон 127.0.0.0/8, щоб помилково використане значення не створювало небажаного мережевого трафіку.
• Немає в списку. Якщо адреси в списку немає, записів для неї немає, тож запит зазвичай повертає NXDOMAIN.
• Запис TXT. DNSBL слід публікувати запис TXT з описом причини внесення. Клієнти повинні перевіряти запис A і можуть також перевіряти запис TXT.
• Різні значення для різних підсписків. Об’єднаний список може повертати різні значення 127.0.0.x, щоб показати, який підсписок спрацював, або одразу кілька записів A. Значення специфічні для кожного списку, тому завжди читайте документацію оператора. Поширені значення описано в нашому посібнику про коди відповідей DNSBL.

У терміналі (зона тут умовна):

dig +short 99.2.0.192.bad.example.com A
dig +short 99.2.0.192.bad.example.com TXT

Тестові записи

RFC 5782 вимагає, щоб списки IPv4 містили запис для 127.0.0.2 і не містили запису для 127.0.0.1. Очікується, що клієнти перевірятимуть ці тестові записи, перш ніж довіряти зоні, і не використовуватимуть зону, яка відповідає на них неправильно.

IPv6: формат nibble

Адресу IPv6 записують повністю у вигляді 32 шістнадцяткових цифр, потім розвертають по одній цифрі (одному nibble, тобто півбайту), ставлячи між ними крапки, і додають зону списку. Приклад з RFC для 2001:db8:1:2:3:4:567:89ab на ugly.example.com:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.com

Списки IPv6 повинні містити тестовий запис ::FFFF:7F00:2 (127.0.0.2 як адреса IPv4-mapped) і не повинні містити ::FFFF:7F00:1. Не кожен список підтримує IPv6, тому, перш ніж покладатися на запит для IPv6, перевірте документацію оператора.

Списки на основі IP і доменні списки

Залежно від вмісту списки бувають двох основних видів.

У доменному прикладі з RFC 5782 invalid.edu перевіряють за doms.example.net запитом invalid.edu.doms.example.net. Доменні списки іноді називають RHSBL (right-hand-side blacklist — чорний список «правої частини» адреси). Їхні тестові записи використовують зарезервовані імена: список повинен містити TEST і не повинен містити INVALID.

Spamhaus Domain Blocklist (dbl.spamhaus.org) — поширений приклад, і його документація наводить кілька практичних моментів:

• Він лише доменний. Запит до нього з IP-адресою завжди повертає код «у списку», тому його не можна налаштовувати як звичайний DNSBL для IP. Для перевірки IP-адрес Spamhaus радить ZEN (zen.spamhaus.org).
• Можна запитувати повне ім’я хоста; збіг буде, якщо домен цього хоста є в списку.
• Під час сеансу SMTP за ним перевіряють рядок HELO і домен MAIL FROM. Після прийняття листа за ним перевіряють домени в заголовках і тексті, як-от URL-адреси та контактні адреси.

Практичний наслідок: чиста IP-адреса відправника не гарантує доставлення. Домен відправника, що є в списку, або внесений до списку домен, на який є посилання в листі, однаково можуть спричинити блокування.

Як сервери одержувачів використовують DNSBL

RFC 5782 описує типове налаштування. Поштовий сервер перевіряє заданий набір DNSxL під час кожного вхідного SMTP-з’єднання. Збіг у чорному списку змушує його відхилити з’єднання, збіг у білому — прийняти. Як варіант, результати передаються до функції оцінювання, яка зважує їх разом з іншими сигналами. Фільтри, що працюють після отримання листа, зазвичай беруть IP-адреси для перевірки з полів заголовка Received або з URI в тексті.

Відхиляти чи оцінювати?

Цей вибір за одержувачем. Власний FAQ SpamCop називає цей список агресивним інструментом і радить позначати або перенаправляти підозрілий спам чи використовувати список як один із чинників оцінки, а не відхиляти пошту одразу. Налаштування відхилення там описано як інформацію для адміністраторів, які не можуть застосувати тонший підхід.

Підводні камені, про які попереджають одержувачів

• Ви делегуєте судження. Використовуючи DNSxL, ви передаєте частину керування своїм сервером оператору списку. RFC каже, що слід переконатися, що правила списку узгоджуються з вашими власними.
• Покинуті списки. Оператор, що закриває список, може встановити wildcard-запис, який вносить до списку всі адреси. Саме за описаними вище тестовими записами клієнт це помічає.
• Кешування. Сервери можуть кешувати результати, але повинні дотримуватися TTL і відкидати застарілі записи.
• Публічні резолвери. У FAQ Spamhaus сказано, що запити через Google Public DNS у більшості випадків повертатимуть «немає в списку», тож справжні записи пропускаються. Коди в 127.255.255.x — це помилки, як-от 127.255.255.254 для запиту через заблокований публічний резолвер, і їх не можна тлумачити як «у списку». Spamhaus зазначає, що деякі сервери через це помилково відхиляють усю пошту, і радить використовувати власний резолвер.

Це одна з причин, чому два інструменти перевірки можуть по-різному оцінювати ту саму адресу: вони можуть надсилати запити через різні резолвери.

Чорні й білі списки (DNSBL і DNSWL)

Запити до DNSBL і DNSWL надсилають однаково, але збіг означає протилежне. Згідно з RFC 5782, адміністратори мереж зазвичай використовують DNSBL для блокування трафіку, а DNSWL — для пріоритетного прийняття трафіку. Той самий список навіть може слугувати чорним в одному контексті й білим — в іншому.

dnswl.org (list.dnswl.org) — приклад білого списку. У його документації сказано, що відповіді мають вигляд 127.0.x.y, де x — категорія, а y — рівень довіри від 0 (немає) до 3 (високий). Там пропонують дозволяти хостам зі списку оминати greylisting і перевірки за чорними списками, хостам із середнім і високим рівнем довіри — оминати фільтрування спаму, а антивірусну перевірку не оминати ніколи. Від чого саме звільняє запис у білому списку, однаково вирішує одержувач.

Поширені причини внесення IP-адреси чи домену до списку

Кожен оператор установлює власні критерії, і багато хто не розголошує точних тригерів. Наведені нижче причини взято з опублікованої документації операторів.

• Скарги на спам і спам-пастки. SpamCop Blocking List містить IP-адреси, з яких надходила пошта, на яку поскаржилися користувачі SpamCop, причому більшу вагу має пошта на спам-пастки (адреси, зібрані або створені спамерами). У FAQ сказано, що без нових скарг запис триває лише 24 години, а адреси автоматично видаляються, коли скарги припиняються.
• Заражені або скомпрометовані пристрої. Spamhaus XBL автоматично вносить IP-адреси за такими ознаками, як шкідливе ПЗ, застосунки «безкоштовного VPN», що пропускають сторонній трафік через пристрій, участь в атаках перебором паролів або спроби ретранслювати пошту з викраденими обліковими даними. Якщо причина не зникає, IP-адресу знову вносять до списку під час наступного підключення.
• Неправильні налаштування й погана гігієна списків розсилання. Spamhaus CSS називає імена HELO, що не збігаються з прямим DNS, скомпрометовані сайти та встановлені CMS, незахищені конфігурації й погано підтримувані списки розсилання. Там сказано, що перед видаленням причину треба виявити й усунути.
• Записи за політикою. Spamhaus PBL охоплює адресний простір, часто домашній широкосмуговий доступ, з якого не слід надсилати пошту напряму. Spamhaus зазначає, що запис у PBL не є наслідком якихось дій кінцевого користувача; пошта з таких діапазонів має відправлятися через SMTP-сервер з автентифікацією.
• Спільна інфраструктура. На віртуальному хостингу надсилання пошти іншим клієнтом може вплинути на IP-адресу, якою користуєтеся ви. Див. що робити, якщо IP-адреса віртуального хостингу потрапила до чорного списку.

Яке місце DNSBL посідають, коли пошта не доставляється

Запис у DNSBL — одна з можливих причин недоставлення пошти, але не єдина. Повернення листів можуть спричинити й неправильні адреси, переповнені скриньки, проблеми на боці одержувача та відсутність автентифікації. Якщо причетний список, повідомлення про недоставлення часто називає його або містить URL для перевірки.

1. Прочитайте повідомлення про недоставлення. Зверніть увагу на код відповіді та будь-яку назву списку чи URL у тексті.
2. Визначте IP-адресу й домен відправника. Скористайтеся рядками Received у заголовках або зверніться до того, хто адмініструє сервер.
3. Перевірте основні списки одразу. Скористайтеся сервісом перевірки чорних списків, а потім підтвердьте кожен збіг на власній сторінці перевірки оператора.
4. Усуньте причину. Пройдіться за переліченими вище причинами. Запити, подані до усунення причини, зазвичай закінчуються повторним внесенням.
5. Дотримуйтеся процедури відповідного оператора. Одні записи зникають самі, для інших потрібен запит на видалення, а деякі списки приймають запити лише від власника мережі. Рішення про видалення зі списку завжди за оператором списку, і запит не є обіцянкою видалення.

Одержувачі також застосовують власне фільтрування, тож пошта може пройти не одразу після того, як запис зникне. Повну послідовність діагностики див. у статті пошта в чорному списку: як читати повідомлення про недоставлення, а щодо автентифікації — налаштування SPF, DKIM і DMARC. Якщо вам не вдається самостійно встановити причину, ви можете звернутися до нас по допомогу.

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

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

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

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Domain Blocklist (DBL)
• Spamhaus: Exploits Blocklist (XBL)
• Spamhaus: Combined Spam Sources (CSS)
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• dnswl.org: Return codes and recommended usage

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

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