- 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
getaddrinfo de 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
- 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
getaddrinfo de 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.com apparaît en premier, on ne peut plus retrouver www.example.com CNAME cdn.example.com
- 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
- À 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
Aucun commentaire pour le moment.