Resumo

  • Durante a reescrita do BIND 10, Mark Andrews e Evan Hunt continuaram como mantenedores conjuntos do BIND 9; a declaração de um sucessor não eliminou os deveres ligados ao servidor instalado.
  • A refatoração posterior do BIND 9 mostra que continuidade não era imobilidade. Intenção, suporte, equivalência funcional, prontidão para cada carga e migração concluída continuavam sendo estados diferentes.

Em fevereiro de 2013, o Internet Systems Consortium anunciou o BIND 10 1.0.0. O comunicado de lançamento dizia que a versão tinha suporte completo, mas ainda não estava completa em funcionalidades. O componente DHCP recebia uma qualificação mais restrita: uma fotografia de engenharia para uso experimental. As afirmações só parecem incompatíveis quando “pronto” é tratado como um único estado.

Um programa pode contar com suporte e servir a uma função delimitada sem oferecer tudo o que outro operador exige. Pode ser instalável sem substituir diretamente seu antecessor. O número da versão comprova uma entrega, não a transferência da base instalada.

Andrews delimitou isso numa conversa da lista bind-users. O BIND 10 ainda estava distante de substituir o BIND 9 e não oferecia várias de suas funções. Ao mesmo tempo, ele registrou uma exceção concreta: para serviço exclusivamente autoritativo, sem assinatura DNSSEC administrada pelo BIND, a nova opção podia estar pronta para produção. Era uma avaliação de carga de trabalho, não um veredito universal.

A história do BIND publicada pelo ISC situa a divisão institucional. Iniciado em 2009, o BIND 10 pretendia reconstruir o software sobre uma nova estrutura e substituir o BIND 9, com colaboração e financiamento sobretudo do segmento de ccTLDs. Enquanto a maior parte da equipe DNS do ISC trabalhava no próximo sistema, Andrews e Evan Hunt permaneceram como mantenedores conjuntos do BIND 9.

Essa permanência abrigava o lado discreto da substituição. Operadores existentes ainda precisavam de resposta a vulnerabilidades, lançamentos previsíveis, controle de regressões e atendimento. Distribuidores ainda dependiam de uma origem mantida. A arquitetura nova pôde acumular capacidade porque a alternativa em produção não desabou antes de a travessia terminar.

Não foi um resgate individual. O ISC contabiliza mais de 43 desenvolvedores centrais com contribuições importantes ao BIND 9 e reconhece que registros antigos subestimam colaboradores externos. O relatório BIND de 2025 nomeia uma equipe ampla e parceiros de fora. Andrews importa não como soberano do BIND, mas pela responsabilidade verificável que dividiu com Hunt quando a atenção institucional estava fragmentada.

O desfecho divergiu da intenção inicial. Em 2014, o ISC encerrou o desenvolvimento do BIND 10 e voltou a investir no BIND 9. Shane Kerr, último líder do projeto, apresentou “The Decline and Fall of BIND 10” no RIPE 68; o arquivo do encontro conserva apresentação e vídeo. O próprio ISC considera insuficiente a explicação fácil do “segundo sistema”. Financiamento, escopo, arquitetura, demanda funcional e adoção compuseram o resultado.

Retomar o BIND 9 também não significou congelá-lo. O ISC documenta a separação de Response Policy Zones, a simplificação de funções centrais e a troca da interface de rede própria por libuv. Antes da refatoração, query_find() tinha pontuação de complexidade McCabe 453. O número não santifica código antigo; mostra que continuidade externa pode conter mudança interna profunda.

O balanço do ISC de 2024 revela a organização ao redor do repositório: nove desenvolvedores, cinco profissionais de QA e dois gestores; 25 lançamentos abertos e 12 prévias com suporte naquele ano. O BIND 9.20 concluiu uma migração por várias versões para laços de eventos libuv e adotou grupos especializados de threads após tarefas longas bloquearem consultas. Reescrita e refatoração incremental não são opostos morais; ambas precisam de teste, observação e recuperação.

O relatório anual de 2021 do ISC registra os vinte anos de Andrews na organização e sua nomeação como Distinguished Engineer. Também descreve ciclos Stable e Extended Support Version sobrepostos para permitir migração gradual. Essa sobreposição é uma ferramenta de governança: dá tempo para comparar, implantar por etapas e recuar, em vez de transformar calendário em ordem.

A página da equipe do ISC continua identificando Andrews pelo cargo. Um título documenta responsabilidade institucional, não o software executado em um servidor específico. Esse fato está nos pacotes, configurações, processos, respostas e registros operacionais.

Um inventário de substituição confiável precisa responder: qual capacidade foi prometida; quais cargas têm suporte agora; o que ainda falta; quem mantém o incumbente no intervalo; qual evidência autoriza cada corte; e que retorno continua disponível. Sem essas distinções, roteiro vira implantação e anúncio de versão vira migração.