Kea DHCP : migrer depuis ISC dhcpd en fin de vie

Le serveur DHCP qui distribue les adresses de tout un datacenter tourne encore sous ISC dhcpd. Stable, jamais touché depuis des années. Sauf qu'ISC a arrêté la maintenance de dhcpd en 2022. Plus de correctifs, plus de patch de sécurité, plus rien. Le jour où on met à jour l'OS de la machine et que dhcpd ne compile plus, ou pire le jour où une faille sort et reste sans patch, on découvre que la dette était là depuis le début. Un service DHCP qui tombe, c'est un parc entier qui perd ses baux.

ISC ne laisse pas de trou : Kea est le successeur officiel, écrit par les mêmes, conçu pour remplacer dhcpd. La question n'est pas de savoir s'il faut migrer, mais quand. Et la réponse est : tout nouveau déploiement en Kea, toute machine dhcpd existante planifiée pour la bascule.

ISC a annoncé la fin de vie de dhcpd en 2022 et a cessé sa maintenance. Le code continue de fonctionner, un binaire ne pourrit pas tout seul. Le problème n'est pas qu'il s'arrête, c'est qu'il se fige pendant que tout bouge autour. L'OS évolue, les bibliothèques changent, une CVE finit par sortir. Sans mainteneur amont, chaque incident devient ton problème, seul, sans patch officiel.

Côté ops, on ne laisse pas un service d'infrastructure critique sur un logiciel abandonné. Le DHCP conditionne l'accès réseau de tout ce qui démarre : serveurs, postes, équipements, machines provisionnées en PXE. Le garder sur une base non maintenue, c'est accepter une bombe à retardement par confort. La règle est simple : un composant en fin de vie sur le chemin critique se remplace avant qu'il ne casse, pas après.

Là où dhcpd était un binaire monolithique, Kea éclate les responsabilités en démons distincts, chacun avec son rôle.

kea-dhcp4 sert le DHCPv4, kea-dhcp6 le DHCPv6. Deux démons séparés, on lance celui dont on a besoin. kea-dhcp-ddns gère la mise à jour dynamique du DNS : quand un bail est attribué, il pousse l'enregistrement A et le PTR vers le serveur DNS. kea-ctrl-agent, le control agent, expose une API REST pour piloter et interroger les démons à chaud, sans redémarrage.

Cette séparation change la façon d'opérer. On reconfigure, on interroge les baux, on bascule un serveur en HA, le tout par API, à chaud. Le modèle colle à une infra qu'on pilote par scripts et automatisation plutôt qu'à coups de SIGHUP sur un fichier texte.

dhcpd avait son langage de config maison, ce format en accolades et points-virgules que tout admin réseau a un jour édité à tâtons. Kea passe au JSON. Plus verbeux à l'œil, mais structuré, validable, et surtout générable.

Un sous-réseau Kea déclare son subnet, ses pools de plage, ses option-data pour passerelle, DNS, domaine, et ses reservations pour les baux fixes par adresse MAC. En prod, ça donne ça : un objet JSON par sous-réseau, lisible, qu'on produit depuis Ansible ou un IPAM au lieu de l'écrire à la main. Le format texte de dhcpd se prêtait mal à la génération automatique ; le JSON de Kea s'y prête naturellement, et c'est là qu'on gagne.

Le piège classique : le timezone. Kea exige que le fuseau de la base de données corresponde à celui du système. Désaccord, et les durées de bail partent en vrille. À vérifier dès l'installation, avant de chercher midi à quatorze heures sur des baux qui expirent au mauvais moment.

C'est le choix structurant. Où Kea stocke les baux attribués.

memfile est le défaut : base en mémoire, persistée sur disque dans un fichier CSV. Simple, rapide, zéro dépendance externe. Aucune initialisation, le démon crée le fichier au premier lancement. Parfait pour un serveur unique. Limite nette : il ne stocke pas les réservations d'hôtes, qui restent dans la config. Et il ne partage rien : un autre serveur Kea ne verra pas ces baux.

MySQL et PostgreSQL changent la donne. Les baux vont en base SQL, et avec eux les réservations d'hôtes, les options par hôte, et même une partie de la configuration serveur. Ce que ça débloque : le partage d'état. Deux serveurs Kea pointant la même base voient les mêmes baux. C'est le socle d'une vraie haute disponibilité et la condition pour ne pas distribuer deux fois la même IP depuis deux serveurs.

En résumé : memfile pour un serveur isolé ou un lab, base SQL dès qu'on veut de la HA ou du partage d'état. Sur une infra de production multi-serveurs, c'est SQL, sans hésiter.

dhcpd avait son mécanisme de failover, réputé capricieux. Kea le remplace par le hook HA, et c'est un gain net selon ISC elle-même.

Deux topologies. Le mode hot-standby : un serveur primaire actif, un secondaire en attente qui prend le relais si le primaire tombe. Le plus simple à comprendre et à régler. Le mode load-balancing, actif-actif : les deux serveurs répondent en même temps, chacun sa part de la charge, et l'un couvre l'autre en cas de panne. Les deux reposent sur une base de baux partagée pour rester cohérents.

Détail qui compte : la HA passe par un hook, un module chargé dynamiquement. La logique modulaire de Kea met les fonctions optionnelles dans des hooks qu'on n'active que si on s'en sert. La HA en est un, comme d'autres fonctions avancées. On charge ce dont on a besoin, pas plus. Pour le reste de la pile résolution d'adresses, on couvre DHCP sous Linux et l'amorçage réseau dans netboot DHCP et PXE.

Le démon kea-dhcp-ddns ferme la boucle entre attribution d'adresse et résolution de nom. À chaque bail, Kea déclenche la création ou la mise à jour de l'enregistrement A (le nom vers l'IP) et du PTR (l'IP vers le nom) sur le serveur DNS, via mise à jour dynamique sécurisée.

L'intérêt opérationnel : une machine qui prend un bail devient joignable par son nom sans intervention manuelle, et le reverse suit. Indispensable sur un parc qui bouge. Le couplage marche avec un BIND configuré pour accepter les updates dynamiques, voir BIND9 en pratique, et la résolution récursive en aval relève d'Unbound.

ISC fournit l'assistant de migration, Keama (Kea Migration Assistant). C'est une branche de dhcpd qui lit la config historique et la traduit en JSON Kea. Le point de départ, pas le point d'arrivée.

La conversion automatique couvre l'essentiel : sous-réseaux, pools, options. Trois zones demandent une reprise manuelle selon ISC, et c'est honnête de le dire : le failover ou la HA, qui change complètement de modèle entre dhcpd et Kea ; la classification client ; les réservations d'hôtes. On ne lance pas Keama en espérant un résultat clé en main sur ces trois points. On convertit, on relit, on réécrit ce qui doit l'être.

La méthode qu'on applique. Convertir avec Keama et garder le résultat comme brouillon. Choisir le backend : SQL si HA, memfile sinon. Reconstruire proprement la HA dans le modèle Kea plutôt que de tordre l'ancien failover. Tester sur un sous-réseau pilote avant de basculer la production. Vérifier le DDNS si on l'utilisait. Garder dhcpd prêt à reprendre la main tant que Kea n'a pas tourné un cycle de baux complet en conditions réelles.

La consigne est tranchée. Tout nouveau déploiement DHCP en Kea, point. Toute machine dhcpd existante : migration planifiée, pas repoussée à l'incident. dhcpd ne recevra plus jamais de correctif, c'est une dette qui ne fait que grossir. Kea 3.0, première version LTS sortie en 2025, est supportée trois ans : la base saine sur laquelle bâtir.

Quand un service d'infrastructure repose sur un logiciel abandonné, on ne bricole pas, on remplace avant la casse, avec un sous-réseau pilote et un plan de retour arrière. C'est le genre de migration qu'on mène sur les infras qu'on opère ; si votre DHCP tourne encore sous dhcpd, on peut planifier et exécuter la bascule vers Kea.

• Kea DHCP, ISC : présentation officielle, statut LTS, positionnement face à dhcpd.
• Migrating to Kea from ISC DHCP, ISC : annonce de fin de vie de dhcpd et chemin de migration recommandé.
• Migrating from ISC DHCP to Kea using Keama, ISC KB : assistant de migration et zones à reprendre manuellement.
• Kea Database Administration, documentation officielle : backends memfile, MySQL et PostgreSQL, initialisation.
• Kea High Availability vs. ISC DHCP Failover, ISC KB : comparaison HA Kea (hot-standby, load-balancing) et failover dhcpd.
• The DHCPv4 Server, Kea ARM : configuration des sous-réseaux, pools, réservations et hooks.