Использование BIND RPZ дает мне именно то, что я ищу для изменения запросов. Однако мой рекурсивный DNS-сервер используется сотнями клиентов, и я ищу способ предоставить каждому клиенту определенный уровень настройки. Возможно, есть пара сотен зон, которые клиент может захотеть включить для создания тысяч различных возможных комбинаций.
Похоже, я ограничен 32 зонами RPZ (кажущейся бесконечной длины), но одно это не сработает - каждому пользователю нужна возможность выбрать определенные зоны. Даже с массивными зонами для каждого клиента он все равно достигнет 32-го лимита.
Я вкратце посмотрел на Unbound, который, похоже, имеет аналогичную настройку RPZ с прозрачностью локальных данных, но веселье, похоже, закончилось поиском способа разделения вещей на представления, чтобы я мог обслуживать их только определенным клиентам.
Конечно, есть способ добиться этого, не изобретая велосипед заново? Я вижу, что коммерческие поставщики предлагают аналогичные настройки, например, OpenDNS, где тысячи клиентов могут переключать различные списки. В чем секрет соуса?
Во-первых, это помогает понять, почему существует ограничение.
Механизм РПЗ в BIND 9.10 не изменился. Документация в статье базы знаний AA-00525 (Создание DNS-брандмауэров с зонами политики ответа (RPZ) все еще почти актуальна. В BIND 9.10 изменилось то, что теперь можно использовать до 32 отдельных файлов RPZ в одном экземпляре BIND, и этот BIND не сильно замедляется из-за такого интенсивного использования RPZ. Каждый из этих 32 файлов зоны политики может указывать политику для любого необходимого количества различных доменов. Предел 32 - это количество независимо заданных коллекций политик и а не количество зон, для которых они определяют политику.
В более ранних версиях BIND, в которых был реализован RPZ, наличие более одного файла зоны RPZ требовало, чтобы BIND выполнял отдельный поиск в каждой зоне политики, чтобы увидеть, было ли совпадение. В BIND 9.10 информация о политике хранится в дереве счисления, в котором одновременный поиск по всем зонам политик может выполняться за сублинейное время, которое приблизительно пропорционально логарифму числа заявлений политики в самой большой коллекции (зона RPZ ).
Улучшенная реализация RPZ для BIND 9.10 была предоставлена Верноном Шрайвером и Полом Викси. Это быстрее, потому что это O (log n) по размеру политики и потому, что он может искать несколько элементов данных параллельно. Новый предел в 32 является результатом использования 32-разрядного битового поля для определения зон политики, влияющих на запрос. Предыдущие реализации RPZ были O (n), а не O (log n).
Я подчеркнул соответствующее словоблудие. Единственный способ изменить ограничение в 32 - обновить алгоритм для использования большего битового поля или полностью удалить код оптимизации. Даже если бы вам пришлось удвоить размер битового поля до 64 (или повторно удвоить до 128 и т. Д.), Вы все равно имеете дело со статическим ограничением, налагаемым оптимизацией дерева оснований. Поскольку я не знаком с внутренностями этого алгоритма, я также не могу сказать, насколько эффективной будет такая попытка для начала.
Вы можете обойти это, используя представления, которые соответствуют вашим индивидуальным клиентам, что даст вам 32 зоны RPZ на одного клиента, но это все, что вы собираетесь сделать, не углубляясь в исходный код.