Выпуск DNS-сервера BIND 9.20.0, переведённый на libuv и новый бэкенд для БД
После двух с половиной лет разработки консорциум ISC представил первый стабильный релиз новой значительной ветки DNS-сервера BIND 9.20, который вобрал в себя изменения, развивавшиеся в экспериментальной ветке BIND 9.19. Поддержка ветки 9.20 будет осуществляться в рамках расширенного цикла сопровождения до первого квартала 2028 года. Поддержка ветки 9.18 прекратится во 2 квартале 2025 года. Для развития функциональности следующей стабильной версии BIND будет сформирована экспериментальная ветка BIND 9.21.0. Код проекта написан на языке Си и распространяется под лицензией MPL 2.0.
Основные изменения:
Ядро приложения, связывающее все компоненты, переведено на использование цикла обработки событий в неблокирующем режиме, реализованного на основе библиотеки libuv, применяемой в таких проектах, как Node.js, Knot DNS, H2O, Luvit и MoarVM. В ветке 9.16 на libuv был переведён менеджер сетевых соединений в BIND, а теперь и части, используемые для взаимодействия внутренних компонентов инфраструктуры, а также длительно выполняемые в отдельных потоках вспомогательные обработчики (threadpool), используемые для верификации DNSSEC, трансфера зон, поддержания каталога зон и обработки RPZ (Response Policy Zone). Для сборки BIND теперь требуется как минимум выпуск libuv 1.34.0.
Предложен новый бэкенд для работы с БД — «QP trie», который пришёл на смену RBTDB (Red-Black Tree Database) и задействован по умолчанию для хранения кэша и базы DNS-зон. Для многопоточной работы в QP trie задействована библиотека liburcu с реализацией в пространстве пользователя структур, не использующих блокировки, благодаря применению механизма синхронизации RCU (read-copy-update) и метода безопасного освобождения памяти QSBR (Quiescent-State-Based Reclamation).
Задействован обновлённый механизм сжатия доменных имён, использующий более компактный метод кодирования имён с большим числом меток.
Расширены возможности DNSSEC: «dnssec-policy» разрешено применять для управления подписанными зонами (опция auto-dnssec удалена); при использовании «inline-signing» добавлена поддержка RFC 8901 (DNSSEC multi-signer model 2); возобновлена поддержка PKCS#11 на базе OpenSSL 3.0.0 Engine API; в «dnssec-policy» добавлена поддержка HSM (Hardware Security Module).
Добавлена поддержка второй версии каталога зон (Catalog Zone, RFC 9432), упрощающего поддержание вторичных DNS-серверов за счёт того, что вместо определения на вторичном сервере отдельных записей для каждой вторичной зоны, между первичным и вторичным серверами организуется передача каталога вторичных зон. После настройки передачи каталога по аналогии с передачей отдельных зон, заводимые на первичном сервере зоны, помеченные как входящие в каталог, автоматически создаются на вторичном сервере без необходимости правки файлов конфигурации.
Добавлена поддержка механизма расширенных ошибок (Extended DNS Errors, RFC 8914), позволяющего возвращать дополнительную информацию о причине ошибки, возникшей при выполнении DNS-запроса.
Реализация технологий «DNS поверх HTTPS» (DoH, DNS over HTTPS) и DNS поверх TLS (DoT, DNS over TLS), применяемых для шифрования запросов клиентов к резолверу и шифрованного обмена данными между серверами, переведена на использование унифицированного транспорта.
Добавлена возможность использования протокола PROXYv2 со всеми транспортами, поддерживаемыми в BIND. Протокол PROXY позволяет передавать информацию о соединении для сохранения сведений об исходном IP-адресе и номере порта при пробросе DNS-запросов через другие бэкенды, балансировщики нагрузки и прокси-серверы.
Добавлена поддержка режима USDT (User Statically Defined Tracing), дающего возможность выполнять трассировку приложения при помощи команды perf, не создавая дополнительные накладные расходы, когда трассировка отключена.
В собираемой статистике реализовано отражения информации о незавершённых входящих операциях передачи зон.
Проведена работа по сокращению задержек, уменьшению потребления памяти и снижению нагрузки на CPU при резолвинге, работе DNS-over-TLS и формировании ответов по UDP и TCP.
Источник: http://www.opennet.ru/opennews/art.shtml? num=61599
OpenNet прочитано 10907 раз
