- Une panne d’une heure de l’un des services mondiaux les plus populaires du système de noms de domaine (DNS) a mis en évidence la nécessité d’une plus grande diversité de cette infrastructure essentielle de l’internet.
- Les fournisseurs d’accès à l’internet doivent configurer leurs réseaux de manière à interroger plusieurs services DNS ou à utiliser leurs propres résolveurs récursifs locaux lorsque cela est possible.
- Les internautes peuvent également améliorer la résilience de leur connectivité en configurant leurs appareils de manière à ce qu’ils interrogent plus d’un service DNS.
La semaine dernière (14 juillet 2025), le service de résolution de noms de domaine publics (DNS) de Cloudflare – 1.1.1.1 – a connu une panne importante qui a touché les utilisateurs du monde entier.
Selon le rapport de Cloudflare après l’incident, le problème provient d’une mauvaise configuration des anciens systèmes utilisés pour maintenir l’infrastructure qui annonce les adresses IP de Cloudflare sur Internet.
L’incident, bien que de relativement courte durée (62 minutes), a mis en évidence une faiblesse essentielle de l’écosystème de l’internet – en particulier les fournisseurs d’accès à l’internet (FAI), les opérateurs de résolveurs et les utilisateurs finaux – qui en est venu à dépendre de quelques grands services de résolveurs DNS centralisés.
Dans ce billet de blog, nous analysons ce que cette panne révèle sur la résilience de l’Internet, en particulier sur la diversité des résolutions DNS, et les meilleures pratiques que les FAI et les utilisateurs devraient envisager pour améliorer l’hygiène opérationnelle et la résilience du DNS.
Pourquoi cette question est-elle si importante ?
Le DNS est le carnet d’adresses de l’internet. Si la résolution DNS échoue, les sites web et les applications deviennent inaccessibles, même si le réseau sous-jacent fonctionne par ailleurs.
Le service Cloudflare 1.1.1.1 est l’un des résolveurs DNS ouverts les plus utilisés au monde. Au début de l’année 2025, le service 1.1.1.1 traitait environ 1,9 trillion de requêtes DNS par jour, desservant des utilisateurs dans environ 250 pays et territoires.
Conçu pour la vitesse et la confidentialité, il a gagné en popularité auprès des utilisateurs finaux et des FAI qui le configurent comme leur résolveur récursif par défaut. Selon W3Techs, la part de marché de Cloudflare pour la résolution DNS est estimée à environ 14,6 % de tous les sites web.
Lire : Les grands DNS prennent-ils le dessus ?
Le 14 juillet, un grand nombre de ces utilisateurs se sont soudainement retrouvés dans l’incapacité d’accéder à l’internet, non pas parce que leur connexion internet était défaillante, mais parce que les noms de domaine n’étaient plus résolus. Les effets ont été particulièrement visibles dans les pays où Cloudflare est souvent le fournisseur de DNS de référence (pour des raisons de performance ou de politique).
Implications pour les FAI et les opérateurs de résolveurs
Pour les fournisseurs de services Internet et les opérateurs de réseaux, cette panne constitue un avertissement clair : dépendre d’un seul résolveur DNS en amont, aussi fiable qu’il puisse paraître, introduit un point de défaillance unique.
De nombreux FAI régionaux ou de petite taille, en particulier dans les régions en développement, disposent de ressources limitées pour gérer et maintenir leurs propres résolveurs de mise en cache. L’externalisation vers un résolveur public tel que 1.1.1.1 ou 8.8.8.8 (Google DNS) est courante dans ces cas. Toutefois, ce modèle ne fonctionne de manière fiable que si le fournisseur choisi reste disponible. Lorsqu’il tombe en panne, il en va de même pour le service DNS pour tous les clients, ce qui a pour effet d’interrompre l’expérience Internet.
Cette situation souligne la nécessité d’une résilience dès la conception, dont l’un des principes fondamentaux est la diversité, une pratique recommandée par KINDNS. Au lieu de s’appuyer sur un seul fournisseur de DNS en amont, les opérateurs devraient configurer leurs systèmes pour interroger plusieurs résolveurs, tels que Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) ou OpenDNS (208.67.222.222). Avec de nombreux fournisseurs en rotation, la défaillance d’un service ne se traduit pas par une perte totale de la fonctionnalité DNS – les requêtes peuvent continuer à être résolues par d’autres voies.
Les FAI devraient, dans la mesure du possible, exécuter leurs propres résolveurs récursifs locaux, idéalement avec mise en cache et validation DNSSEC. Cette configuration améliore les performances, la sécurité et la confidentialité des utilisateurs et donne aux FAI un plus grand contrôle opérationnel. Ces résolveurs locaux peuvent toujours transmettre des requêtes à des fournisseurs externes, mais avec l’avantage supplémentaire de la mise en cache et d’une logique de repli qui permet d’assurer la continuité du service, même lorsqu’un fournisseur d’accès en amont s’éteint.
Leçons pour les utilisateurs finaux
Les utilisateurs finaux qui configurent manuellement 1.1.1.1 sur leurs appareils (généralement pour améliorer les performances ou la protection de la vie privée) peuvent également avoir ressenti la panne.
La plupart des utilisateurs ne savent pas comment évaluer la fiabilité du DNS ou ne réalisent pas les conséquences potentielles de l’installation en dur d’un seul fournisseur DNS sur leurs téléphones, routeurs ou ordinateurs portables. Par conséquent, lors de la configuration manuelle des DNS, il convient de configurer au moins deux fournisseurs de DNS. Il est également recommandé d’utiliser le résolveur de votre fournisseur d’accès à Internet s’il prend en charge les normes modernes et les pratiques en matière de confidentialité.
L’incident DNS de Cloudflare nous rappelle que même les systèmes bien conçus connaissent des défaillances. L’objectif d’un internet résilient n’est pas d’éliminer toutes les défaillances, mais d’en atténuer l’impact et de garantir un rétablissement rapide lorsqu’elles se produisent.
Les FAI, les utilisateurs finaux et les opérateurs de résolveurs ont tous un rôle à jouer. En favorisant la redondance, en adoptant les meilleures pratiques et en réduisant les dépendances structurelles, nous pouvons garantir un internet plus résilient et inclusif pour tous.
Photo de Nahil Naseer sur Unsplash