Из улучшений 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 обращался не всегда к самому быстрому авторитивному серверу, что приводило к возникновению задержек и сводило на нет топологические оптимизации).