Ключевые новшества BIND 9.9.0:

• Технология "Inline Signing", позволяющая существенно упростить перевод текущей инфраструктуры на использование DNSSEC без нарушения привычного цикла сопровождения DNS. Выполнение таких операций, как формирование цифровых подписей для DNS-зон и управление ключами, теперь существенно упрощено и не приводит к усложнению или необходимости внесения изменений в текущее рабочее окружение. Переход на DNSSEC может быть выполнен c использованием полностью автоматического и прозрачного процесса формирования цифровых подписей.

  Для активации прозрачного формирования подписей в настройки master-зоны достаточно добавить опцию 'inline-signing yes', без необходимости внесения изменений непосредственно в файл зоны. Использование данной опции на slave-сервере позволяет задействовать DNSSEC даже для зон, master-сервер которых не поддерживает DNSSEC. Готовые примеры конфигурации "Inline Signing" можно посмотреть на данной странице.

• Значительно увеличена скорость запуска. При наличии большого числа зон время запуска сократилось в среднем от 3 до 20 раз. Для конфигураций с огромным числом зон изменения более ощутимы - время запуска сервера с 500 тысячами зон сократилось с пяти с половиной часов до 2-3 минут, при росте потребления памяти на 2%. Подобного эффекта удалось достигнуть благодаря устранению ошибки и более активному использованию многопоточности. Проблема была вызвана неверным выбором размера пула одновременно выполняемых в BIND внутренних задач. При загрузке для обслуживания каждой зоны создается своя внутренняя задача, в рамках которой кроме разбора данных выполняются такие требующие времени действия, как отправка SOA-запросов master-серверам и отправка NOTIFY-уведомлений slave-серверам, сброс на диск дампа динамических зон и генерация DNSSEC-сигнатур. Так как по умолчанию число одновременно выполняемых задач было ограничено 8, все эти действия по сути выполнялись последовательно.

  Кроме того, на 50% увеличена скорость обработки slave-зон за счёт их кэширования в более эффективном бинарном формате, вместо текстового представления. Минимизировано время простоя сервера при выполнении операции 'rndc reconfig'.

• Увеличение производительности на многопроцессорных системах. При сборке с поддержкой многопоточности и при запуске сервера на многоядерных системах под управлением Unix или Linux, named отныне одновременно использует несколько потоков для обработки входящего UDP-трафика. На некоторых системах подобный подход позволяет добиться значительного увеличения производительности обработки запросов. Дополнительно, основательно переработан код системы управления и увеличена масштабируемость клиента для обслуживания рекурсивных запросов (ранее наблюдались провалы в производительности при запуске на системах с более чем 8 процессорными ядрами).
• Реализация механизма перенаправления NXDOMAIN, позволяющего при обработке запроса клиента в ситуации выявления отсутствия домена, вместо вывода ответа NXDOMAIN ("no such domain") перенаправить клиента на заданный IP. Например, провайдеры могут направлять пользователей на хост с сайтом, анализирующим ошибки в написании имени и предлагающим перейти по корректному адресу.
• Улучшение в работе команд RNDC. Добавлена новая команда 'rndc flushtree' для очистки кэша DNS для всех имён поддоменов, относительно заданного имени. Команды 'rndc freeze' и 'rndc thaw' более не удаляют файл с журналом зон, что позволяет использовать настройку 'ixfr-from-differences' с динамически создаваемыми зонами. Для синхронизации и удаления журнала зон следует использовать команду 'rndc sync -clean'.
• Общие улучшения в работе DNSSEC. Новая команда 'rndc signing' позволяет повысить наглядность и управляемость за процессом автоматического формирования подписей DNSSEC. Через 'rndc signing' теперь также можно изменять для зоны конфигурацию параметров NSEC3.
• Опция 'also-notify' теперь поддерживает тот же синтаксис, что и опция 'masters'. Подобное изменение позволяет, например, указывать TSIG-ключи для нотификации.
• Новая опция 'serial-update-method' даёт возможность выбрать каким образом изменять номер SOA-записи для динамических зон (например, увеличивать каждый раз на единицу или использовать текущее время).