Resumen

  • Durante la reescritura BIND 10, Mark Andrews y Evan Hunt siguieron como mantenedores conjuntos de BIND 9; declarar un sucesor no eliminó las responsabilidades del servidor instalado.
  • La refactorización posterior de BIND 9 demuestra que continuidad no significaba inmovilidad. Intención, soporte, paridad funcional, aptitud para una carga y migración consumada eran estados distintos.

En febrero de 2013, Internet Systems Consortium presentó BIND 10 1.0.0. El anuncio de la versión decía que contaba con soporte completo, aunque todavía no estaba completo en funciones. El componente DHCP recibía otra etiqueta: instantánea de ingeniería para uso experimental. Las tres afirmaciones pueden ser ciertas porque «listo» no es una propiedad única.

Un producto puede disponer de soporte y funcionar para un cometido limitado sin cubrir lo que exige otro operador. Puede instalarse sin ser un sustituto directo. El número de versión prueba que hubo una entrega; no prueba que la base desplegada se haya trasladado.

Andrews delimitó el problema en una conversación de bind-users. BIND 10 aún estaba lejos de reemplazar a BIND 9 y carecía de numerosas funciones. Pero añadió una precisión: para servicio exclusivamente autoritativo, sin firma DNSSEC gestionada por BIND, podía estar listo para producción. No era una sentencia general sobre si BIND 10 funcionaba, sino una evaluación vinculada a la carga.

La historia de BIND de ISC explica la división del trabajo. BIND 10 comenzó en 2009 como una reescritura desde cero sobre un marco nuevo, destinada a sustituir y mejorar BIND 9, con financiación y colaboración principalmente del entorno ccTLD. Mientras casi todo el equipo DNS de ISC se concentraba en el siguiente sistema, Andrews y Evan Hunt permanecieron como mantenedores conjuntos de BIND 9.

Esa continuidad contenía el trabajo menos visible del reemplazo. Los operadores actuales aún necesitaban respuesta de seguridad, versiones previsibles, control de regresiones y asistencia. Los distribuidores necesitaban un origen mantenido. La arquitectura futura pudo acumular capacidad porque la opción de producción no se desmoronó antes de que los usuarios pudieran abandonarla.

No fue el rescate de un solo hombre. ISC atribuye contribuciones importantes a más de 43 desarrolladores centrales de BIND 9 y advierte que el historial antiguo infravalora aportes externos. Su informe BIND de 2025 enumera un equipo amplio y colaboradores externos. La relevancia de Andrews no reside en poseer autoridad soberana sobre BIND, sino en la responsabilidad concreta que compartió con Hunt cuando la organización repartía su atención.

El resultado se apartó del propósito original. ISC terminó el desarrollo de BIND 10 en 2014 y volvió a invertir en BIND 9. Shane Kerr, último responsable del proyecto, presentó «The Decline and Fall of BIND 10» en RIPE 68; el archivo de la reunión conserva material y vídeo. ISC considera incompleta la explicación fácil del «segundo sistema». Financiación, alcance, arquitectura, demanda funcional y adopción formaron parte del desenlace.

Recuperar BIND 9 tampoco significó conservar intacto su interior. ISC documenta la separación de Response Policy Zones, la simplificación de funciones centrales y el reemplazo de la interfaz de red propia por libuv. Antes de refactorizar, query_find() tenía un índice de complejidad de McCabe de 453. El dato no convierte el código antiguo en intocable; muestra que un servicio continuo puede absorber cambios internos profundos.

El balance de ISC de 2024 enseña la organización que rodeaba al código: nueve desarrolladores, cinco profesionales de QA y dos responsables; 25 versiones abiertas y 12 versiones preliminares con soporte aquel año. BIND 9.20 culminó una transición de varios ciclos hacia bucles de eventos libuv y añadió grupos de hilos especializados tras observar tareas largas que bloqueaban consultas. Reescritura y refactorización incremental no son virtudes opuestas: ambas necesitan pruebas, observación y recuperación.

El informe anual de ISC de 2021 registra los veinte años de Andrews en ISC y su nombramiento como Distinguished Engineer. También describe ciclos Stable y Extended Support Version solapados para permitir una migración gradual. El solapamiento es gobierno práctico: permite comparar, desplegar por etapas y retroceder sin convertir una fecha de lanzamiento en una orden.

La página del equipo de ISC sigue presentando a Andrews con ese cargo. El título acredita responsabilidad institucional, no lo que ejecuta un servidor concreto. Ese hecho queda aguas abajo, en paquetes, configuración, procesos, respuestas y registros operativos.

Un libro mayor de reemplazo debe conservar seis respuestas: capacidad prometida, cargas soportadas hoy, funciones ausentes, responsable del incumbente durante la transición, evidencia que autoriza cada corte y mecanismo de retorno. Sin ellas, la hoja de ruta suplanta al despliegue y el anuncio de versión suplanta a la migración.