Релиз DNS-сервера BIND 9.8.0Компания ISC представила первый стабильный релиз новой ветки DNS-сервера BIND 9.8. Из улучшений BIND 9.8 можно отметить: Вместо статической хэш-таблицы фиксированного размера для хранения кэша ответов от авторитативных DNS-серверов теперь задействован динамически расширяемый ADB hash. На нагруженных серверах новый хэш позволит избавиться от коллизий и исключит вызванные ими провалы во времени обслуживания запросов; Добавлена поддержка нового типа зон "static-stub", которые позволяют указать конкретные IP по которым следует обращаться для преобразования имен (resolving) заданных зон, в обход обслуживающих данные зоны DNS-серверов; Добавлена поддержка механизма Response Policy Zones, позволяющего на лету вычислять "репутацию" для DNS-имен через создание специальной децентрализованной DNS-зоны (аналог DNSBL для борьбы с хостами спамеров и мошенников); Добавлена поддержка DNS64, позволяющая автоматически синтезировать IPv6 AAAA-записи на основании IPv4 A-записей, а также IP6.ARPA CNAME блоки для существующих IN-ADDR.ARPA; В Dynamically Loadable Zones (DLZ) добавлена поддержка динамических обновлений и возможность создания внешних DLZ-драйверов, не требующих прямой линковки на этапе сборки. Для использования внешних DLZ-драйверов в блоке update-policy добавлена поддержка нового типа соответствия "external"; В коде GSS-TSIG исправлено большое число ошибок, добавлено несколько новшеств и улучшена совместимость с динамическими обновлениями от Microsoft DHCP; В утилите dig появилась новая опция "+onesoa", позволяющая запретить ввод дополнительных SOA-записей в AXFR-ответе; В named.conf добавлена опция 'resolver-query-timeout', дающая возможность определить таймаут в секундах для рекурсивных запросов; Вместо "RTT banding" осуществлен уход к старому методу выбора сервера для выполнения рекурсивного запроса, при котором выбирается авторитативный сервер с минимальным RTT. В прошлых версиях с целью усиления защиты от атак по отравлению DNS-кэша применялся метод случайного выбора авторитативного сервера, который приносил больше вреда чем пользы из-за снижения эффективности формирования запроса (resolver обращался не всегда к самому быстрому авторитивному серверу, что приводило к возникновению задержек и сводило на нет топологические оптимизации).
Распечатано с HostDB.ru.
|