После двух лет разработки консорциум ISC представил первый стабильный релиз новой значительной ветки DNS-сервера BIND 9.18. Поддержка ветки 9.18 будет осуществляться в течение трёх лет до 2 квартала 2025 года в рамках расширенного цикла сопровождения. Поддержка ветки 9.11 прекратится в марте, а ветки 9.16 в середине 2023 года. Для развития функциональности следующей стабильной версии BIND сформирована экспериментальная ветка BIND 9.19.0.
Выпуск BIND 9.18.0 примечателен реализацией поддержки технологий «DNS поверх HTTPS» (DoH, DNS over HTTPS) и DNS поверх TLS (DoT, DNS over TLS), а также механизма XoT (XFR-over-TLS) для безопасной передачи содержимого DNS-зон между серверами (поддерживается как отдача, так и приём зон по XoT). При соответствующих настройках один процесс named теперь может обслуживать не только традиционные DNS-запросы, но и запросы, отправленные с использованием DNS-over-HTTPS и DNS-over-TLS. Клиентская поддержка DNS-over-TLS встроена в утилиту dig, которая может использоваться для отправки запросов поверх TLS при указании флага «+tls».
Реализация протокола HTTP/2, используемого в DoH, основана на применении библиотеки nghttp2, которая включена в число необязательных сборочных зависимостей. Сертификаты для DoH и DoT могут предоставляться пользователем или генерироваться автоматически во время запуска.
Обработка запросов с использованием DoH и DoT включается через добавление опций «http» и «tls» в директиве listen-on. Для поддержки незашифрованного DNS-over-HTTP в настройках следует указать «tls none». Ключи определяются в секции «tls». Стандартные сетевые порты 853 для DoT, 443 для DoH и 80 для DNS-over-HTTP могут быть переопределены через параметры tls-port, https-port и http-port. Например:
tls local-tls { key-file «/path/to/priv_key.pem»; cert-file «/path/to/cert_chain.pem»; }; http local-http-server { endpoints { «/dns-query»; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
Из особенностей реализации DoH в BIND отмечается возможность выноса операций шифрования для TLS на другой сервер, что может понадобиться в условиях, когда хранение TLS-сертификатов осуществляется на другой системе (например, в инфраструктуре с web-серверами) и обслуживается другим персоналом. Поддержка незашифрованного DNS-over-HTTP реализована для упрощения отладки и как уровень для проброса на другой сервер во внутренней сети (для выноса шифрования на отдельный сервер). На выносном сервере для формирования TLS-трафика может использоваться nginx, по аналогии с тем, как организуется обвязка HTTPS для сайтов.
Другой особенностью является интеграция DoH в качестве общего транспорта, который может применяться не только для обработки запросов клиентов к резолверу, но и при обмене данными между серверами, при передаче зон авторитетным DNS-сервером и при обработке любых запросов, поддерживаемых другими транспортами DNS.
Из недостатков, которые можно будет компенсировать отключением сборки с DoH/DoT или выносом шифрования на другой сервер, выделяется общее усложнение кодовой базы — в состав добавляется встроенный HTTP-сервер и TLS-библиотека, которые потенциально могут содержать уязвимости и выступать дополнительными векторами для атак. Также при использовании DoH увеличивается трафик.
Напомним, что DNS-over-HTTPS может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками и подменой DNS-трафика (например, при подключении к публичным Wi-Fi), противостояния блокировкам на уровне DNS (DNS-over-HTTPS не может заменить VPN в области обхода блокировок, реализованных на уровне DPI) или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DNS-over-HTTPS запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API.
«DNS over TLS» отличается от «DNS over HTTPS» применением штатного протокола DNS (обычно используется сетевой порт 853), завёрнутого в шифрованный канал связи, организованный при помощи протокола TLS с проверкой валидности хоста через TLS/SSL-сертификаты, заверенные удостоверяющим центром. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.
Некоторые другие новшества:
- Добавлены настройки tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer и udp-send-buffer для задания размеров буферов, используемых при отправке и приёме запросов по TCP и UDP. На нагруженных серверах увеличение входящих буферов позволит избежать отбрасывания пакетов в момент пиков трафика, а уменьшение — поможет избавиться от засорения памяти старыми запросами.
- Добавлена новая категория логов «rpz-passthru», позволяющая отдельно журналировать действия проброса RPZ (Response Policy Zones).
- В секции response-policy добавлена опция «nsdname-wait-recurse», при установке которой в значение «no» правила RPZ NSDNAME применяются только если для запроса найдены присутствующие в кэше авторитетные серверы имён, иначе правило RPZ NSDNAME игнорируется, но информация извлекается в фоне и применяется к последующим запросам.
- Для записей с типами HTTPS и SVCB реализована обработка секции «ADDITIONAL».
- Добавлены настраиваемые типы правил update-policy — krb5-subdomain-self-rhs и ms-subdomain-self-rhs, позволяющие ограничить обновление записей SRV и PTR. В блоках update-policy также добавлена возможность установки ограничений числа записей, отдельных для каждого типа.
- В вывод утилиты dig добавлены сведения о транспортном протоколе (UDP, TCP, TLS, HTTPS) и префиксах DNS64. Для отладочных целей в dig добавлена возможность указания конкретного идентификатора запроса (dig +qid=<num>).
- Добавлена поддержка библиотеки OpenSSL 3.0.
- Для решения проблем с IP-фрагментацией при обработке DNS-сообщений большого размера, обозначенных инициативой DNS Flag Day 2020, из резолвера удалён код, выполняющий корректировку размера буфера EDNS в случае отсутствия ответа на запрос. Размер буфера EDNS теперь устанавливается постоянным (edns-udp-size) для всех исходящих запросов.
- Система сборки переведена на использование связки из autoconf, automake и libtool.
- Прекращена поддержка файлов зон в формате «map» (masterfile-format map). Пользователям данного формата рекомендовано преобразовать зоны в формат raw при помощи утилиты named-compilezone.
- Прекращена поддержка старых драйверов DLZ (Dynamically Loadable Zones), на смену которым пришли модули DLZ.
- Прекращена поддержка сборки и запуска для платформы Windows. Последней веткой, которую можно установить в Windows, остаётся BIND 9.16.
Источник: opennet.ru