Résumé

  • GoDaddy situe le début de l'interruption au 12 décembre 2025 à 21 h 20 GMT et le rétablissement à 21 h 28 GMT, après détection et annulation de la commande exécutée par inadvertance [1].
  • L'entreprise indique que tous ses services DNS faisant autorité ont été touchés. Les utilisateurs ayant besoin d'une nouvelle résolution pouvaient échouer, alors qu'une réponse encore valide en cache pouvait masquer l'indisponibilité [1].
  • Le compte rendu public ne donne ni la commande, ni son circuit d'approbation, ni les préfixes ou nœuds concernés, ni le volume de requêtes en échec, ni les empreintes de configuration. Ces inconnues doivent rester explicites.
  • Les RFC de l'IETF expliquent la distribution Anycast, le DNS faisant autorité, les TTL et la surveillance multipoint. Elles ne permettent pas de déduire le mécanisme non publié de cet incident [2][3][4][5].
  • Un contrôle défendable lie la commande à des objets exacts, prouve aussi ce qu'elle exclut, commence par un canari réversible, mesure l'effet hors du plan de contrôle et vérifie le retour de la configuration comme du service.

Distinguer les faits de l'analyse

Cet article porte sur l'interruption du 12 décembre 2025. Il ne traite pas de la panne DNS distincte survenue chez GoDaddy en 2012. Les dates, les dossiers publics et les limites opérationnelles diffèrent ; attribuer le mécanisme de l'un à l'autre produirait une fausse causalité.

GoDaddy a publié son explication le 15 décembre. Le récit de l'opérateur établit plusieurs points : une commande a été exécutée par inadvertance, l'accès Anycast aux services de noms faisant autorité a été interrompu pendant huit minutes, tous les services DNS faisant autorité de GoDaddy ont été concernés, la commande a été détectée puis annulée, et les tables de routage se sont mises à jour après le rétablissement du réseau [1].

Le texte ne précise pas l'objet de la commande. Il ne dit pas si elle a agi directement sur une politique BGP, un système d'orchestration, un couplage entre santé du service et annonce de routes, un préfixe de couverture ou un autre composant. Il ne publie pas les préfixes, le nombre de nœuds, les systèmes autonomes, les zones géographiques, les domaines concernés ou le taux de requêtes en échec.

Ces absences ne prouvent ni l'inexistence d'un contrôle ni une faute individuelle. Elles bornent les conclusions. Les faits propres à l'incident doivent rester attribués à GoDaddy ; les normes servent à formuler les preuves attendues, pas à inventer une topologie.

DNS faisant autorité et Anycast : deux états à ne pas confondre

Le DNS faisant autorité fournit la réponse de référence pour les noms qui lui sont délégués. Lorsqu'un résolveur récursif ne possède pas de réponse utilisable en cache, il doit interroger un serveur faisant autorité. La RFC 1034 décrit le TTL comme la limite de conservation d'un enregistrement en cache [4]. C'est pourquoi deux utilisateurs peuvent observer des résultats différents pendant la même interruption.

Anycast distribue l'accès à une adresse de service. Selon la RFC 4786, la même adresse peut être annoncée depuis plusieurs nœuds distincts et le système de routage dirige la demande vers l'un d'eux [2]. La justesse de la zone DNS, la santé du serveur et la visibilité de la route sont donc des états liés, mais distincts.

Une zone peut être correcte alors que son adresse de service n'est plus joignable. Un nœud peut être prêt à répondre alors que son annonce a disparu. Une route peut rester visible alors que le service derrière elle ne répond plus. Une analyse fiable ne dit qu'une commande a modifié l'une de ces couches que si les traces d'exécution et les observations du réseau les relient.

GoDaddy parle d'une interruption de « l'accès Anycast » et indique qu'après le retour du réseau, les tables de routage ont été mises à jour [1]. Cela établit une perte de joignabilité. Cela ne suffit pas à affirmer que toutes les annonces BGP ont été retirées ou à identifier l'objet exact de la commande.

Une commande mondiale doit viser un objet exact

« Le réseau DNS » n'est pas un objet de changement assez précis. Une demande à fort impact doit se résoudre en adresses de service, préfixes, groupes de nœuds, politiques de routage et révisions de configuration. Le sélecteur lisible par un humain doit être développé en un ensemble de cibles vérifiable, puis figé et haché au moment de l'approbation.

La preuve de périmètre doit aussi être négative. Si une commande concerne un nœud de test, le paquet de preuve doit montrer que les nœuds de production et les préfixes mondiaux ne sont pas sélectionnés. Si l'action est régionale, les autres zones de captation doivent conserver leurs annonces et continuer à répondre correctement.

Le texte d'une commande ne suffit pas. Les alias, étiquettes, groupes dynamiques et configurations générées peuvent élargir la cible entre la revue et l'exécution. L'approbation doit porter sur l'expansion résolue, l'état actuel, le delta rendu et l'effet de routage attendu. Si l'inventaire change, l'autorisation doit expirer.

Une opération globale n'est pas toujours illégitime. Une crise peut exiger un retrait ou un rétablissement coordonné. Mais la portée mondiale doit déclencher un niveau supérieur : approbation indépendante, retour arrière précalculé, conditions d'arrêt, sondes externes et déploiement progressif depuis un nœud isolé.

La multiplicité des nœuds ne prouve pas leur indépendance

Anycast apporte une distribution géographique, mais un contrôle partagé peut devenir le véritable domaine de panne. Si un même sélecteur, générateur de politique, identifiant ou orchestrateur peut modifier tous les nœuds, le nombre de sites ne protège pas contre cette action commune.

La RFC 4786 traite du lien entre disponibilité du service et annonces de routage. Elle décrit aussi les risques des préfixes couvrant plusieurs services et la difficulté d'observer Anycast, puisque la disponibilité dépend du lieu de la sonde [2]. L'indépendance se démontre donc par une transition de panne, pas par un schéma d'architecture.

Un exercice doit retirer un nœud ou un groupe d'annonces et confirmer que les autres sites continuent de renvoyer les bonnes réponses. Il doit vérifier que l'automatisation de reprise n'étend pas une panne locale et qu'un service partageant un préfixe de couverture ne force pas la disparition d'autres services.

Cette preuve peut commencer hors production, en développant le même sélecteur et en rejetant toute cible excédentaire. Un canari en production peut ensuite appliquer un changement réversible à un seul groupe tandis que des requêtes synthétiques proviennent de plusieurs réseaux. L'extension n'est permise que si les zones non visées restent stables.

Le cache modifie la visibilité, pas l'obligation de service

GoDaddy explique que le cache a surtout limité l'impact aux utilisateurs ayant besoin d'une nouvelle recherche [1]. Cette précision est essentielle : une panne du serveur faisant autorité ne se présente pas nécessairement comme l'arrêt simultané de tous les sites.

Le cache n'est pourtant pas une garantie. Un nom nouveau peut être absent du cache, un enregistrement peut expirer pendant l'incident et les politiques des résolveurs diffèrent. La RFC 8767 décrit la possibilité, côté résolveur, de servir des données périmées dans certaines conditions [5]. Elle ne permet pas d'affirmer quels résolveurs l'ont fait ici.

Les métriques doivent donc séparer le succès des requêtes faisant autorité, la joignabilité des adresses de service, l'utilisation de réponses en cache et la disponibilité finale de l'application. Une copie en cache peut atténuer le symptôme sans démontrer la santé de la plateforme faisant autorité.

La reprise comporte également plusieurs horloges : restauration de la configuration, propagation de la route, nouvelle tentative du résolveur, puis récupération de l'application. À côté de 21 h 28 GMT, une clôture rigoureuse conserve la distribution des temps de retour observés depuis différents réseaux.

Le registre de contrôle doit rejoindre le réseau en fonctionnement

Les inventaires, dépôts de politiques et systèmes de déploiement sont des registres indispensables. Ils décrivent les objets autorisés, leurs propriétaires et l'état souhaité. Ils ne sont pas pour autant le réseau réel. Un sélecteur approuvé peut se développer incorrectement ; une API peut répondre avec succès alors que l'effet est erroné ; un journal de retour arrière ne prouve pas que les requêtes publiques réussissent.

Un identifiant de changement doit relier la demande, le hachage des cibles, le delta, l'approbateur, le résultat d'exécution, l'état des routes par nœud, les requêtes DNS externes et la restauration. Des horloges communes permettent d'ordonner la commande, la variation de route et l'échec de résolution.

La preuve d'exécution dit ce qui a été tenté. La preuve d'effet dit ce qui s'est produit. Si le client perd la réponse, une partie de l'opération peut déjà être appliquée. Il faut réconcilier l'identifiant d'idempotence et l'état réel avant toute nouvelle soumission.

Le retour arrière n'est pas seulement une seconde commande. Il doit confirmer l'ancien état, le retour des annonces, la correction des réponses faisant autorité, la stabilité des sondes et les écarts résiduels. Configuration et service doivent être restaurés ensemble.

Constituer un paquet de preuve exécutable

Avant l'opération, le paquet précise la conséquence pour le service, les adresses et nœuds, le caractère local ou mondial, les dépendances partagées, l'état courant, le delta, le réviseur, le canari, les seuils d'arrêt et le retour arrière testé. Toute variation des cibles impose une nouvelle revue.

Pendant l'opération, il conserve en ajout seul l'identité authentifiée, les octets exacts de la requête, la clé d'idempotence, les réponses par cible et la révision appliquée. Des observateurs externes enregistrent en parallèle routes, codes DNS, contenu, latence et changement de zone de captation. Le droit de modifier le réseau ne doit pas permettre d'altérer ces preuves.

Après l'opération, plusieurs régions interrogent directement les adresses faisant autorité. Des noms contrôlés non mis en cache ou à TTL court empêchent le cache de produire un faux signal vert. Un désaccord entre santé interne et joignabilité externe empêche la clôture.

Le test de non-récurrence couvre au minimum trois situations : retrait sûr d'un nœud avec continuité des autres, rejet avant exécution d'un sélecteur volontairement trop large, et réconciliation d'un résultat inconnu sans répétition aveugle. Les hachages, routes, réponses, alertes et preuves de restauration sont conservés ensemble.

Une communication publique plus précise reste compatible avec la sécurité

GoDaddy a donné la date, la durée, la classe de service, la catégorie d'action, le mécanisme d'impact, la restauration et les catégories d'amélioration [1]. C'est plus utile qu'un avis générique. Une mise à jour pourrait encore préciser si l'opération touchait un objet global partagé, si un canari et une limite existaient, comment la perte a été détectée, si le retour arrière était préapprouvé et si un exercice a démontré l'isolation.

Il n'est pas nécessaire de publier la syntaxe, les identifiants ou les préfixes sensibles. Il est en revanche important de distinguer une amélioration planifiée d'un contrôle effectivement testé. Les clients d'un DNS faisant autorité ne peuvent pas auditer directement le routage interne ; une preuve publique bornée leur permet d'évaluer le changement de risque.

Périmètre de responsabilité

GoDaddy contrôlait la plateforme faisant autorité décrite dans son communiqué et la commande qu'il dit avoir exécutée par inadvertance. Les résolveurs récursifs, réseaux d'accès, navigateurs et systèmes d'exploitation contrôlaient les caches et les nouvelles tentatives. Le routage mondial reliait ces domaines. Ces limites expliquent les différences d'impact sans effacer la propriété du contrôle initial.

La responsabilité de l'opérateur est de limiter une action aux objets prévus, de détecter une perte inattendue de joignabilité et de restaurer un état vérifié. Les résolveurs peuvent améliorer la résilience avec le cache ou le service de données périmées, mais ils ne remplacent pas indéfiniment une autorité joignable.

La conclusion porte sur la preuve : Anycast ne distribue réellement un service que si les contrôles préservent des nœuds indépendants et joignables. Le cache n'atténue les symptômes que tant qu'une réponse demeure utilisable. Une commande mondiale n'est digne de confiance que lorsque cible, delta, approbation, effet et retour arrière sont liés et éprouvés sur le réseau en fonctionnement.

Sources

  1. https://www.godaddy.com/resources/news/understanding-godaddys-12-12-dns-interruption
  2. https://www.rfc-editor.org/rfc/rfc4786.html
  3. https://www.rfc-editor.org/rfc/rfc9199.html
  4. https://www.rfc-editor.org/rfc/rfc1034.html
  5. https://www.rfc-editor.org/rfc/rfc8767.html