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