После более года разработки консорциум ISC представил (https://www.isc.org/blogs/bind-9-14-released/) первый стабильный релиз новой значительной ветки 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-серверами, на которых используется старое ПО с некорректно реализованной (https://www.opennet.dev/opennews/art.shtml?num=49999) обработкой запросов EDNS (расширенные флаги, которые кодируются в специальных RR-записях без нарушения обратной совместимости со старым протоколом). Изменение не повлияет работу серверов, не поддерживающих EDNS, но корректно отбрасывающих не поддерживаемые запросы EDNS.
Проблемы могут возникнуть только с сервеами, которые вопреки стандарту не отправляют DNS-ответ в старом формате, отбрасывая флаги EDNS, а молча игнорируют подобные запросы, никак не реагируя на них и не отправляя ответный пакет. При этом авторитативные DNS-серверы могут как и раньше не поддерживать EDNS и ограничиваться старым классическим протоколом, но теперь они обязаны корректно реагировать на подобные запросы. В настоящее время все актуальные DNS-серверы корректно отвечают на запросы с EDNS, а проблемные системы, как правило на основе старых выпусков PowerDNS, и блокирующие EDNS межсетевые экраны были уведомлены в рамках проведённой в феврале инициативы DNS flag day (https://www.opennet.dev/opennews/art.shtml?num=49999).
Ранее для обеспечения взаимодействия с серверами, не отвечавшими на запросы с флагами EDNS, в BIND применялся "грязный хак" - если после отправки запроса с флагами EDNS через определённый промежуток времени не поступал ответ, DNS-сервер считал, что расширенные флаги не поддерживаются и отправлял повторный запрос без флагов EDNS. Наличие подобного кода приводило к увеличению задержек из-за повторной отправки пакетов, повышению нагрузки на сеть и неоднозначности при отсутствии ответа из-за сетевых сбоев, а также мешало внедрению основанных на EDNS возможностей, таких как применение DNS Cookies для защиты от DDoS-атак.
Другие изменения (http://ftp.isc.org/isc/bind9/9.14.0/RELEASE-NOTES-bind-9.14....) в BIND 9.14.0:
- Прекращена возможность сборки без OpenSSL, даже если BIND собирается в режиме без DNSSEC. OpenSSL переведён в обязательные зависимости из-за использование предоставляемого данной библиотекой генератора псевдослучайных чисел (CSPRNG), работающего в неблокирующем режиме;- Для работы в UNIX-подобных ОС теперь требуется поддержка многопоточности (POSIX threads), расширенных параметров сокетов для IPv6 (RFC 3542) и Си-компилятора с поддержкой атомарных операций;
- Прекращено тестирование работы на устаревших ОС, включая старые версии 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 (https://www.isc.org/blogs/qname-minimization-and-privacy/), нацеленные на сокращение передачи дополнительной информации в запросах с целью предотвращения утечек конфиденциальных сведений и повышения приватности. В будущих выпусках планируется применить режим "strict";
- Добавлен режим зеркалирования зон, позволяющий named получать и работать с локальными копиями зон, но без функционирования в форме авторитетного сервера для данных зон. DNS-ответы для зеркалируемых зон не устанавливают бит AA ("authoritative answer"), но выставляют бит AD ("authenticated data"). Основным назначением указанной возможности является обработка локальных копий корневой зоны DNS;
- Существенно повышена производительность работы с большим числом зон, обработки большого числа запросов и работы с корневой зоной. Расширено применение glue-cache, ускорена работа сетевых обработчиков за счёт исключения миграции между ядрами CPU. В проведённых тестах по сравнению с BIND 9.12 производительность обработки тысячи зон возросла на 20%, миллиона зон на 15%, выполнение миллиона операций делегирования на 10%, обработки миллиона RR-запросов на 12%, рекурсивной обработки запросов на 18% и обработки корневой зоны на 10%;
- Добавлена поддержка сборки с библиотекой libidn2 для поддержки интернационализированных имён IDNA2008 (ранее поддерживалась только библиотека idnkit-1).
URL: https://www.isc.org/blogs/bind-9-14-released/
Новость: https://www.opennet.dev/opennews/art.shtml?num=50372
> В named.conf помимо неполиткорректных названий "master" и "slave" теперь в
> качестве типов зон можно указывать "primary" и "secondary";Теперь заживем!
Это ж киллер-фича!
Толи еще будет.
> Это ж киллер-фича!А в каком выпуске ожидается nigger-фича?
Молодцы, что совместимость не сломали. Надеюсь, SJW-шники не потребуют совсем убрать
Ещё политкорректнее заменить на что-нибудь типа "fag" и "punk" (знатоки английской фени могут поправить). Хотя, не следует забывать права лесбиянок и зоофилов. </sarcasm>
А интересно: когда неполиткорректное serve заменять станут?
> Прекращена возможность сборки без OpenSSL и сборки безподдержки новых-модных дыр. Прекрасно.
> Например, в плагин filter-aaaa.so заменил собой встроенную реализацию filter-aaaa
удобно, чо - больше корявых интерфейсов, больше багов, больше трэша
> помимо неполиткорректных названий "master" и "slave" теперь в качестве
> типов зон можно указывать "primary" и "secondary"великолепно
в общем, в помойку.
А какие есть альтернативы сабжу? Для крупных и мелких масштабов? (Слышал про knot-dns, который чехи из CZ.NIZ пилят + их роутер).
Я использую NSD. Быстр и удобен.
Есть еще nsd + unbound от голландских травокуров.
Knot, erldns, infoblox, NSD, PowerDNS.
> А какие есть альтернативы сабжу?windows2008R2 core. low footprint, ad'шная (то есть быстрая и надежная) репликация при совместимости с axfr (и, кажется, ixfr тоже, но я не пытался) если где-то застрял bind, встроенная синхронизация зон. Работает и у хомеюзеров, и в AD'шных лесах с тысячами доменов тоже.
Единственный недостаток - 64бита.knot dns внезапно возглавил колонну идущих найух участием в спонсированном клаудфлейрью и прочими уродами мероприятии "сломаем нахрен ресолвинг своим пользователям", плюс как все современные поделки требует отдельный рекурсор.
Пока ты не федеральный оператор - вполне можно в эту сторону вообще не смотреть.
> Единственный недостаток - 64бита.Ага, а ценник за лицензию + CAL для каждого клиента?
какой еще тебе ценник, в "стране бесплатного фотошопа"? На самом деле - ну сколько тебе тех серверов надо, 3, 5?CAL для dns отсутствует, только активация на сам сервер нужна. В целом и недорого, поскольку нужна на core и минимальная, но вот купить ее, если в 2010м не успел - это реально засада.
Как это сделать частному лицу а не лавке с собственным account manager - хз :-( Причем тому строго-настрого указано не давать тебе купить отличное от 2016 ни под каким видом.ну и без апдейтов она, конечно, останется еще не в этом году, но скоро. С другой стороны, у меня тоже апдейт не предусмотрен.
А я думал, что это шутка была! :)
> windows2008R2 core. low footprint,му-ха-ха, один раз!
> ad'шная (то есть быстрая и надежная) репликация
му-ха-ха, второй раз!!
> при совместимости с axfr (и, кажется, ixfr тоже, но я не пытался
только эти "последователи" RFC1035 разрешают рабочим станциям херачить кириллицу в A-записи...
что происходит потом c ixfr на другие невиндовые сервера - сами догадаетесь?а слать forward-запрос сразу по tcp (а не udp, а затем если вернулась ашипка повторять по tcp) научилось это неуёмное угробище? а превентивное обновление кэша научилось?
и косяков там ещё таких - адъ и израиль.
так что нах.
смех без причины - признак большого ума и, главное - владения темой.> что происходит потом c ixfr на другие невиндовые сервера - сами догадаетесь?
их проблемы (впрочем, и тех у кого откуда-то берутся рабочие станции, имеющие произвольные имена левыми алфавитами)
> а слать forward-запрос сразу по tcp
схерали?
> и косяков там ещё таких - адъ и израиль.
да, я вижу косяков вы скурили уже не один.
с учетом того, что 9.13 до сих пор продолжает падать на ровном месте, говорить об использовании 9.14 мне кажется слегка преждевременно
> с учетом того, что 9.13 до сих пор продолжает падать на ровном местея бы на твоем месте пересобрал его без openssl, xml и прочей стремной херни - это не ровное место ни разу, хорошо если это просто реакция на какой-то мусорный траффик или неудачный конфиг, а может быть тебя мала-мала и поломать пытаются.
Если падает на assert - разбирайся что за assert, обычно это явный признак совсем серьезной проблемы.
> говорить об использовании 9.14 мне кажется слегка преждевременно
бэкпорты секьюрити патчей (о большей части которых ты даже и не узнаешь, политика ISC) сам будешь делать? Молодец, коноплев, пять.
н-дя... вы какими версиями бинда пользуетесь то?
ведь судя по вашей реплики - никакими. иначе бы знали, что срок поддержки 9.11 заканчивается 2021, а 13 версия до сих пор относится к unstable.
> н-дя... вы какими версиями бинда пользуетесь то?я ж говорю - виндой я пользуюсь. Ну и 9.11 попадается, только я ж не просто так говорил про непубликуемые (у них нет cve ##) дыры - политика isc, с 2001го кажется.
"срок поддержки" у этих альтернативно-одаренных означает только если дырка выльется в паблик - они ее почти быстро почти исправят, не надейтесь ни на что другое. Так что ставьте что на лопате выкатили, иначе будет только хуже.Исключение - redhat, ibm и еще кто-то, входящие в группу особо доверенных, имеющих доступ к внутренним секьюрити-алертам. Но в шестерке, к примеру, вот такая красота:
9.8.2-0.68.rc1.el6_10.1
68, как мы все понимаем - это число итераций патчинга (даже не отдельных патчей). Все еще хочется разбираться, что они там патчат и работает ли под нагрузкой оно вообще?
Google со своими восьмерками теперь будет тормозом прогресса.
> Google со своими восьмерками теперь будет тормозом прогресса.чего это вдруг? Мы тоже поапгрейдимся.