Résumé

  • Pendant la réécriture BIND 10, Mark Andrews et Evan Hunt sont restés co-responsables de BIND 9 : l'annonce d'un successeur n'effaçait pas les devoirs liés au serveur déjà déployé.
  • Les refontes ultérieures de BIND 9 montrent que continuité ne signifiait pas immobilité. Intention, assistance, parité fonctionnelle, aptitude à une charge précise et migration effective restaient des faits distincts.

En février 2013, Internet Systems Consortium annonçait BIND 10 1.0.0. Le communiqué de version le disait pleinement pris en charge tout en précisant qu'il n'était pas fonctionnellement complet. Sa partie DHCP recevait une qualification encore différente : instantané d'ingénierie à vocation expérimentale. Ces états ne se contredisent que si l'on exige du mot « prêt » une réponse unique.

Un logiciel peut disposer d'une assistance et satisfaire les essais d'un rôle limité sans posséder les fonctions indispensables à un autre opérateur. Il peut être installable sans remplacer à l'identique son prédécesseur. Une version atteste une livraison, non le déplacement d'un parc réel.

Mark Andrews formulait cette limite dans un échange de la liste bind-users : BIND 10 restait loin de pouvoir remplacer BIND 9 et plusieurs fonctions manquaient. Mais la même discussion apportait une nuance décisive. Pour un service faisant uniquement autorité, sans signature DNSSEC gérée par BIND, la nouvelle solution pouvait déjà convenir à la production. Il ne s'agissait donc pas de décider si BIND 10 « marchait », mais de dire pour quelle charge il était défendable.

L'histoire de BIND publiée par ISC situe Andrews dans une séparation institutionnelle plus vaste. Lancé en 2009, BIND 10 devait reconstruire BIND sur un nouveau cadre applicatif et remplacer BIND 9. Le projet associait plusieurs contributeurs et bailleurs, surtout issus des ccTLD. Tandis que l'essentiel de l'équipe DNS d'ISC travaillait au prochain système, Andrews et Evan Hunt demeuraient co-mainteneurs de BIND 9.

Ce maintien est la face discrète d'un programme de remplacement. Les exploitants en place avaient toujours besoin de correctifs de sécurité, de versions prévisibles, de régressions maîtrisées et d'un interlocuteur. Les distributeurs avaient encore besoin d'un amont fiable. La nouvelle architecture pouvait progresser sur une voie séparée parce que l'option de production ne disparaissait pas avant la fin de la traversée.

Il serait faux d'en faire le sauvetage d'un homme seul. ISC compte plus de 43 développeurs centraux ayant contribué de façon notable à BIND 9 et reconnaît que l'ancien historique des commits sous-estime les apports extérieurs. Son rapport BIND 2025 nomme une équipe étendue et de nombreux partenaires. Andrews importe ici non comme propriétaire souverain du logiciel, mais comme porteur, avec Hunt, d'une responsabilité vérifiable au moment où l'attention de l'organisation se divisait.

Le résultat n'a pas suivi l'intention initiale. En 2014, ISC a arrêté le développement de BIND 10 et réorienté son investissement vers BIND 9. Shane Kerr, dernier responsable du projet, avait présenté « The Decline and Fall of BIND 10 » à RIPE 68 ; les archives de la réunion en conservent les supports. ISC juge elle-même trop courte l'explication habituelle par le seul « deuxième système ». Financement, périmètre, architecture, demande fonctionnelle et adoption ont tous pesé.

Revenir à BIND 9 ne signifiait pas le figer. ISC décrit ensuite le découplage des Response Policy Zones, la simplification de fonctions centrales et le remplacement de son interface réseau maison par libuv. Avant refonte, query_find() affichait un score de complexité de McCabe de 453. Ce nombre ne sacralise pas le vieux code ; il montre qu'une continuité de service peut contenir des transformations internes profondes.

Le bilan ISC de 2024 rend visible l'appareil autour du dépôt : neuf développeurs, cinq personnes en assurance qualité et deux responsables ; 25 versions libres et 12 versions préliminaires prises en charge sur l'année. BIND 9.20 achevait sur plusieurs versions le passage aux boucles d'événements libuv, tandis que des groupes de threads spécialisés répondaient aux tâches longues susceptibles de bloquer les requêtes. Réécriture et refactorisation progressive ne sont pas deux vertus opposées : toutes deux doivent produire essais, observations et possibilité de retour.

Le rapport annuel 2021 d'ISC marque les vingt ans d'Andrews dans l'organisation et sa nomination comme Distinguished Engineer. Il décrit aussi des cycles Stable et Extended Support Version qui se chevauchent afin de permettre une migration graduelle. Ce chevauchement est un instrument de gouvernance : il laisse aux opérateurs le temps de comparer, d'étager et d'annuler, au lieu de transformer un calendrier de versions en ordre.

La page actuelle de l'équipe ISC présente toujours Andrews comme Distinguished Engineer. Un titre établit une responsabilité institutionnelle ; il ne révèle pas ce qui tourne sur un serveur de noms donné. Ce fait se trouve en aval, dans les paquets, configurations, processus, réponses et journaux de décision.

Un registre de remplacement sérieux doit donc répondre à six questions : quelle capacité est promise ? Quelles charges sont prises en charge maintenant ? Quelles fonctions manquent ? Qui entretient le système existant pendant l'intervalle ? Quelle preuve autorise chaque bascule ? Quel retour reste possible ensuite ? Sans cette séparation, la feuille de route usurpe la place du déploiement et l'annonce de version celle de la migration.