Кратко

  • Во время переписывания BIND 10 Mark Andrews и Evan Hunt продолжали совместно сопровождать BIND 9; объявление преемника не отменило ответственность за установленный сервер.
  • Позднейшая глубокая переработка BIND 9 показывает, что непрерывность не означала неподвижность. Намерение, поддержка, функциональный паритет, готовность к конкретной нагрузке и завершённая миграция оставались разными состояниями.

В феврале 2013 года Internet Systems Consortium объявил BIND 10 1.0.0. В сообщении о выпуске версия называлась полностью поддерживаемой, но ещё не полной по функциям. Компонент DHCP получил более узкое определение: экспериментальный инженерный снимок. Противоречие возникает лишь тогда, когда «готовность» считают одним переключателем.

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

Andrews провёл эту границу в обсуждении bind-users. BIND 10 был ещё далёк от замены BIND 9 и не обладал многими его функциями. Но там же звучало существенное уточнение: для исключительно авторитативного сервиса без управляемого BIND подписания DNSSEC новая система уже могла быть пригодна для эксплуатации. Это была оценка конкретной нагрузки, а не общий приговор.

История BIND от ISC описывает институциональное разделение труда. BIND 10 начался в 2009 году как полное переписывание на новой прикладной основе, призванное заменить и улучшить BIND 9, при участии и финансировании главным образом сообщества ccTLD. Пока большая часть DNS-команды ISC строила следующую систему, Andrews и Evan Hunt оставались совместными сопровождающими BIND 9.

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

Это не история одинокого спасителя. ISC насчитывает более 43 основных разработчиков со значительным вкладом в BIND 9 и предупреждает, что старые журналы коммитов недооценивают внешнюю работу. Отчёт BIND за 2025 год называет широкую команду и сторонних партнёров. Значение Andrews не в верховной власти над BIND, а в проверяемой ответственности, которую он делил с Hunt в период раздвоенного внимания организации.

Итог разошёлся с первоначальным намерением. В 2014 году ISC прекратил разработку BIND 10 и вернул инвестиции в BIND 9. Последний руководитель проекта Shane Kerr выступил на RIPE 68 с докладом «The Decline and Fall of BIND 10»; архив встречи хранит материалы и видео. Сам ISC считает объяснение одним «синдромом второй системы» слишком простым. На исход влияли финансирование, масштаб, архитектура, спрос на функции и принятие операторами.

Возврат к BIND 9 не означал заморозку его внутреннего устройства. ISC описывает отделение Response Policy Zones, упрощение центральных функций и замену собственной сетевой подсистемы на libuv. До переработки query_find() имела показатель сложности McCabe 453. Это не освящает старый код; это показывает, что непрерывность внешнего сервиса совместима с глубоким внутренним изменением.

Итоги ISC за 2024 год показывают систему вокруг кода: девять разработчиков, пять специалистов QA и два руководителя; 25 открытых выпусков и 12 поддерживаемых предварительных версий за год. BIND 9.20 завершил растянутый на несколько выпусков переход к циклам событий libuv, а для долгих задач, способных задерживать запросы, появились специализированные пулы потоков. Переписывание и постепенная переработка — не моральные противоположности: обоим нужны испытания, наблюдение и восстановление.

Годовой отчёт ISC за 2021 год отмечает двадцатилетие Andrews в организации и его назначение Distinguished Engineer. Там же описаны перекрывающиеся циклы Stable и Extended Support Version для плавного перехода. Перекрытие — механизм управления: оператор получает время на сравнение, поэтапное внедрение и возврат, а календарь выпусков не превращается в приказ.

Страница команды ISC по-прежнему указывает эту должность Andrews. Должность фиксирует институциональную ответственность, но не доказывает, что запущено на конкретном сервере имён. Производственный факт находится в пакетах, конфигурации, процессах, ответах и операционных записях.

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