Publié le 7 février 2026 12h33. Une mise à jour de routine du service DNS de Cloudflare a provoqué une interruption de service de son DNS public 1.1.1.1, révélant une ambiguïté dans les normes DNS concernant l’ordre des enregistrements CNAME et A. L’entreprise a rapidement corrigé le problème et propose désormais une spécification clarifiée à l’IETF.
- Une modification de l’ordre des enregistrements CNAME a entraîné des échecs de résolution DNS pour certains utilisateurs.
- Le problème est lié à des implémentations DNS plus anciennes qui s’attendent à ce que les enregistrements CNAME précèdent les enregistrements A.
- Cloudflare a déployé une solution et propose une nouvelle norme pour éviter de futures interruptions.
Le 8 janvier, une mise à jour du service DNS de Cloudflare, initialement destinée à optimiser l’utilisation de la mémoire, a eu des conséquences inattendues. Cette modification a altéré l’ordre dans lequel les enregistrements CNAME (Canonical Name) étaient renvoyés dans les réponses DNS. Si la plupart des logiciels modernes ne tiennent pas compte de cet ordre, certaines implémentations plus anciennes s’attendent à ce que les enregistrements CNAME, qui servent d’alias à d’autres noms de domaine, apparaissent avant les enregistrements A, qui pointent directement vers une adresse IP.
Lorsque l’ordre a été modifié, certains résolveurs DNS ont commencé à échouer lors de la résolution des noms de domaine, entraînant une panne significative du service DNS public 1.1.1.1 de Cloudflare, très populaire. Sébastien Neuteboom, ingénieur système chez Cloudflare, a expliqué que le changement avait été introduit le 2 décembre 2025, testé le 10 décembre et déployé progressivement à partir du 7 janvier 2026.
« En apportant quelques améliorations pour réduire l’utilisation de la mémoire de notre implémentation de cache, nous avons introduit une modification subtile dans l’ordre des enregistrements CNAME. »
Sébastien Neuteboom, ingénieur système chez Cloudflare
Le fonctionnement du DNS implique que lorsqu’un résolveur recherche un nom avec un enregistrement CNAME, il peut rencontrer une chaîne d’alias qui le mène finalement à une adresse IP. Chaque étape de cette chaîne est mise en cache avec sa propre durée de validité. Si une partie de cette chaîne expire, le résolveur ne récupère que la partie expirée et la combine avec les parties encore valides pour reconstituer la réponse complète.
Avant la mise à jour, le code de Cloudflare créait une nouvelle liste pour les enregistrements CNAME, y insérait la chaîne existante, puis ajoutait les nouveaux enregistrements. Pour optimiser l’utilisation de la mémoire, le code a été modifié pour ajouter les enregistrements CNAME directement à la liste des réponses existantes. C’est cette modification qui a entraîné l’apparition des enregistrements CNAME en bas des réponses, après l’adresse IP finale.
« Auparavant, le code créait une nouvelle liste, insérait la chaîne CNAME existante, puis ajoutait les nouveaux enregistrements (…) Cependant, pour enregistrer certaines allocations de mémoire et copies, le code a été modifié pour ajouter les CNAME à la liste de réponses existante. En conséquence, les réponses renvoyées par 1.1.1.1 avaient désormais parfois les enregistrements CNAME apparaissant en bas, après la réponse finale résolue. »
Sébastien Neuteboom, ingénieur système chez Cloudflare
Si des logiciels comme systemd-resolved ne sont pas sensibles à l’ordre des enregistrements, d’autres, notamment la fonction getaddrinfo de la bibliothèque glibc, s’attendent à trouver les enregistrements CNAME en premier. Un utilisateur sur Reddit a commenté :
« D’une part, je respecte vraiment les détails de leurs autopsies et de leurs normes d’ingénierie très élevées, mais d’un autre côté, je ne peux m’empêcher de penser qu’ils n’ont pas mis en place de tests appropriés (et leur culture) pour comprendre l’impact qu’ils ont à l’échelle mondiale. »
Sur un fil de discussion sur Hacker News, de nombreux utilisateurs ont remis en question la clarté de la spécification RFC ou ont suggéré que les développeurs de Cloudflare l’avaient mal interprétée. Patrick May a souligné l’importance de la loi de Hyrum (« Avec un nombre suffisant d’utilisateurs d’une API, peu importe ce que vous promettez dans le contrat : tous les comportements observables de votre système dépendront de quelqu’un. ») combinée au non-respect de la loi de Postel (« Soyez conservateur dans ce que vous envoyez, soyez libéral dans ce que vous acceptez »).
Pour résoudre ce problème, Cloudflare a proposé un brouillon de RFC à l’IETF (Brouillon Internet) qui définit explicitement la manière correcte de gérer les enregistrements CNAME dans les réponses DNS. L’entreprise a commencé le déploiement de la correction le 7 janvier et a atteint 90 % de ses serveurs le 8 janvier à 17h40 UTC. L’incident a été signalé peu de temps après, la restauration du service ayant été achevée à 19h55 UTC.