BIND 9.14 не совместим с серверами без EDNS
После более года разработки консорциум ISC представил первый стабильный релиз новой значительной ветки DNS-сервера BIND 9.14. Поддержка ветки 9.14 будет осуществляться до 2 квартала 2020 года в рамках штатного цикла сопровождения. В следующем году будет сформирован LTS релиз 9.16, который будет поддерживаться три года. Обновления для прошлой LTS-ветки 9.11 продолжат выпускаться до декабря 2021 года. Поддержка ветки 9.12 прекратиться в июне.

BIND 9.14.0 стал первым стабильный выпуском, сформированным в рамках новой схемы нумерации версий. Нечётные номера релизов теперь присваиваются экспериментальным веткам, в которых развивается функциональность для будущих стабильных веток, имеющих чётный номер выпуска. Формирование отдельных альфа- и бета-веток прекращено. Таким образом, ветка BIND 9.13 была экспериментальной и на её базе сформирован стабильный релиз BIND 9.14.
Ключевым изменением в BIND 9.14.0 стало отключение кода, позволявшего взаимодействовать с DNS-серверами, на которых используется старое ПО с некорректно реализованной обработкой запросов EDNS (расширенные флаги, которые кодируются в специальных RR-записях без нарушения обратной совместимости со старым протоколом). Изменение не повлияет работу серверов, не поддерживающих EDNS, но корректно обрабатывающих запросы с флагами EDNS.

Проблемы могут возникнуть только с серверами, которые вопреки стандарту не отправляют DNS-ответ в старом формате, отбрасывая флаги EDNS, а молча игнорируют подобные запросы, никак не реагируя на них и не отправляя ответный пакет. При этом авторитативные DNS-серверы могут, как и раньше, не поддерживать EDNS и ограничиваться старым классическим протоколом, но теперь они обязаны корректно реагировать на подобные запросы. В настоящее время все актуальные DNS-серверы корректно отвечают на запросы с EDNS, а проблемные системы, как правило на основе старых выпусков PowerDNS, и блокирующие EDNS межсетевые экраны были уведомлены в рамках проведённой в феврале инициативы DNS flag day.

Ранее для обеспечения взаимодействия с серверами, не отвечавшими на запросы с флагами EDNS, в BIND применялся "грязный хак" - если после отправки запроса с флагами EDNS через определённый промежуток времени не поступал ответ, DNS-сервер считал, что расширенные флаги не поддерживаются и отправлял повторный запрос без флагов EDNS. Наличие подобного кода приводило к увеличению задержек из-за повторной отправки пакетов, повышению нагрузки на сеть и неоднозначности при отсутствии ответа из-за сетевых сбоев, а также мешало внедрению основанных на EDNS возможностей, таких как применение DNS Cookies для защиты от DDoS-атак.

Другие изменения в BIND 9.14.0:
  • Прекращена возможность сборки без OpenSSL и сборки без поддержки DNSSEC. Задействован предоставляемый библиотекой OpenSSL генератор псевдослучайных чисел (CSPRNG), работающий в неблокирующем режиме;
  • Для работы в UNIX-подобных ОС теперь требуется поддержка многопоточности (POSIX threads), расширенных параметров сокетов для IPv6 (RFC 3542) и Си-компилятора с поддержкой атомарных операций. При сборке в Linux для настройки привилегий процесса теперь требуется библиотека libcap;
  • Прекращено тестирование работы на устаревших ОС, включая старые версии UnixWare, BSD/OS, AIX, Tru64, SunOS, TruCluster и IRIX. Также удалена поддержка некоторых устаревших систем;
  • Существенно изменён код для управления задачами и работой с сокетами - задачи теперь распределяются с использованием очередей, закреплённых за ядрами CPU, а в сетевом стеке реализовано несколько циклов обработки событий, запускаемых в привязанных к CPU разных потоках. Указанные изменения позволили существенно повысить производительность на крупных многоядерных системах, особенно при использовании сетевых карт с поддержкой нескольких очередей обработки пакетов;
  • Добавлен новый механизм подключения плагинов, позволяющий подключать дополнительные обработчики запросов, реализованные в форме внешних библиотек. Со временем, планируется выделить в плагины код для обработки необязательных расширений, таких как средства противостояния DDoS-атакам. Например, в плагин filter-aaaa.so заменил собой встроенную реализацию filter-aaaa;
  • В named.conf помимо неполиткорректных названий "master" и "slave" теперь в качестве типов зон можно указывать "primary" и "secondary";
  • Включены по умолчанию в режиме "relaxed" наработки проекта QNAME Minimization (RFC-7816), нацеленные на сокращение передачи дополнительной информации в запросах с целью предотвращения утечек сведений о запрошенном домене и повышения приватности. В будущих выпусках планируется применить режим "strict". В указанном режиме резолвер не упоминает полное имя искомого хоста в своих запросах к вышестоящему серверу имён. Например, при определении адреса для хоста foo.bar.baz.com резолвер отправит авторитетному для зоны ".com" серверу запрос "QTYPE=NS,QNAME=baz.com", не упоминая "foo.bar";
  • Добавлен режим зеркалирования зон, позволяющий named получать и работать с локальными копиями зон, но без функционирования в форме авторитетного сервера для данных зон. DNS-ответы для зеркалируемых зон не устанавливают бит AA ("authoritative answer"), но выставляют бит AD ("authenticated data"). Основным назначением указанной возможности является обработка локальных копий корневой зоны DNS;
  • Существенно повышена производительность работы с большим числом зон, обработки большого числа запросов и работы с корневой зоной. Расширено применение glue-cache, ускорена работа сетевых обработчиков за счёт исключения миграции между ядрами CPU. В проведённых тестах по сравнению с BIND 9.12 производительность обработки тысячи зон возросла на 20%, миллиона зон на 15%, выполнение миллиона операций делегирования на 10%, обработка миллиона RR-запросов на 12%, рекурсивная обработка запросов на 18% и обработка корневой зоны на 10%;
  • Добавлена настройка validate-except для определения списка доменов, для которых не нужно производить валидацию DNSSEC;
  • Добавлена опция "--enable-fips-mode" для включения FIPS-режима в OpenSSL;
  • Добавлены новые настройки min-cache-ttl и min-ncache-ttl для переопределения минимального TTL для полученных DNS записей (positive caching) и несуществующих записей (negative caching);
  • Добавлена поддержка сборки с библиотекой libidn2 для поддержки интернационализированных имён IDNA2008 (ранее поддерживалась только библиотека idnkit-1 и IDNA2003).
Вы должны войти

loading