Альтернативные способы преодолеть ограничение зоны 32 rpz в BIND? ... без запуска BIND тысячу раз
Использование BIND RPZ дает мне именно то, что я ищу для изменения запросов. Тем не менее, мой рекурсивный DNS-сервер используется сотнями клиентов, и я ищу способ предоставить каждому клиенту определенный уровень настройки. Возможно, клиент может захотеть включить пару сотен зон для создания тысяч различных возможных комбинаций.
Похоже, я ограничен 32 зонами RPZ (кажущейся бесконечной длины), но это само по себе не сработает - каждому пользователю нужна возможность подключения к определенным зонам. Даже с массивными зонами для каждого клиента он все равно достигнет 32 предела.
Я кратко посмотрел на Unbound, который, похоже, имеет аналогичную настройку RPZ с прозрачностью локальных данных, но, похоже, веселье закончилось, когда я искал способ разделить вещи на представления, чтобы я мог обслуживать их только определенным клиентам.
Конечно, есть способ сделать это, не изобретая колесо? Я вижу коммерческих провайдеров, предлагающих аналогичные установки, например OpenDNS, где тысячи клиентов могут переключаться между различными списками. Какой секретный соус?
1 ответ
First, it helps to understand why the limitation exists.
Механизм RPZ не изменился в BIND 9.10. Документация в статье KB 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-зоны для каждого клиента, но это все, что вы получите, не вдаваясь в исходный код.