Sommaire (4 sections)
Les pannes franches sont un luxe : tout est cassé, tout le monde le voit, on cherche, on trouve. Celle-ci était d'une autre espèce. Notre chaîne d'intégration continue échouait par intermittence (un build sur trois, environ) sur la résolution de nos propres domaines. Même commande, mêmes serveurs : tantôt ça passe, tantôt no such host. Et pour brouiller les pistes, un second message apparaissait parfois : connect: network is unreachable sur une adresse IPv6. Autopsie d'une des pannes les plus instructives de l'année, parce que tout, dans son diagnostic, est réutilisable.
Le faux coupable : toujours dater les indices #
Le message IPv6 désignait un suspect évident : un enregistrement AAAA pointant vers une adresse que nos machines de build, en IPv4 seul, ne pouvaient pas joindre. Affaire classée ? C'est là qu'intervient le réflexe qui a sauvé le diagnostic : dater l'indice. Cet AAAA existait depuis deux mois et demi, et la CI avait tourné sans accroc pendant toute cette période. Un élément présent longtemps avant les symptômes ne peut pas en être la cause ; il ne faisait que diversifier les messages d'erreur (échec de la résolution A → « no such host » ; seule la AAAA qui répond → tentative IPv6 → « unreachable »). Première leçon, générale : face à un symptôme intermittent, établir la chronologie (date du dernier succès, date de chaque changement) avant toute hypothèse.
La méthode qui a tranché #
- Compter les échecs par domaine dans les journaux du résolveur interne : les SERVFAIL ne touchaient que deux de nos zones (des centaines d'occurrences) et zéro domaine externe sur dix testés. La panne avait donc un périmètre, et un périmètre est déjà une signature.
- Comparer les résolveurs publics : la même requête réussissait 12 fois sur 12 sur l'un… et 3 fois sur 12 sur un autre, connu pour valider strictement DNSSEC. Un domaine qui échoue seulement chez les résolveurs validants, c'est une flèche au néon vers la chaîne de confiance.
- Vérifier le DS :
dig DS <zone>chez le parent. Bingo : un enregistrement DS publié pour des zones qui, elles, servaient des réponses non signées.
Le mécanisme : la promesse non tenue #
DNSSEC fonctionne par chaîne de confiance : la zone parente (.com) publie un enregistrement DS (l'empreinte de la clé de votre zone) qui promet aux résolveurs : « les réponses de cette zone sont signées, et voici comment vérifier ». Un résolveur validant qui trouve ce DS exige alors des réponses signées. S'il reçoit du non-signé (notre cas, pendant une fenêtre de migration de serveurs DNS où l'ancien et le nouveau jeu cohabitaient dans les caches), il ne rend pas la réponse « quand même » : il répond SERVFAIL, par conception. C'est un refus de sécurité, pas un bug. D'où l'intermittence parfaite : nos résolveurs internes interrogeaient en alternance un résolveur laxiste et un validant strict : environ une résolution sur sept échouait, juste assez pour faire tomber un build de temps en temps sans jamais rien casser franchement.
Règle d'or DNSSEC : activer = signer la zone, vérifier, puis publier le DS. Désactiver = retirer le DS, attendre son TTL, puis seulement dé-signer. Jamais dans l'autre ordre, et jamais un DS qui survit à un changement de serveurs autoritatifs.
La résolution, et la vérification qui compte #
Le correctif tenait en une action : retirer les DS publiés chez le registrar pour les zones concernées, puis vérifier, sur chaque zone du portefeuille, que dig DS ne renvoie plus rien et que le résolveur validant répond 12/12. Dernier piège au passage : l'interface ou l'API de votre registrar peut afficher un état DNSSEC (« désactivé ») qui ne prouve rien sur ce que le parent publie réellement. Seule une requête DS au DNS fait foi. Les échecs de CI ont cessé le jour même.
Cette panne coche toutes les cases de notre définition de la fiabilité : invisible des tableaux de bord, intermittente, et résolue par la méthode plutôt que par la chance. C'est le niveau de détail auquel une infrastructure infogérée sérieusement doit être tenue, DNS compris, ce parent pauvre qu'on ne regarde que quand tout brûle. Un mystère de résolution chez vous ? On aime ce genre d'énigmes.
