RPZ (Response Policy Zone) в BIND9 — механизм переписывания ответа рекурсивного резолвера по набору правил. На практике это «DNS firewall»: вы централизованно блокируете вредоносные домены, трекеры, фишинговые зоны и шумные эндпойнты, а также строите allowlist (разрешённое в приоритете), чтобы не ломать критичные сервисы.
Ниже — рабочий, эксплуатационный подход: включение RPZ в BIND9, структура policy zones, типы действий, allowlist-исключения, порядок срабатывания, минимально достаточное логирование и методика отладки. Формат намеренно «сделал → проверил → посмотрел логи».
Что такое BIND9 RPZ и чем он отличается от обычной зоны
Классическая authoritative-зона отвечает «как владелец домена». RPZ применяется на стороне рекурсивного резолвера (recursive resolver) и может переписать ответ до того, как он уйдёт клиенту. То есть вы не меняете внешний DNS домена — вы меняете то, что увидят пользователи/сервера при резолвинге через ваш BIND.
Чем RPZ полезен в эксплуатации:
- работает на уровне доменных имён и некоторых атрибутов ответа (включая триггеры по IP в A/AAAA через отдельные механизмы RPZ);
- поддерживает разные действия: NXDOMAIN/NODATA, CNAME на «заглушку», PASSTHRU (разрешить);
- позволяет разруливать конфликты «denylist vs allowlist» приоритетом и порядком policy zones;
- не требует агентского ПО: достаточно перевести клиентов на ваш резолвер.
Когда RPZ — хороший выбор (и где осторожнее)
Типовые кейсы, где RPZ даёт быстрый эффект:
- Офис/команда/прод: запрет фишинга и малвари на уровне инфраструктуры.
- Серверные сегменты: усиление egress-control через контроль DNS, особенно в контейнерных и CI средах.
- Снижение шума: блокировка доменов телеметрии/рекламы, если это не конфликтует с политиками компании.
- Инциденты: быстрое «отрубание» домена IOC на время расследования.
RPZ не поможет, если приложение обращается по hardcoded IP или использует DoH/DoT в обход вашего резолвера. В таких сценариях нужен сетевой контроль egress и политика на рабочих станциях/шлюзах.
Где нужна аккуратность: SaaS с динамическими доменами (цепочки CNAME), приложения с pinned endpoints, интеграции «сломался один домен — упал бизнес-процесс». Здесь обязательно планируйте allowlist и наблюдаемость (логи + метрики), а изменения катите через тестовый контур.
Архитектура: как обычно строят DNS firewall на BIND9
Практичная схема выглядит так:
- BIND9 работает как рекурсивный резолвер для внутренних клиентов (сети, VPN, VPC).
- RPZ подключается в
optionsчерезresponse-policyи список policy zones. - Обычно используют как минимум две зоны: deny (блокировки) и allow (исключения/разрешения). Иногда добавляют отдельную зону для «redirect на заглушку».
- Обновление списков: локальные файлы, master/slave, либо генерация из фидов (под ваши правила комплаенса) с проверками и откатом.
Если вы выбираете, на чём поднимать резолвер, ориентируйтесь на изоляцию и предсказуемость ресурса. Для продового резолвера чаще удобнее отдельная виртуальная машина: так проще держать одинаковую конфигурацию, обновления и логи.
Базовая конфигурация: включаем RPZ в named.conf
Ниже — минимальный пример с двумя policy zones: rpz-allow и rpz-deny. Allowlist указан первым: если домен присутствует и там, и там — разрешение победит. Это самая удобная модель эксплуатации, потому что исключения всегда «сильнее» блокировок.
options {
recursion yes;
allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 127.0.0.1; };
listen-on { 127.0.0.1; 10.0.0.10; };
response-policy {
zone "rpz-allow";
zone "rpz-deny";
};
};
zone "rpz-allow" {
type master;
file "/etc/bind/rpz/rpz-allow.db";
allow-query { none; };
};
zone "rpz-deny" {
type master;
file "/etc/bind/rpz/rpz-deny.db";
allow-query { none; };
};Комментарии к важным местам:
response-policy— список policy zones. Порядок важен и определяет приоритет при конфликте.allow-query { none; }— чтобы RPZ-зону нельзя было «снять» как обычную зону запросом извне.- Ограничивайте рекурсию через
allow-recursion(и дополнительно на фаерволе), иначе есть риск получить открытый резолвер.
Если вы мигрируете с другого DNS-стека или сравниваете подходы, полезно держать под рукой обзор различий по возможностям и эксплуатации: сравнение PowerDNS и BIND для инфраструктурных задач.
Файл RPZ-зоны: что внутри и как устроены правила
RPZ-зона по формату похожа на обычную DNS-зону, но имена в ней — это «триггеры политики». В простейшем варианте блокируем домен и поддомены CNAME-правилом.
Пример deny-zone:
$TTL 60
@ IN SOA localhost. root.localhost. (
2026011001 ; serial
1H ; refresh
15M ; retry
7D ; expire
1H ) ; minimum
IN NS localhost.
; Блокировка домена целиком и всех поддоменов
bad.example. CNAME .
*.bad.example. CNAME .
; Точечная блокировка конкретного поддомена
ads.goodservice.example. CNAME .Что означает CNAME . в контексте RPZ: это «policy action» (синтетический ответ, который по смыслу эквивалентен блокировке). В эксплуатации такой шаблон часто используют как «жёсткий стоп» на имя.
Если вам важно, чтобы пользователь видел понятное объяснение в браузере, вместо «глухой» блокировки можно сделать редирект на walled garden (CNAME на домен заглушки), а заглушка отдаст страницу с текстом и контактами. Для сервисов/агентов это обычно хуже (лишний шум), а для пользовательских сегментов иногда удобнее.
Allowlist в RPZ: как делать исключения правильно
Allowlist обычно нужен в двух случаях: (1) denylist слишком широкий и задевает нужные домены; (2) у вас есть зоны, которые нельзя блокировать ни при каких условиях (например, критичная интеграция).
Пример allow-zone: «пропусти как есть» через CNAME на rpz-passthru.
$TTL 60
@ IN SOA localhost. root.localhost. (
2026011001 ; serial
1H
15M
7D
1H )
IN NS localhost.
; Разрешаем домен и поддомены (исключение)
important.example. CNAME rpz-passthru.
*.important.example. CNAME rpz-passthru.
; Разрешаем конкретный поддомен, даже если весь домен в deny
api.vendor.example. CNAME rpz-passthru.Ключевая идея: allowlist — отдельная policy zone, которая стоит раньше deny. Тогда вы не превращаете deny-файл в «кашу исключений», которую невозможно сопровождать.
Хорошее правило процесса: исключения добавляются только в allow-zone, а deny-zone генерируется автоматически из источников. Так вы снижаете риск ручных правок в проде и упрощаете откат.
Приоритеты policy zones: что делать при конфликте правил
Конфликты возникают, когда одно имя совпало с правилами в нескольких зонах. Самая практичная модель приоритетов:
- Сначала allowlist (PASSTHRU), затем deny/redirect.
- В deny-zone держите только блокировки/редиректы, без исключений.
- Если нужно несколько deny-политик (например, «строгая» и «мягкая»), разделяйте на разные зоны и задавайте порядок в
response-policy.
Настройки, которые часто забывают в проде
Чтобы RPZ работал предсказуемо, обычно дополнительно фиксируют:
- Контроль клиентов: кроме
allow-recursionиспользуйтеallow-query-cache, ACL и входной сетевой firewall. - TTL для RPZ: часто держат 60–300 секунд, чтобы быстро чинить ложные срабатывания, но не устраивать постоянный churn.
- Серийник и перезагрузка: при правках зоны повышайте serial и делайте reload конкретной зоны, а не всей службы.
Команды контроля (универсальный набор):
named-checkconf
named-checkzone rpz-deny /etc/bind/rpz/rpz-deny.db
named-checkzone rpz-allow /etc/bind/rpz/rpz-allow.db
rndc reload rpz-deny
rndc reload rpz-allow
rndc statusЕсли у вас сложная DNS-архитектура (внутренние/внешние зоны, разные ответы в зависимости от сети), RPZ часто комбинируют с views. См. практический разбор: split-horizon и views в BIND.
DNS logging: как логировать RPZ и не утонуть в логах
DNS-запросы очень шумные, поэтому «логировать всё» почти всегда означает гигабайты в сутки и потерю смысла. Для RPZ полезнее логировать именно срабатывания политики и немного контекста.
Пример конфигурации логирования (пути адаптируйте под вашу систему):
logging {
channel rpz_log {
file "/var/log/named/rpz.log" versions 10 size 50m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel queries_log {
file "/var/log/named/queries.log" versions 5 size 100m;
severity info;
print-time yes;
print-category yes;
};
category rpz { rpz_log; };
category queries { queries_log; };
};Практика такая:
- на постоянке держите
category rpz(срабатывания политики) и ограниченную ротацией глубину; category queriesвключайте на время расследования, либо на отдельном резолвере, если у вас пул.
Для расследований важнее корреляция (время, клиент, имя, действие), чем полный дамп всех DNS-запросов.
Проверка: как убедиться, что RPZ реально срабатывает
После включения проверьте по шагам:
- резолвер доступен клиенту и реально рекурсирует;
- домен из deny-zone отдаёт ожидаемый результат (блок/редирект);
- домен из allow-zone действительно «пробивает» блокировку;
- в логе RPZ появляются записи о срабатывании.
Типовые команды диагностики:
dig @127.0.0.1 bad.example A
dig @127.0.0.1 api.vendor.example A
dig @127.0.0.1 ads.goodservice.example A
rndc querylog
rndc querylogrndc querylog — переключатель: включили, собрали нужные события, выключили, чтобы не оставить вечный шум.
Типовые ошибки при внедрении RPZ
1) Открытый резолвер из-за неверных ACL
Если включили рекурсию и не ограничили клиентов, резолвер может стать публичным. Обязательно используйте ACL на allow-recursion и/или allow-query-cache и дублируйте ограничения сетевым firewall на вход.
2) Allowlist «не работает» из-за порядка policy zones
Проверьте порядок в response-policy: allow-zone должна идти раньше deny-zone. Если несколько deny-зон, зафиксируйте соглашение по порядку и не нарушайте его.
3) «Ломаем CDN» из-за слишком широких правил
Блокировать базовый домен провайдера (особенно CDN/антибот) часто означает блокировать десятки легитимных сервисов. Вводите стадию тестирования: сначала наблюдение (логирование + отчёт), потом включение блокировок.
4) Нет процесса обновления и отката
RPZ — это контент, а контент ломается. Храните зоны в Git, делайте генерацию с проверками (named-checkzone), применяйте атомарно и держите быстрый rollback (предыдущий файл + reload конкретной зоны).
Практика эксплуатации: как вести deny/allow списки без боли
Правила, которые хорошо работают в командах DevOps:
- Разделяйте источники: deny — только генерация, allow — ручной список исключений (и тоже под контролем версий).
- Короткий TTL для RPZ (60–300 секунд), чтобы быстро чинить ложные срабатывания.
- Единый формат: если хотите блокировать «всё дерево», добавляйте и apex, и wildcard (
example.tld.и*.example.tld.). - Минимальная наблюдаемость: отдельный лог для RPZ, ротация, быстрый поиск по домену и времени.
- Плейбук инцидента: добавить в allow → reload → проверить → оформить постоянное исключение или исправить источник deny.
Если вы публикуете сервисы наружу и вам важна доверенная цепочка резолвинга и соответствие требованиям безопасности, отдельно продумайте политику DNSSEC и управление ключами. В такой схеме часто появляется потребность в управляемых SSL-сертификатах для внутренних админок/порталов и сервисов мониторинга, чтобы не плодить самоподписанные сертификаты.
Заключение
BIND9 с Response Policy Zone — один из самых практичных способов собрать управляемый DNS firewall в своей инфраструктуре: предсказуемые политики, быстрые исключения через allowlist и нормальная эксплуатация при условии, что вы продумали порядок policy zones, ограничения рекурсии и dns logging.
Следующий логичный шаг: автоматизация генерации зон из нескольких источников, тестовый резолвер для «сухого прогона» и отчётность по срабатываниям (сколько блоков, какие домены, какие клиенты).
