Le CNAME d’abord, ou l’enregistrement A d’abord ?
(blog.cloudflare.com)- Le 8 janvier 2026, une mise à jour du service 1.1.1.1 de Cloudflare a modifié l’ordre des enregistrements dans les réponses DNS, provoquant des échecs de résolution DNS chez certains utilisateurs dans le monde
- La cause du problème était une modification du code qui a déplacé les enregistrements CNAME derrière les enregistrements A/AAAA, alors que certaines implémentations de clients DNS dépendaient de cet ordre
- En particulier, la fonction
getaddrinfode glibc et le processus DNSC des commutateurs Cisco ont été touchés, avec dans le second cas une boucle de redémarrage - La RFC 1034 indique seulement qu’un CNAME peut « possibly preface » la réponse, ce qui signifie qu’il n’existe pas de norme claire sur l’ordre des enregistrements
- Cloudflare est revenu à un placement systématique des CNAME en premier et a soumis à l’IETF un Internet-Draft pour définir une norme plus explicite
1. Vue d’ensemble de l’incident
- Le 8 janvier 2026, le déploiement d’une mise à jour visant à réduire l’usage mémoire de 1.1.1.1 a entraîné une modification de l’ordre des enregistrements dans les réponses DNS
- Le changement a été introduit dans la base de code le 2 décembre 2025, déployé en environnement de test le 10 décembre, puis lancé mondialement le 7 janvier 2026
- L’incident a été déclaré le 8 janvier à 18:19 UTC, le rollback a commencé à 18:27 et la restauration s’est achevée à 19:55
- La plupart des clients DNS modernes ignorent l’ordre des enregistrements dans la réponse, mais certaines implémentations supposent que le CNAME doit toujours apparaître en premier
- Quand cet ordre a changé, certains clients ont traité la réponse comme vide, entraînant un échec de résolution
2. Chaîne de CNAME et fonctionnement du cache
- Lors d’une requête sur un domaine, par exemple
www.example.com, la résolution vers l’IP finale peut passer par plusieurs chaînes de CNAME- Exemple :
www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
- Exemple :
- Chaque maillon CNAME possède un TTL (Time-To-Live), et seule une partie de la chaîne peut expirer
- 1.1.1.1 ne relance la requête que pour la partie expirée, puis fusionne le cache existant et les nouveaux enregistrements pour construire la réponse
3. Détails de la modification du code
- Dans l’ancien code, la chaîne de CNAME était insérée en premier, puis les enregistrements A/AAAA étaient ajoutés
answer_rrs.extend_from_slice(&self.records); // CNAMEs first
- Dans le code modifié, les CNAME étaient ajoutés en dernier
entry.answer.extend(self.records); // CNAMEs last
- En conséquence, les CNAME sont descendus en bas de la réponse, ce que certains clients n’ont pas su gérer
4. Exemples d’implémentations affectées
- La fonction
getaddrinfode glibc analyse la réponse séquentiellement et doit voir le CNAME apparaître d’abord pour pouvoir suivre le nom suivant- Si le CNAME arrive après, le « nom attendu » n’est pas mis à jour et le résultat reste vide
- Le processus DNSC de trois modèles de commutateurs Cisco Catalyst a aussi été affecté et, lorsqu’ils utilisaient 1.1.1.1, cela a provoqué une boucle de redémarrage due à une erreur fatale
- Cisco a publié une documentation de service à ce sujet
5. Implémentations non affectées
- systemd-resolved analyse la réponse à l’aide d’une structure
OrderedSet, ce qui lui permet de parcourir l’ensemble des enregistrements indépendamment de la position du CNAME- Il a donc continué à fonctionner normalement malgré ce changement d’ordre
6. L’ambiguïté de la RFC 1034
- La RFC 1034 (1987) indique qu’une réponse peut être prefaced par un ou plusieurs CNAME
- Cependant, comme elle n’emploie pas de mots-clés normatifs comme MUST/SHOULD, cela ne constitue pas une exigence explicite
- Ce n’est qu’après la RFC 2119 (1997) que ces mots-clés ont été standardisés, si bien que le document de l’époque ne formulait pas d’obligation claire
- Cloudflare plaçait les CNAME en premier dans son implémentation initiale, mais sans le garantir par des tests
7. Distinction entre RRset et sections du message
- La RFC 1034 §3.6 précise que l’ordre au sein d’un RRset (ensemble d’enregistrements de même nom, type et classe) n’a pas d’importance
- En revanche, elle ne dit rien sur l’ordre entre différents RRset
- L’exemple du §6.2.1 ne traite que de deux enregistrements A de même nom et n’aborde pas l’ordre relatif entre CNAME et A
- Il existe donc un vide dans la définition de l’ordre entre enregistrements CNAME et A
8. Le problème d’ordre à l’intérieur d’une chaîne de CNAME
- Lorsqu’un CNAME comporte plusieurs étapes, un simple mélange de l’ordre interne à la chaîne peut aussi faire échouer une analyse séquentielle
- Exemple : si
cdn.example.com CNAME server.cdn-provider.comapparaît en premier, on ne peut plus retrouverwww.example.com CNAME cdn.example.com
- Exemple : si
- La RFC 1034 ne définit pas non plus d’exigence sur l’ordre des chaînes de CNAME
9. Critère de fonctionnement des résolveurs
- La RFC 1034 §5.2.2 précise que lorsqu’un résolveur rencontre un CNAME, il doit relancer la requête avec le nouveau nom
- Mais cette explication vise le résolveur complet (par exemple 1.1.1.1), alors que les stub resolvers comme celui de glibc n’implémentent pas cette logique
- En pratique, certains stub resolvers ne suivent donc pas le comportement attendu par la RFC
10. Comparaison avec la règle explicite de DNSSEC
- La RFC 4035 (DNSSEC) indique avec MUST la priorité d’inclusion des enregistrements RRSIG
- Toutefois, cette règle concerne leur présence, et non leur ordre
- DNSSEC fournit donc des règles d’inclusion claires, alors que pour les zones non signées (Unsigned zones), l’ambiguïté de la RFC 1034 demeure
11. Conclusion et mesures prises par Cloudflare
- Même si, selon la RFC, l’ordre des CNAME n’est pas obligatoire, certains clients partent de cette hypothèse
Cloudflare est donc revenu à une politique plaçant toujours les CNAME en premier - Pour éviter qu’un problème similaire ne se reproduise, l’entreprise a soumis un Internet-Draft à l’IETF
- Document : draft-jabley-dnsop-ordered-answer-section
- Objectif : standardiser plus clairement l’ordre de traitement des CNAME dans les réponses DNS
- À travers cet incident, Cloudflare a confirmé que les ambiguïtés d’un protocole vieux de 40 ans peuvent encore avoir un impact concret en production
12. Informations complémentaires
- Via sa Connectivity Cloud, qui inclut 1.1.1.1, Cloudflare fournit des services de
protection des réseaux d’entreprise, accélération d’applications à l’échelle d’Internet, défense DDoS et prise en charge des déploiements Zero Trust - L’application gratuite 1.1.1.1 permet un accès à Internet plus rapide et plus sûr
1 commentaires
Avis sur Hacker News
J’ai l’impression que la formulation de la RFC n’est pas si ambiguë
L’expression « possibly preface » se lit comme « s’il y a un enregistrement CNAME, on le met d’abord », et non comme « on peut le mettre n’importe où si on veut »
Mais l’essentiel n’est pas une simple question d’interprétation de phrase : c’est qu’une équipe qui exploite l’un des serveurs DNS les plus importants du monde a changé la logique de réponse CNAME
Cela a forcément dû casser de façon évidente dans les tests, et il est surprenant que personne n’ait demandé : « est-ce que cet ordre est important ? »
Cloudflare communique ces derniers temps de manière transparente sur ses problèmes, mais ici cela sonne plutôt comme un « fait amusant à partager »
Le fait qu’un truc pareil ait passé les tests dans un système de cette taille ressemble à une grosse erreur
Comme l’exemple peut être généralisé, cela peut laisser croire à tort que « l’ordre n’a pas d’importance dans tous les cas »
Au final, ce qui paraît être une « compréhension claire » pour l’un peut donner à un autre l’impression de se demander « est-ce qu’il a vraiment lu toute la doc ? »
Ce genre de cas montre l’importance du langage normatif
On peut voir la discussion associée sur la liste de diffusion IETF
La phrase disant que « les différences d’ordre n’ont pas d’importance » ne vaut que pour cet exemple précis, et ne signifie pas qu’il faut ignorer la règle générale
On dit que la RFC 1034 a défini les RRset, mais en réalité il n’y a pas de définition explicite de ce terme
L’interprétation de Cloudflare ressemble à une exception prise à tort pour la règle générale
Cela dit, il n’existe pas non plus de règle claire sur l’ordre d’une chaîne de CNAME, donc il reste un peu d’ambiguïté sur ce point
On dirait un cas où la loi de Hyrum et la loi de Postel ont agi en même temps
D’un côté, « si une API a assez d’utilisateurs, quelqu’un finira par dépendre de chaque comportement observable du système »
De l’autre, le principe « soyez conservateur dans ce que vous envoyez, libéral dans ce que vous acceptez » entre en collision avec cela
Ici, le point important, c’est que le resolver de glibc a cassé — on est loin d’un cas rare
La vraie info, c’est surtout que Cloudflare n’a pas correctement testé son changement
Ce bug m’a rappelé un vieux souvenir
En 2011, quand Cloudflare avait ignoré la RFC pour autoriser les CNAME à l’apex d’un domaine
Dans le billet de blog de l’époque, ils disaient en substance qu’ils allaient « ignorer la RFC et résoudre le problème concret »
Mais un CNAME est un concept d’alias au niveau du nom, et en le mettant à l’apex on casse le cache des NS, MX et SOA
Beaucoup d’ingénieurs avaient averti à l’époque, mais c’était l’esprit « move fast and break things »
Cela dit, le fait qu’ils traitent maintenant aussi finement l’ordre entre chaîne de CNAME et enregistrement A montre qu’il y a eu des progrès
La notion de CNAME et d’alias sème la confusion depuis longtemps, et le langage non normatif de la RFC 1034 n’a fait qu’aggraver le problème
Ce flou s’est accumulé au fil du temps, mais il reste difficilement acceptable qu’un gros fournisseur de services fasse encore ce genre d’erreur
J’aurais plutôt tendance à penser que c’est la spécification elle-même qui posait problème
Il est surprenant que la résolution DNS générique de glibc dépende de l’ordre des enregistrements
C’est étonnant qu’il n’y ait pas eu de gros problème pendant plus de 20 ans
La plupart des opérateurs DNS avaient probablement appris empiriquement pendant leurs tests que l’ordre comptait
Si cela a attiré l’attention ici, c’est parce que Cloudflare a touché des centaines de millions d’appareils dans le monde
Je me demande quand même si Cloudflare a envoyé un correctif à des resolvers open source comme glibc
Les CNAME sont vraiment très pénibles à manipuler (voir les notes de DJB)
Un resolver simple comme celui de glibc n’a pas de cache, donc l’implémenter demanderait un changement de code important
Le fait que Cloudflare affirme que « la RFC n’exige pas d’ordre pour les CNAME » ressemble à de la chicane sur les mots
Ce n’est pas parce qu’il n’y a pas de « MUST » qu’on peut en déduire « n’importe quel ordre convient »
Reconnaître son erreur et passer à autre chose rend le monde meilleur
Se défausser de sa responsabilité par un débat sémantique fait au contraire perdre en crédibilité
Cloudflare semble ne pas avoir bien compris la RFC 1034
Leur interface DNS bloque A et AAAA lorsqu’il y a un CNAME, mais autorise d’autres enregistrements
Du coup, lorsque CNAME et TXT coexistent, cela produit des résultats dépendants du cache
internet.nl a également mis en évidence ce problème
Certains utilisateurs ont configuré cela en suivant le guide de mxtoolbox, ce qui entre en conflit avec la RFC 1034
L’une sur « comment déléguer un service DMARC via un CNAME », l’autre sur « comment l’héberger directement »
La capture d’écran semble avoir ajouté à la confusion
Le fait que Cloudflare soit finalement arrivé à la conclusion que le CNAME doit apparaître avant les autres enregistrements paraît raisonnable
En administrant le DNS en entreprise, j’ai souvent ressenti les limites du DNS
En particulier, lorsqu’un SERVFAIL survient, le client ne peut pas distinguer quel serveur pose problème
Résultat : plusieurs serveurs DNS et couches de cache provoquent des rafales de nouvelles tentatives inutiles
Et le search path répète des requêtes NXDOMAIN vers de mauvais domaines
servfail-ttlpour atténuer celaD’après la section 7.1 de la RFC2308, il est permis de mettre en cache les réponses SERVFAIL
C’est une norme ancienne, mais l’approche reste valable
Cloudflare casse souvent les standards, puis rédige de nouvelles RFC pour le justifier
Des cas comme la RFC 8482 sont à mes yeux une honte pour l’industrie
La phrase disant que « cette fois encore, ils ont soumis un nouvel Internet-Draft pour éviter la confusion » sonne de manière ironique
Pour un serveur DNS à l’échelle de 1.1.1.1, il devrait y avoir des tests d’intégration incluant de vrais resolvers comme celui de glibc
Alors pourquoi ce problème n’a-t-il été découvert qu’en production ?
Les tests unitaires ont peut-être réussi, mais le cas où ces deux conditions se chevauchent a sans doute été manqué