Кратко

  • Политика поддержки ISC делит мажорные ветки BIND 9 на четыре типа и ограничивает чётные стабильные ветки четырьмя годами, последний отрезок которых — только исправления уязвимостей.
  • Публичное предупреждение по политике раскрытия дефектов и уязвимостей запускается при оценке CVSS 7 и выше, а сама политика распространяется только на поддерживаемые продукты и только на самый свежий месячный релиз каждой стабильной ветки.
  • Независимые записи Debian показывают как продолжение исправлений после завершения поддержки ветки у поставщика, так и измеримое запаздывание между версией, в которой исправление существует, и версией, принятой в стабильный дистрибутив.

Первая граница: поддержка ветки

Политика поддержки программного обеспечения ISC делит мажорные версии BIND 9 на четыре типа — Development, Stable, Extended Support (ESV) и Supported Preview (-S) — и устанавливает, что чётные стабильные ветки поддерживаются в общей сложности четыре года: примерно двенадцать месяцев исправлений функций и ошибок, затем расширенная поддержка, а после неё только исправления уязвимостей (политика поддержки ISC). Там же эта схема прямо названа ориентиром, а не гарантией.

Хронология по тому же документу выглядит так: BIND 9.18 был впервые выпущен в январе 2022 года, объявлен ESV в январе 2023 года и запланирован к завершению поддержки в июне 2026 года; BIND 9.20 вышел в июле 2024 года; ветка BIND 9.16 завершила жизненный цикл в марте 2024 года, а её последний релиз вышел в апреле 2024 года. Следующая стабильная ветка, 9.22, отложена как минимум до IV квартала 2026 года по формулировке политики поддержки и минимум до конца 2026 года по формулировке блога от 12 мая 2026 года, где причина описана как следствие анализа кода большими языковыми моделями, нашедшего историческое количество потенциальных уязвимостей (блог ISC от 12 мая 2026 года).

Эта граница важнее, чем кажется при чтении одних только предупреждений об уязвимостях: сообщение о найденной ошибке не создаёт обязательства исправлять её в ветке, которая уже выведена из поддержки.

Вторая граница: порог серьёзности и тип раскрытия

Политика раскрытия дефектов и уязвимостей ISC срабатывает при оценке CVSS 7 и выше, то есть при уровнях HIGH или CRITICAL; такие случаи классифицируются как Type I, если уязвимость не используется в реальных атаках, и как Type II, если она уже наблюдается «в дикой природе» или вызывает известные проблемы (политика раскрытия ISC).

Для Type I поддержка клиентов и OEM-производители получают формальное уведомление и предварительный код за три — пять рабочих дней до публикации, а при затрагивании авторитетного обслуживания уведомляются и операторы корневых серверов; упаковщики операционных систем получают до двадцати четырёх часов предупреждения. Публичное раскрытие сопровождается исправленными версиями всего поддерживаемого затронутого кода. Для Type II ISC ставит целью выпустить исправляющий код в течение двадцати четырёх часов после уведомления, и предварительное уведомление упаковщиков не всегда предшествует публичному объявлению.

Из того же документа следуют два ограничения, которые часто теряются при пересказе: политика применяется только к поддерживаемым продуктам, рекомендованным для промышленной эксплуатации, и только к самому последнему месячному релизу каждой стабильной ветки обслуживания; она не распространяется на версии с завершённым жизненным циклом, версии с завершённым обслуживанием и на ветки в разработке, а также не покрывает сторонние зависимости, включённые в пакеты ISC. Платная услуга Early Vulnerability Notification, доступная по подписке, включённая в подписки на поддержку и продаваемая отдельно, допускает до четырёх поименованных лиц на подписчика, требует соглашения о неразглашении и уведомляет подписчиков максимум за пять дней и минимум за три рабочих дня до публичного объявления (описание услуги EVN).

Там же ISC сообщает, что большинство обнаруживаемых в BIND 9 уязвимостей — это способы вызвать срабатывание INSIST или ASSERT, приводящие к завершению работы сервера, что может быть эффективной атакой на отказ в обслуживании, и что в части случаев уязвимость публикует сам обнаруживший её исследователь, и тогда ISC не управляет раскрытием. Это существенная оговорка: график «за три — пять рабочих дней», на который ориентируются операторы, описывает только те случаи, где поставщик сохраняет контроль над моментом публикации.

Третья граница: только последний месячный релиз

С 12 мая 2026 года ISC сообщает, что в обозримом будущем исправления безопасности следует ожидать в каждом месячном релизе обслуживания BIND, что заменяет неформальную практику примерно одного релиза безопасности в квартал (блог ISC от 12 мая 2026 года). Там же сказано, что организация не будет вкладывать дополнительные усилия в определение того, какой именно минорный релиз внёс проблему, и что пользователям следует обновляться до последней версии обслуживания своей ветки. Кроме того, ISC допускает выпуск CVE для большего числа уязвимостей средней серьёзности в диапазоне CVSS от 5 до 7 и предупреждает, что не всегда будет переносить исправления для таких уязвимостей в предыдущие версии; порог EVN при этом остаётся на уровне CVSS 7 и выше.

Иллюстрацией нового ритма служат примечания к выпуску BIND 9.20.26, где перечислено несколько исправлений безопасности с идентификаторами CVE, включая CVE-2026-10723, касающуюся проверки имени подписанта в NSEC3, и CVE-2026-10822, касающуюся утверждения при некорректном DNSKEY (примечания к выпуску 9.20.26). Практический вывод из этой границы не в том, что исправления замедлились, а в том, что адрес исправления сместился: правильной целью становится последняя версия обслуживания ветки, а не та версия, где уязвимость была впервые устранена.

Матрица исправлений: что видно и что остаётся за кадром

Матрица уязвимостей BIND 9 сопоставляет каждую CVE с релизом, в котором она устранена, и показывает только поддерживаемые стабильные ветки; более старые ветки, как правило, не получают исправлений и могут даже не оцениваться на наличие уязвимости (матрица уязвимостей ISC). В полученном фрагменте матрица фиксирует, что BIND 9.18 завершил жизненный цикл, что 9.18.50 был последним релизом серии и что версии с завершённым жизненным циклом следует считать уязвимыми к новым CVE. Единственная не выведенная из эксплуатации колонка в этом фрагменте — 9.20, а последняя указанная там версия с исправлением — 9.20.29 от 16 сентября 2026 года.

Здесь документы расходятся, и расхождение лучше не сглаживать. Завершение BIND 9.18 описано тремя способами: релизом в июне 2026 года, запланированным на 17 июня 2026 года, в блоге от 10 июня 2026 года; отметкой о завершении жизненного цикла 1 июля 2026 года в матрице уязвимостей; и датой 30 июня 2026 года в независимом справочнике жизненных циклов endoflife.date. Аналогично отложенность ветки 9.22 сформулирована как «как минимум IV квартал 2026 года» на странице политики поддержки и как «как минимум конец 2026 года» в блоге от 12 мая 2026 года. Каждая из этих формулировок принадлежит своему источнику и сохраняется как таковая.

Независимая проверка доставки: Debian

Если документы ISC описывают обязательства самого поставщика, то записи Debian позволяют проверить, что происходит дальше. Блог ISC от 10 июня 2026 года сообщает, что обслуживание 9.18 завершилось июньским релизом, запланированным на 17 июня 2026 года, после примерно четырёх с половиной лет, призывает к переходу на 9.20, описанную как ветка качества ESV, и приводит датированные вехи перенаправления пакетных репозиториев bind-esv на 9.20, включая публичное обновление пакета 15 июля 2026 года и ещё один релиз обслуживания 22 июля 2026 года (объявление о завершении поддержки 9.18).

Следующий слой — независимые записи дистрибутива. Уведомление безопасности Debian DSA-6395-1, выпущенное Сальваторе Бонаккорсо 22 июля 2026 года, охватывает девять CVE пакета bind9 и описывает последствия, среди которых обход проверки DNSSEC, обход политики RPZ, отравление кэша и отказ в обслуживании; в стабильном выпуске исправление установлено на версию 1:9.20.26-1~deb13u1 (DSA-6395-1).

Трекер безопасности Debian фиксирует bind9 в trixie на версии 1:9.20.26-1deb13u1 и в trixie-security на 1:9.20.29-1deb13u1, в bookworm на 1:9.18.49-1deb12u1 и в bookworm-security на 1:9.18.49-1deb12u2, а для forky и sid — 1:9.20.29-1, показывая при этом раздел открытых проблем пакета (трекер безопасности Debian). Трекер пакетов приводит версии по выпускам: oldstable 1:9.18.49-1deb12u1, stable 1:9.20.23-1deb13u1, stable-security 1:9.20.29-1deb13u1, testing и unstable 1:9.20.29-1, experimental 1:9.21.26-1, сообщает о пятнадцати открытых проблемах безопасности в bookworm и регистрирует принятие 1:9.20.29-1deb13u1 в stable-security 17 сентября 2026 года и миграцию 1:9.20.29-1 в testing 19 сентября 2026 года (трекер пакетов Debian).

Два наблюдения здесь важнее остальных. Первое: ветка 9.18 продолжала получать исправления в bookworm — вплоть до 1:9.18.49-1deb12u2 — уже после того, как поставщик объявил её завершённой, то есть часть работы по поддержке перешла к дистрибутиву. Второе: матрица указывает 9.20.29 с датой 16 сентября 2026 года, тогда как трекер Debian регистрирует принятие 1:9.20.29-1deb13u1 в stable-security 17 сентября 2026 года. Разница в один день в этом конкретном случае невелика, но она измерима и показывает, что между версией, где исправление существует, и версией, доступной пользователю дистрибутива, есть отдельный, наблюдаемый этап доставки.

Независимый от ISC справочник жизненных циклов endoflife.date относит окончание поддержки безопасности BIND 9.20 к 8 июля 2028 года, завершение 9.18 — к 30 июня 2026 года и завершение 9.16 — к 31 марта 2024 года, а также отмечает, что уязвимости в ветках разработки устраняются как обычные ошибки, без отдельных предупреждений с CVE (endoflife.date).

Границы доказательств

Все документы ISC в этом материале — собственный рассказ организации о собственных обязательствах, и для центральных утверждений они остаются источником со стороны оператора. Записи Debian независимы от ISC в части упаковки и обработки CVE, но воспроизводят данные об уязвимостях, полученные от поставщика; endoflife.date — справочник, поддерживаемый сообществом. Ни одна из этих страниц не открывалась напрямую: утверждения опираются на выдержки, возвращённые поиском, и на сохранённые снимки источников, часть дат выведена из адресов страниц, а трекеры обновляются и со временем меняются.

Наконец, публичного измерения доли развёрнутых серверов BIND 9, обновлённых в пределах заданного окна после предупреждения, найти не удалось, поэтому никакая оценка распространения здесь не приводится.

Профиль организации и связанные записи справочника доступны в записи ISC-AGP1 Internet Systems Consortium Inc..