Вопрос или проблема
Я пытаюсь создать лабораторию, чтобы воспроизвести проблему, с которой мы сталкиваемся, однако столкнулся с проблемой.
Настройка: две инстанции bind, работающие на разных портах на одном сервере.
Инстанция A: Настроена с простой политикой RPZ, которая блокирует example.com, разрешен рекурсивный запрос с localhost и любого другого адреса. [порт 54]
Инстанция B: Настроена на “только пересылка” с инстанцией A в качестве единственного пересылающего сервера; [порт 55]
Тест 1 – ожидаемые результаты
Запрос к инстанции A с помощью dig “dig example.com @127.0.0.1 -p54” возвращает следующее (правильные результаты, NXDOMAIN)
; <<>> DiG 9.18.28-0ubuntu0.20.04.1-Ubuntu <<>> example.com @127.0.0.1 -p54
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52665
;; флаги: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флаги:; udp: 1232
; COOKIE: 8300a71b26db4dfe0100000067086bb06e4a20d874d17582 (хорошо)
;; СЕКЦИЯ ВОПРОСА:
;example.com.INA
;; ДОПОЛНИТЕЛЬНАЯ СЕКЦИЯ:
rpz.example.com.60INSOAlocalhost. need.to.know.only. 201702121 60 60 432000 60
;; Время запроса: 4 мсек
;; СЕРВЕР: 127.0.0.1#54(127.0.0.1) (UDP)
;; КОГДА: Пт Окт 11 00:05:04 UTC 2024
;; РАЗМЕР СООБЩЕНИЯ rcvd: 134
и логи инстанции A показывают
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119: UDP запрос
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119: использование представления '_default'
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119: запрос не подписан
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119: рекурсия доступна
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119 (example.com): запрос (кэш) 'example.com/A/IN' одобрен
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119 (example.com): попытка переписывания QNAME RPZ example.com через example.com.rpz.example.com
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119 (example.com): переписывание QNAME RPZ NXDOMAIN example.com/A/IN через example.com.rpz.example.com
11-Окт-2024 00:07:47.061 клиент @0x7f8b1c1a1318 127.0.0.1#50119 (example.com): сброс клиента
Тест 2 – некорректные результаты
Запрос к инстанции B с помощью dig “dig example.com @127.0.0.1 -p55” возвращает следующее (некорректные результаты)
; <<>> DiG 9.18.28-0ubuntu0.20.04.1-Ubuntu <<>> example.com @127.0.0.1 -p55
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24269
;; флаги: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флаги:; udp: 1232
; COOKIE: 1e0aad6357bd5b840100000067086d59a3953dc8128220a1 (хорошо)
;; СЕКЦИЯ ВОПРОСА:
;example.com.INA
;; СЕКЦИЯ ОТВЕТА:
example.com.1INA93.184.215.14
;; Время запроса: 4 мсек
;; СЕРВЕР: 127.0.0.1#55(127.0.0.1) (UDP)
;; КОГДА: Пт Окт 11 00:12:09 UTC 2024
;; РАЗМЕР СООБЩЕНИЯ rcvd: 84
Логи инстанции A показывают, что она обрабатывает запрос; но не использует RPZ.
11-Окт-2024 00:12:09.757 клиент @0x7f8b1c1a1318 127.0.0.1#33523: UDP запрос
11-Окт-2024 00:12:09.757 клиент @0x7f8b1c1a1318 127.0.0.1#33523: использование представления '_default'
11-Окт-2024 00:12:09.757 клиент @0x7f8b1c1a1318 127.0.0.1#33523: запрос не подписан
11-Окт-2024 00:12:09.757 клиент @0x7f8b1c1a1318 127.0.0.1#33523: рекурсия доступна
11-Окт-2024 00:12:09.757 клиент @0x7f8b1c1a1318 127.0.0.1#33523 (example.com): запрос (кэш) 'example.com/A/IN' одобрен
11-Окт-2024 00:12:09.757 клиент @0x7f8b1c1a1318 127.0.0.1#33523 (example.com): сброс клиента
Тест 3 – тест на отказ
Просто для полноты картины, если инстанция A будет остановлена, запросы к инстанции B будут завершаться с ошибкой SERVFAL, подтверждая, что ИНСТАНЦИЯ B использует ИНСТАНЦИЮ A, а не находит другой путь.
Может кто-нибудь подсказать, что происходит и как заставить инстанцию A предоставлять RPZ-ответы инстанции B?
Ответ или решение
Для решения вашей проблемы, связанной с настройкой двух экземпляров BIND на одном сервере, давайте внимательно рассмотрим настройки и причины, по которым Instance B не получает ответы RPZ от Instance A.
Анализ текущей ситуации
Вы имеете две установки BIND на разных портах (54 и 55), где:
- Instance A (порт 54) настроен с использованием политики RPZ, которая блокирует
example.com. - Instance B (порт 55) настроен на "только пересылка" с Instance A как единственным пересылающим сервером.
Проблема
Как вы заметили, результаты тестов указывают на то, что Instance A корректно возвращает NXDOMAIN для запросов к example.com, тогда как Instance B отвечает NOERROR с записью A, что неверно.
Возможные причины
-
Кэширование DNS: Возможно, Instance B запоминает (кэширует) неправильный ответ на запрос от Instance A. Это может быть связано с тем, что кэширование ответа о существовании
example.comвмешивается в обработку RPZ. -
Кэшированные ответы на стороне Instance A: Обратите внимание, что если вы запрашиваете
example.comслишком часто, и в кэше Instance A сохранен неправильный ответ, это может повлиять на то, как Instance B обрабатывает запросы. -
Настройки пересылки: Настройка Instance B на использование "только пересылки" подразумевает, что он не будет кэшировать ответы, однако способ, которым он обрабатывает ответы от Instance A, может привести к неправильному интерпретированию статус-кода ответов.
Рекомендации по устранению неполадок
-
Очистка кэша: Попробуйте очистить кэш обеих инстанций BIND. Для Instance B можно попробовать временно отключить кэширование, а для Instance A использовать команду:
rndc flush -
Изменение настроек Instance B: Попробуйте временно изменить настройки Instance B, чтобы он не использовал "только пересылку", а также добавьте опцию для включения кэширования, чтобы проверить, изменится ли поведение.
-
Проверка правил RPZ: Убедитесь, что RPZ настроен корректно и что
example.comправильно соответствует правилам блокировки. Вы можете использовать следующие команды, чтобы проверить, как правила применяются в реальном времени:rndc rpz show -
Логирование: Включите более подробное логирование для обоих экземпляров BIND. Это поможет получить больше информации о том, какие запросы обрабатываются и как они обрабатываются. Например, убедитесь, что в конфигурации стоит:
logging { channel default_log { file "data/named.log"; severity info; print-time yes; }; category default { default_log; }; }; -
Тестирование независимых запросов: Протестируйте Instance A напрямую, чтобы убедиться, что только Instance A отвечает корректно. Запросы к Instance B не должны возвращать ответ, если Instance A не отвечает должным образом.
-
Проверка конфигурации: Убедитесь, что в конфигурации Instance B правильно указаны адреса и порты для пересылки. Можно проверить, чтобы Instance A был указан в конфигурации как
forwarders:forwarding { forwarders { 127.0.0.1 port 54; }; };
Заключение
Эти шаги должны помочь вам диагностировать и устранить проблему с тем, что Instance A не передает правильные RPZ-ответы Instance B. Пожалуйста, проводите тестирование после каждого изменения, чтобы узнать, повлияло ли это на функциональность. Если проблемы сохраняются, возможно, стоит рассмотреть возможность обращения за поддержкой к сообществу BIND или консультантам по DNS.