Défaut de cache DNS Azure 2021: un test de responsabilité

Résumé

Entre 21 h 21 UTC et 22 h 00 UTC le 1er avril 2021, Azure DNS a connu un problème de disponibilité de service. Microsoft a indiqué que la majorité des services dépendants s’étaient rétablis vers 22 h 30 UTC. Son avis communautaire contemporain utilisait une fenêtre d’impact approximative de 21 h 30 à 22 h 30, tandis qu’une surveillance indépendante signalait une alarme vers 21 h 20. Il s’agit d’observations différentes, pas nécessairement d’horloges contradictoires. [1][2]
Microsoft a décrit une surtension anormale de requêtes DNS provenant du monde entier et ciblant un ensemble de domaines hébergés sur Azure. L’entreprise n’a pas identifié publiquement d’attaquant, d’intention, de botnet ou de campagne confirmée de déni de service distribué. La surtension initiale doit rester inexpliquée au-delà de la description de Microsoft. [2][4][5]
Microsoft a indiqué qu’une séquence d’événements particulière a exposé un défaut de code réduisant l’efficacité des caches DNS Edge d’Azure. Le dossier public ne divulgue ni le chemin de code, ni la clé de cache, ni le taux de succès, ni la population de serveurs périphériques touchés, ni le travail de backend généré par chaque échec de cache. [2][4][5]
À mesure que le service DNS surchargeait, les clients réitéraient leurs requêtes plus fréquemment. Microsoft a indiqué que le système d’atténuation des pics volumétriques considérait ces nouvelles tentatives comme légitimes et ne les écartait donc pas. Cela étaye une boucle de rétroaction d’amplification par nouvelles tentatives, mais pas une reconstitution précise au niveau des paquets. [2][4]
Microsoft a indiqué que la surveillance avait détecté une disponibilité réduite, que les ingénieurs étaient intervenus et que le service DNS s’était rétabli automatiquement vers 22 h 00 UTC. L’entreprise a reconnu que le temps de rétablissement dépassait son objectif de conception. Elle a ensuite modifié la logique d’atténuation pour se protéger des nouvelles tentatives excessives et a cité la réparation du défaut de cache ainsi qu’une meilleure détection du trafic anormal comme prochaines étapes. [2][4][5]
L’incident a touché un plan de contrôle réseau plutôt qu’une seule application. Les utilisateurs rencontraient des difficultés intermittentes pour résoudre les noms utilisés par Azure, Dynamics, Xbox Live et d’autres services Microsoft. Un enregistrement de service correct ne suffisait pas lorsque le chemin faisant autorité en cours d’exécution ne renvoyait pas de réponses fiables. [1][3][6]
La documentation Azure actuelle décrit un réseau DNS anycast mondial, des fonctions de fiabilité et des contrôles clients. Ces documents expliquent l’architecture et les responsabilités, mais ils ne peuvent pas servir de preuve de l’implémentation exacte de 2021 ni de l’achèvement des mesures correctives. [7]-[13]
Les normes DNS séparent le service faisant autorité de la résolution récursive et documentent la manière dont la mise en cache, l’absence de réponse et les nouvelles tentatives influencent la charge. La RFC 4697 est particulièrement pertinente, car le comportement de nouvelle tentative des résolveurs peut imposer un travail excessif aux serveurs faisant autorité. Les normes ne montrent pas quels clients ou résolveurs ont contribué et dans quelle proportion pendant cet incident. [14]-[22]
La responsabilité suit le contrôle. L’ingénierie d’Azure DNS contrôlait le code du cache, la capacité périphérique, la régulation du trafic, la classification des atténuations et l’automatisation de la reprise. Les équipes de service Microsoft contrôlaient les dépendances DNS partagées. Les opérateurs de résolveurs et de clients contrôlaient le comportement de nouvelle tentative et de cache. Les clients contrôlaient certains choix de surveillance et de délégation, mais ne pouvaient ni inspecter ni réparer le défaut interne d’Azure.
Une réparation crédible exige des preuves bornées dans le temps: taux de succès du cache par classe de requête, taux de nouvelles tentatives, saturation périphérique, changements de zone de captage anycast, comportement des règles d’atténuation, sondes de résolution valides connues, rétablissement par service et tests de récurrence. Aucun de ces éléments ne doit être déduit d’une simple étiquette de statut.

La chronologie comporte plusieurs horloges

Les rapports d’incident deviennent souvent plus propres à mesure qu’ils vieillissent. Le dossier Azure DNS doit résister à ce nettoyage lorsqu’il efface des distinctions utiles.

Le récit d’incident ultérieur de Microsoft situait le problème de disponibilité du service Azure DNS entre 21 h 21 UTC et 22 h 00 UTC le 1er avril 2021. Il indiquait que la majorité des services s’étaient rétablis vers 22 h 30 UTC. Exoprise a reproduit ce compte rendu et signalé que sa propre surveillance DNS et serveur avait déclenché une alarme vers 21 h 20. [2] Un avis communautaire contemporain d’un employé de Microsoft, publié alors que la réponse était encore en cours, décrivait un impact client entre environ 21 h 30 UTC et 22 h 30 UTC.

Une mise à jour ultérieure d’un employé de Microsoft sur la même page indiquait que les serveurs DNS de Microsoft avaient connu un pic de trafic et que des capacités DNS résilientes avaient été activées. [1]

Ces horodatages mesurent des choses différentes:

la première observation d’échec par un moniteur externe;
l’heure de début ultérieure indiquée par le fournisseur pour l’état du service DNS;
l’heure à laquelle le fournisseur a considéré que le DNS s’était rétabli automatiquement;
la période pendant laquelle les clients ont connu un accès intermittent;
l’heure à laquelle une majorité de services dépendants s’étaient rétablis.

Le rapport contemporain de The Register citait le début approximatif de 21 h 30 UTC et indiquait que Microsoft avait redirigé le trafic vers des capacités DNS résilientes pendant l’enquête. Il décrivait des effets dans les grandes régions géographiques, tout en excluant du périmètre rapporté le cloud gouvernemental de Microsoft et les services chinois. [3] TechCrunch signalait séparément des défaillances touchant plusieurs produits Microsoft et citait Microsoft reconnaissant un problème sur le portail Azure et les services Azure. [6]

Les preuves publiques n’établissent pas un moment de rétablissement universel pour chaque nom, résolveur, région ou service. Les caches DNS peuvent faire apparaître la panne et le rétablissement à des moments différents. Un résolveur disposant d’une réponse chaude peut continuer à servir un nom après la baisse de disponibilité du service faisant autorité. Un autre résolveur avec un cache froid peut échouer immédiatement. Lorsque le service faisant autorité s’améliore, un état négatif ou en échec chez les clients et les résolveurs intermédiaires peut encore retarder le rétablissement visible.

Microsoft lui-même distinguait le rétablissement automatique du DNS à 22 h 00 du rétablissement majoritaire des services à 22 h 30. [2]

Cette distinction compte pour la responsabilité. Un fournisseur ne devrait pas définir le rétablissement uniquement par une mesure serveur interne si les utilisateurs ne peuvent toujours pas résoudre des noms critiques. Une alarme externe ne devrait pas non plus être traitée automatiquement comme le début de la cause profonde. Une chronologie réconciliée exige au moins quatre pistes: santé du service faisant autorité, résultats des résolveurs récursifs, rétablissement des services dépendants et accessibilité visible par l’utilisateur.

Une surtension anormale n’est pas une attaque prouvée

Microsoft a indiqué qu’Azure DNS avait reçu une surtension anormale de requêtes provenant du monde entier et ciblant un ensemble de domaines hébergés sur Azure. [2][4] Il s’agit d’une description de volume et de distribution des cibles. Elle n’établit pas à elle seule qui a généré le trafic, si l’intention était malveillante, si les adresses sources étaient usurpées ou si l’événement répondait à une classification particulière de déni de service.

Certains reportages ont employé un vocabulaire d’attaque. Le dossier technique cité ici ne fournit ni échantillon de paquets, ni rapport d’attribution, ni déclaration de Microsoft nommant une campagne DDoS. La norme de preuve future est donc étroite:

Confirmé par le compte de Microsoft: une surtension mondiale de requêtes visait un ensemble de domaines hébergés sur Azure.
Confirmé par le compte de Microsoft: les caches normaux et la régulation du trafic du service étaient censés atténuer une telle surtension.
Confirmé par le compte de Microsoft: un défaut de code réduisait l’efficacité du cache périphérique dans une séquence particulière.
Inconnu: ce qui a déclenché la surtension.
Inconnu: si un acteur coordonné avait l’intention de priver le service.
Inconnu: si le trafic était usurpé, réfléchi, généré par des appareils compromis, causé par un comportement logiciel ou s’il combinait plusieurs sources.
Inconnu: les noms, types de requête, débits et distributions géographiques impliqués.

Cette frontière n’est pas une prudence sémantique gratuite. La réparation dépend du mécanisme. La validation des adresses sources peut restreindre le trafic usurpé, mais n’empêche pas les clients légitimes de réessayer. Une limite de débit peut supprimer un volume élevé, mais peut rejeter une résolution valide. Davantage de capacité de cache peut aider pour les questions répétées, mais peut ne pas aider une charge dominée par des noms uniques ou des combinaisons de requêtes contournant le cache. Une meilleure distribution anycast peut répartir le travail tout en déplaçant la surcharge entre les serveurs périphériques.

Qualifier la surtension d’attaque sans preuve ferait paraître une explication comme établie et pourrait orienter la responsabilité vers l’extérieur. Le propre compte de Microsoft identifie un défaut interne et une lacune de classification des atténuations, indépendamment de la source initiale. Même si le premier trafic était malveillant, le service devait encore gérer le mode de défaillance pris en charge: une efficacité de cache réduite suivie de nouvelles tentatives légitimes que son contrôle volumétrique n’a pas éliminées.

Le défaut de cache a modifié le coût de chaque requête

La mise en cache n’est pas une simple optimisation de performance dans un DNS faisant autorité. Elle peut déterminer la quantité de travail qu’un serveur périphérique effectue pour des questions répétées et la charge qui atteint des composants de service plus profonds.

Microsoft a indiqué que l’efficacité du cache DNS Edge avait diminué parce qu’un défaut de code avait été exposé par une séquence d’événements particulière. [2][4][5] La formulation est informative mais incomplète. Elle ne dit pas si les requêtes touchées manquaient un cache de réponses, contournaient un cache négatif, provoquaient des consultations répétées du backend, se disputaient un état partagé, invalidaient des entrées ou consommaient une autre ressource rare. Elle n’identifie pas si tous les serveurs périphériques étaient vulnérables ou seulement un sous-ensemble atteint par des chemins anycast particuliers.

La reconstitution responsable doit éviter de combler ces détails. Elle peut néanmoins montrer pourquoi l’efficacité compte.

Supposons un serveur périphérique simplifié recevant des questions répétées. Avec un taux de succès de cache élevé, la plupart des réponses sont servies depuis un état déjà disponible. Le travail marginal par requête reste relativement faible. Si un défaut pousse davantage de requêtes vers un chemin plus lent, chaque requête peut consommer plus de temps CPU, de mémoire, de synchronisation, de travail réseau ou de capacité de backend. La latence augmente. Les clients attendent plus longtemps ou ne reçoivent aucune réponse. Ils réessaient.

La population de nouvelles tentatives augmente alors le débit entrant même si la surtension initiale cesse de croître.

Voici la boucle de rétroaction centrale étayée par le récit de Microsoft:

Une surtension anormale de requêtes atteint Azure DNS.
Une séquence particulière expose un défaut d’efficacité du cache.
Davantage de requêtes exigent un traitement coûteux ou attendent plus longtemps.
La disponibilité du service DNS diminue.
Les clients réessaient les requêtes restées sans réponse.
Le système volumétrique traite ces nouvelles tentatives comme légitimes.
Le trafic de nouvelles tentatives ajoute une charge au service déjà altéré.

La boucle n’exige pas qu’un client particulier se comporte de manière irrationnelle. Une nouvelle tentative peut être individuellement raisonnable. La défaillance systémique provient du comportement agrégé et de l’incapacité de l’opérateur à classer ou réguler ce travail en toute sécurité.

Les RFC 1034 et 1035 établissent la mise en cache comme un élément fondamental du fonctionnement du DNS. [17][18] La RFC 2308 définit la mise en cache négative afin que les résolveurs ne reposent pas sans limite la même question d’inexistence. [19] Des normes ultérieures comme les RFC 8020 et 8198 décrivent des moyens de réduire le trafic de requêtes négatives inutiles dans des conditions particulières. [21][22] Aucun de ces documents ne prouve que le défaut d’Azure concernait des réponses négatives. Ils montrent seulement que la réutilisation des requêtes, l’état du cache et les échecs répétés sont des variables opérationnelles reconnues.

Des nouvelles tentatives légitimes peuvent rester dangereuses en agrégat

L’aveu le plus lourd de conséquences de Microsoft a été que les nouvelles tentatives des clients étaient considérées comme du trafic DNS légitime et n’étaient donc pas écartées par les systèmes d’atténuation des pics volumétriques. [2][4]

« Légitime » peut signifier plusieurs choses. Un paquet peut avoir une source plausible. Une requête peut être conforme au protocole. Un client peut être autorisé à utiliser un résolveur récursif. Un domaine demandé peut exister. Rien ne garantit qu’un flux agrégé non borné de nouvelles tentatives soit sûr pour un service faisant autorité altéré.

La RFC 4697 documente un comportement de résolveur qui peut imposer une charge de requêtes excessive aux serveurs faisant autorité. Elle décrit des schémas dans lesquels les résolveurs réessaient de manière trop agressive, interrogent plusieurs serveurs ou poursuivent leur travail alors qu’une réponse plus disciplinée réduirait la charge. [20] Le document précède l’incident Azure de nombreuses années. Sa pertinence n’est pas qu’Azure ait nécessairement violé un algorithme prescrit. Il établit que l’amplification par nouvelles tentatives à la frontière résolveur-autorité est une classe de défaillance opérationnelle connue.

Le dossier Azure laisse plusieurs questions sans réponse:

Quels clients ou implémentations récursives ont réessayé?
Les nouvelles tentatives étaient-elles concentrées dans des composants de service opérés par Microsoft, des résolveurs publics, des résolveurs d’entreprise ou des appareils d’utilisateurs finaux?
Quelle réponse ou quel délai d’attente déclenchait la tentative suivante?
Les intervalles de nouvelle tentative étaient-ils aléatoires ou synchronisés?
Les clients basculaient-ils entre des adresses anycast ou répétaient-ils vers le même serveur périphérique atteint?
Quelles classes de requête généraient le coût le plus élevé après l’apparition du défaut de cache?
Les nouvelles tentatives valides devenaient-elles distinguables de la surtension initiale par nom, horodatage, réseau source ou réponse antérieure?

Sans ces mesures, « nouvelles tentatives excessives » est une catégorie utile mais pas un diagnostic complet.

Le défi d’atténuation est également réel. Écarter toutes les nouvelles tentatives peut allonger une panne et refuser des clients dont le premier paquet a simplement été perdu. Autoriser chaque nouvelle tentative peut entretenir la surcharge. L’opérateur a besoin d’une admission bornée: protéger suffisamment de travail valide connu pour préserver le rétablissement tout en limitant les schémas qui consomment des ressources disproportionnées.

Microsoft a indiqué avoir mis à jour la logique d’atténuation volumétrique immédiatement après l’incident pour protéger le service DNS des nouvelles tentatives excessives. [2][4] Un compte vérifiable montrerait quel signal a changé, comment la nouvelle règle distingue une nouvelle tentative inoffensive d’un comportement agrégé nuisible, quels tests de faux positifs ont été exécutés et comment les opérateurs peuvent désactiver ou ajuster le contrôle s’il bloque des noms légitimes.

Le service faisant autorité et la résolution récursive sont des domaines de contrôle distincts

Une recherche DNS d’un utilisateur traverse des systèmes opérés par différentes parties.

Le résolveur stub d’un appareil interroge normalement un résolveur récursif. Le résolveur récursif peut répondre depuis son cache. S’il ne dispose pas d’une réponse utilisable, il suit les délégations et interroge les serveurs faisant autorité de la zone concernée. Les RFC 1034 et 1035 définissent ces rôles et les échanges de messages entre eux. [17][18]

Azure DNS opérait la couche faisant autorité pour les domaines hébergés sur Azure touchés. Il contrôlait l’implémentation périphérique du service, le comportement du cache, la capacité, la régulation du trafic et les réponses faisant autorité. Les résolveurs récursifs contrôlaient l’état en cache, la sélection des serveurs, l’interprétation des délais d’attente et le comportement de nouvelle tentative. Les applications contrôlaient si et comment leurs propres appels réessayaient après un échec de résolution de nom. Les réseaux d’accès et le routage Internet influençaient le serveur périphérique Azure atteint par une requête anycast.

Le même symptôme peut donc avoir différentes causes:

Un résolveur peut expirer parce que le serveur périphérique faisant autorité atteint est surchargé.
Un chemin peut perdre des paquets même si le serveur périphérique est sain.
Un résolveur peut conserver un résultat négatif ou un état de nouvelle tentative épuisé après l’amélioration du service faisant autorité.
Une application peut transformer un échec de résolveur en de nombreuses nouvelles tentatives parallèles.
Une page d’état peut elle-même être difficile à atteindre parce que son nom d’hôte dépend de la couche altérée.

La RFC 8906 explique qu’un serveur faisant autorité qui ne répond pas peut être indiscernable d’une perte de paquets du point de vue du résolveur. [16] Cette ambiguïté affecte à la fois le comportement automatisé et la communication d’incident. Un résolveur peut raisonnablement essayer une autre adresse faisant autorité, mais de nombreux résolveurs prenant la même décision peuvent déplacer ou multiplier la charge.

La responsabilité ne devrait pas aplatir ces rôles. Azure ne peut pas contrôler chaque algorithme client. Les opérateurs de résolveurs ne peuvent pas corriger le code de cache d’Azure. Les clients ne peuvent pas inspecter la télémétrie interne des serveurs périphériques. Mais Azure contrôlait la frontière de service qui acceptait les requêtes et la logique d’atténuation qui classait le trafic de nouvelles tentatives. Cela lui confère la responsabilité principale de démontrer que le service faisant autorité pouvait se dégrader sans transformer un comportement de rétablissement valide en surcharge durable.

L’anycast répartit les requêtes mais ne rend pas chaque serveur périphérique équivalent

La documentation Microsoft actuelle indique qu’Azure DNS utilise un réseau mondial de serveurs de noms et l’anycast pour diriger chaque requête vers un serveur DNS proche disponible. [7] Les conseils anycast de Windows Server de Microsoft expliquent le schéma général: plusieurs sites annoncent la même adresse de service et le routage sélectionne un chemin. [9]

Ces documents décrivent l’architecture actuelle et la pratique générale. Ils ne prouvent pas la topologie exacte de 2021, la politique de routage ou le comportement de retrait. Cette frontière temporelle doit rester explicite.

La RFC 9199 explique pourquoi les grands services faisant autorité utilisent couramment plusieurs serveurs, l’anycast et l’équilibrage de charge. Elle met aussi en garde contre l’hypothèse d’un modèle de déploiement universel. Le placement des résolveurs, le routage, le peering et la forme de la zone de captage influencent l’instance qui reçoit le trafic. [14]

Pendant une surtension de requêtes, l’anycast peut répartir la charge. Il peut aussi produire une expérience inégale:

une zone de captage peut recevoir une part plus importante d’une charge ciblée;
les changements de route peuvent déplacer à la fois les requêtes hostiles et légitimes vers un autre serveur périphérique;
un nœud peut rester joignable alors que sa couche applicative est surchargée;
un retrait peut protéger un site tout en concentrant le trafic ailleurs;
des résolveurs récursifs de réseaux différents peuvent atteindre des serveurs périphériques différents et signaler des disponibilités différentes.

L’analyse des causes profondes publiée par Microsoft ne divulgue pas si le défaut de cache touchait tous les serveurs périphériques, si les routes ont changé, si les capacités DNS résilientes signifiaient un déplacement de zone de captage, ou si certains serveurs avaient une meilleure efficacité de cache que d’autres. [1][2]

L’expression « trafic redirigé vers nos capacités DNS résilientes » figurait dans les rapports de statut contemporains. [3] Elle est trop large pour établir ce qui a changé. Un compte technique crédible relierait l’expression à des preuves:

quelles routes ou quels points de terminaison de service ont changé;
quelles zones de captage ont été déplacées;
si l’état du cache a été déplacé ou préchauffé;
comment les taux de réponses et de délais d’attente ont changé à chaque étape;
si le changement a réduit le volume de nouvelles tentatives;
quelles sondes externes ont confirmé le rétablissement.

L’anycast est une infrastructure, pas une absolution. Sa valeur se mesure à la continuité observée sous la charge réelle.

Servir des données périmées est une option, pas une panacée supposée

Lorsque les serveurs faisant autorité ne peuvent pas répondre, un résolveur récursif peut disposer d’une copie expirée d’une réponse précédemment valide. La RFC 8767 définit une méthode bornée pour servir des données périmées afin d’améliorer la résilience dans des conditions spécifiées. [15]

Ce mécanisme est pertinent pour la continuité, mais ne devrait pas être importé dans l’incident comme un contrôle manquant. Les sources publiques ne disent pas quels résolveurs détenaient des réponses périmées, quels enregistrements étaient assez stables pour être servis, si les réponses avaient expiré ou si la distribution de données périmées était activée.

Servir des données périmées comporte des compromis:

Il peut maintenir joignable un nom de service stable pendant une courte défaillance du service faisant autorité.
Il peut conserver une adresse que l’opérateur a un besoin urgent de changer.
Il peut masquer une altération continue du service faisant autorité pour certains utilisateurs.
Il n’aide pas une première requête sans réponse en cache.
Il ne répare pas le serveur périphérique faisant autorité et ne réduit pas toutes les classes de requête.
Son utilité dépend de l’état antérieur du cache et des limites configurées.

La mise en cache négative a des frontières similaires. La RFC 2308 réduit les requêtes répétées pour des réponses négatives connues. La RFC 8020 permet à un résolveur de s’arrêter sous une branche NXDOMAIN validée. La RFC 8198 autorise l’utilisation agressive des enregistrements de déni authentifiés par DNSSEC pour synthétiser des réponses négatives supplémentaires. [19][21][22]

Ces mécanismes peuvent réduire le travail en amont inutile. Ils ne prouvent pas que la surtension Azure consistait en des noms inexistants aléatoires ni que le défaut exposé concernait la mise en cache négative. Ils ne peuvent pas non plus être recommandés en toute sécurité sans connaître la distribution des requêtes et l’état DNSSEC.

La question fondée sur les preuves n’est pas « Pourquoi chaque résolveur a-t-il échoué à servir des données périmées? ». Elle est:

Quels noms touchés disposaient de réponses en cache utilisables?
Quelle part du trafic de nouvelles tentatives provenait d’états de cache froids, positifs, négatifs ou expirés?
Quel comportement de résilience réduisait le travail faisant autorité sans conserver un état périmé dangereux?
Quel comportement d’application se produisait lorsque les résolveurs renvoyaient des réponses périmées, échouées ou retardées?

Ces mesures transformeraient une discussion générale sur les normes en une décision de contrôle propre à l’incident.

La concentration des dépendances a fait ressembler une seule défaillance DNS à de nombreuses pannes de service

L’incident était visible au travers d’Azure, Dynamics, Xbox Live et d’autres services Microsoft parce que la résolution de noms se trouvait sous plusieurs chemins de service. L’avis de questions-réponses de Microsoft citait Azure, Dynamics et Xbox Live. [1] Exoprise reproduisait une communication Microsoft 365 mentionnant Teams et un ensemble plus large de produits dépendants. [2] The Register et TechCrunch décrivaient indépendamment des plaintes d’accès répandues sur les propriétés Microsoft. [3][6]

Les preuves ne montrent pas que chaque application sous-jacente avait échoué. Un utilisateur incapable de résoudre un nom de service vit une indisponibilité de service même si le calcul, le stockage et les processus applicatifs restent sains. Cette distinction compte à la fois pour le diagnostic et pour le rétablissement.

Le DNS fait partie de l’identité réseau. Il associe les noms utilisés par les utilisateurs et les logiciels à des points de terminaison joignables. Un enregistrement peut rester correctement stocké tandis que le service qui y répond devient indisponible. L’utilisateur ne tire aucun bénéfice pratique de l’enregistrement correct si aucune réponse n’arrive.

Une dépendance partagée soulève plusieurs questions de responsabilité:

Les chemins de statut public, de support, de gestion et d’authentification dépendaient-ils de la même couche DNS faisant autorité?
Les intervenants internes pouvaient-ils atteindre les outils nécessaires au diagnostic et à la communication?
Quelles équipes de service surveillaient indépendamment le DNS depuis l’extérieur du réseau Microsoft?
Quels propriétaires de service savaient que leurs noms partageaient une même implémentation de cache périphérique?
Existait-il des chemins de communication d’urgence statiques hors de l’espace de noms touché?
Le rétablissement des services dépendait-il de l’expiration ou du rafraîchissement des caches des résolveurs après le rétablissement du service faisant autorité?

Exoprise signalait des difficultés avec les pages d’état Azure pendant l’événement et décrivait Microsoft orientant les utilisateurs vers d’autres surfaces de statut. [2] Ce rapport doit être traité comme une observation indépendante, pas comme la preuve que chaque point de terminaison de statut a échoué pour la même raison. Il expose néanmoins un problème de gouvernance: un canal de communication d’incident ne devrait pas partager une dépendance non examinée avec le service qu’il rapporte.

La réparation n’est pas nécessairement un second fournisseur DNS pour chaque nom. Elle commence par un graphe de dépendances précis et une observation indépendante. Les propriétaires de service Microsoft doivent savoir quels noms, chemins faisant autorité, résolveurs récursifs et actions de plan de contrôle restent communs.

La surveillance a détecté la dégradation, mais la détection n’est pas l’endiguement

Microsoft a indiqué qu’une disponibilité de service réduite avait déclenché les systèmes de surveillance et mobilisé les ingénieurs. [2] Exoprise a indiqué que son moniteur externe avait alerté vers 21 h 20, près du début ultérieur de 21 h 21 de la fenêtre DNS du fournisseur. [2]

Ce timing suggère que la détection n’était pas le seul problème. Le service s’est rétabli automatiquement à 22 h 00, mais Microsoft a reconnu que la durée dépassait son objectif de conception. La question pertinente devient ce que les opérateurs pouvaient faire après la détection.

Un système de détection utile devrait séparer au moins ces signaux:

débit de requêtes entrantes;
taux de succès et d’échec du cache par classe de requête;
coût par requête répondue ou échouée;
profondeur de file d’attente et saturation du serveur;
taux de réponses valides;
taux de délais d’attente et d’erreurs des résolveurs externes;
volume de nouvelles tentatives et distribution des sources de nouvelles tentatives;
mouvements de zone de captage anycast;
succès de résolution de noms spécifique au service.

Une alarme de trafic agrégé peut manquer un changement dans le travail par requête. Un défaut de cache peut transformer un débit de requêtes familier en problème de capacité. Une alarme de disponibilité peut ne se déclencher qu’après que les utilisateurs échouent déjà. Un détecteur volumétrique peut classer les nouvelles tentatives comme valides alors que leur effet agrégé empêche le rétablissement.

Le compte public indique que les ingénieurs ont préparé une capacité de service supplémentaire et une capacité à répondre aux requêtes DNS depuis le système d’atténuation volumétrique si une action supplémentaire devenait nécessaire. [2] Il ne dit pas si l’une ou l’autre étape a été réellement appliquée avant le rétablissement automatique, quel seuil l’aurait déclenchée, ou si la capacité aurait rompu la boucle de rétroaction.

Voici une distinction de contrôle:

La détection répond à la question de savoir si quelque chose ne va pas.
Le diagnostic identifie le mécanisme.
L’endiguement limite la rétroaction nuisible.
Le rétablissement restaure la résolution valide.
La vérification montre que les utilisateurs externes et les services dépendants se sont rétablis.

Une alarme rapide n’excuse pas un endiguement faible. Le rétablissement automatique ne prouve pas non plus que le service pourrait se rétablir de manière fiable d’une surtension plus longue ou répétée.

Le rétablissement a dépassé l’objectif de conception

La déclaration de Microsoft selon laquelle le rétablissement a dépassé son objectif de conception est inhabituellement utile, car elle révèle une norme interne sans divulguer la cible numérique. [2][5]

La déclaration soulève quatre questions.

Premièrement, que mesurait l’objectif de conception? Il pouvait se référer à la disponibilité des réponses faisant autorité, au temps de rétablissement automatique, au temps d’intervention de l’opérateur ou à la restauration de service de bout en bout. Ces mesures ne sont pas interchangeables.

Deuxièmement, quel mécanisme était censé l’atteindre? Un cache peut se rétablir à mesure que la charge diminue. Un site anycast peut se retirer. De la capacité peut être ajoutée. Une règle d’atténuation peut changer. Sans propriétaire de contrôle et sans déclencheur, l’« objectif de conception » reste une aspiration.

Troisièmement, l’objectif était-il testé face à une défaillance combinée? Un test de charge normal peut mesurer la capacité de requêtes avec une efficacité de cache saine. Un test de cache peut ne pas inclure des nouvelles tentatives synchronisées. Un test d’atténuation volumétrique peut modéliser des paquets hostiles mais autoriser des nouvelles tentatives valides sans limite. L’événement de 2021 a réuni ces conditions.

Quatrièmement, comment la réparation a-t-elle été validée? Microsoft a cité la réparation du défaut de code afin que les requêtes puissent être traitées efficacement en cache et l’amélioration de la détection et de l’atténuation automatiques du trafic anormal. [2][4] Une liste d’éléments de travail n’est pas une preuve d’achèvement.

La clôture appropriée lierait chaque mesure à un test:

Mesure	Preuve requise
Réparation du défaut de cache	Test de reproduction de la séquence déclenchante, efficacité du cache avant et après, identifiants de code et de déploiement
Protection contre les nouvelles tentatives	Charge de nouvelles tentatives contrôlée, préservation des réponses légitimes, taux de faux positifs, seuil de restauration
Détection d’anomalie	Latence de détection par classe de requête, preuves de sensibilité et de fausses alarmes
Capacité périphérique	Marge de saturation par serveur périphérique avec une efficacité de cache dégradée
Rétablissement automatique	Exécutions répétées d’injection de panne et distribution des temps de rétablissement
Rétablissement des services	Sondes externes pour des noms Microsoft et clients représentatifs sur plusieurs réseaux de résolveurs

Sans ces preuves, les lecteurs peuvent savoir ce que Microsoft comptait améliorer, mais pas quelle part du risque a été supprimée.

Le SLA ne remplace pas les preuves d’incident

Azure publie un SLA pour les zones DNS. Le document actuel définit la disponibilité du service et les crédits de service potentiels dans des conditions contractuelles spécifiées. [13] Il est utile pour identifier la frontière juridique et commerciale actuelle.

Il n’établit pas quels contrats de 2021 s’appliquaient, si un client particulier remplissait les conditions de la réclamation, si l’indisponibilité mesurée dépassait un seuil ou si Microsoft avait une responsabilité juridique. Les sources publiques de ce dossier ne contiennent aucune réclamation propre à un client, aucune décision de régulateur ni aucune conclusion judiciaire.

Un SLA peut également mesurer un objet plus étroit que le préjudice subi par le client. Un calcul de disponibilité DNS peut ne pas saisir le rétablissement retardé des applications, l’accès aux pages d’état, la main-d’œuvre opérationnelle ou les transactions perdues parce qu’un résolveur ne pouvait pas obtenir de réponse. Inversement, un signalement de difficulté de service par un client ne prouve pas automatiquement une violation du SLA.

Le registre de responsabilité devrait donc tenir trois comptes séparés:

Disponibilité technique: ce que les systèmes faisant autorité et récursifs ont renvoyé.
Impact client: quelles fonctions ont échoué, pour qui et pendant combien de temps.
Recours contractuel: quelles conditions, mesures et procédures de réclamation s’appliquaient.

Les confondre exagère la responsabilité ou minimise le préjudice. Les frontières comptent donc plus que le choix d’une mesure unique comme représentation de tout l’incident.

Les clients contrôlaient l’architecture, pas le défaut d’Azure

Les conseils de fiabilité Azure actuels décrivent les responsabilités du fournisseur et du client. Azure opère la plateforme DNS, tandis que les clients configurent les zones, les enregistrements, la délégation et certains choix de résilience. [8][12]

Les clients peuvent prendre des mesures utiles:

surveiller les noms critiques depuis des résolveurs et des réseaux extérieurs à Azure;
inventorier les chemins de contrôle et d’utilisateur qui dépendent de zones hébergées sur Azure;
choisir les TTL délibérément;
tester le comportement des applications lorsque la résolution échoue;
préserver les chemins d’accès et de communication d’urgence;
évaluer la diversité des fournisseurs faisant autorité pour les systèmes qui justifient sa complexité;
comprendre les opérations DNSSEC et de délégation s’ils les utilisent.

Ces contrôles ne transfèrent pas aux clients la responsabilité du défaut de cache d’Azure. Un client ne peut pas inspecter l’implémentation périphérique, modifier la classification volumétrique ni ajouter de la capacité au fournisseur. On ne devrait pas non plus lui dire qu’une architecture unique est universellement correcte.

Un DNS faisant autorité multi-fournisseurs peut réduire un mode de défaillance courant, mais il ajoute des risques de synchronisation de zone, de délégation, de DNSSEC, de contrôle d’accès et de bascule. La RFC 9199 met l’accent sur le contexte plutôt que sur une conception imposée unique. [14] Un second fournisseur qui partage le routage, l’accès au registraire, l’automatisation ou le personnel opérationnel peut ne pas être indépendant sur les aspects qui comptent.

La décision pertinente du client est une acceptation documentée du risque:

Quelles défaillances de résolution de noms le service doit-il survivre?
Quels domaines de défaillance sont réellement indépendants?
À quelle vitesse l’état de délégation ou de fournisseur peut-il changer?
Quel état périmé ou conflictuel une bascule pourrait-elle créer?
Qui a l’autorité d’exécuter et d’annuler le changement?
Quel test prouve que le chemin fonctionne depuis les réseaux réels des utilisateurs?

La résilience du client est une couche de défense. Elle n’excuse pas un opérateur d’infrastructure de laisser son propre défaut et son comportement d’atténuation non mesurés.

La responsabilité suit le contrôle et l’accès aux preuves

Le dossier public étaye une répartition fondée sur le contrôle.

Ingénierie Azure DNS

L’ingénierie Azure DNS contrôlait le service faisant autorité, l’implémentation du cache, le déploiement périphérique, la régulation du trafic, la logique d’atténuation volumétrique et l’automatisation du rétablissement. Elle disposait du meilleur accès aux distributions de requêtes, aux métriques de cache et à l’état des serveurs. Son devoir n’était pas d’empêcher toute surtension de requêtes. Il était de concevoir et de tester le comportement de dégradation afin qu’un seul défaut de cache ne permette pas à des nouvelles tentatives valides d’entretenir la surcharge, et de conserver les preuves montrant ce qui s’est passé.

Gestion des incidents Microsoft

La gestion des incidents contrôlait l’escalade, la coordination et la communication publique. La différence entre la mise à jour préliminaire « pic » et le compte ultérieur de défaut de cache est raisonnable pendant l’enquête, à condition que le dossier montre ce qui a changé. Elle devrait préserver une séquence horodatée d’hypothèses, de preuves et d’actions correctives plutôt que de présenter le récit final comme s’il était connu depuis le début.

Propriétaires de services Microsoft

Les équipes exécutant Azure, Dynamics, Xbox Live, Microsoft 365 et les surfaces de contrôle associées contrôlaient la conception de leurs dépendances et la surveillance externe. Elles ne contrôlaient pas le défaut DNS, mais elles pouvaient identifier si les noms critiques, les pages d’état et les outils de rétablissement partageaient le même chemin faisant autorité.

Opérateurs de résolveurs récursifs et de clients

Les développeurs de résolveurs et de clients contrôlaient les intervalles de nouvelle tentative, le comportement de cache et la gestion des échecs. La RFC 4697 montre pourquoi la discipline en matière de nouvelles tentatives est une responsabilité partagée reconnue de longue date. [20] Le dossier n’identifie pas quelles implémentations ont généré le plus de trafic, de sorte qu’aucun opérateur spécifique ne devrait être accusé. Un post-mortem complet fournirait des distributions agrégées permettant à l’écosystème de réparer les schémas nuisibles.

Clients

Les clients contrôlaient certains choix de zone, de TTL, de surveillance et de diversité des fournisseurs. Leur responsabilité dépend de la criticité du service, des options contractuelles disponibles et de la faisabilité d’un DNS indépendant. Ils ne possédaient ni l’information ni l’autorité nécessaires pour corriger le cache périphérique d’Azure ou le classificateur d’atténuation.

Cette répartition est asymétrique parce que le contrôle et les preuves étaient asymétriques. Azure détenait les preuves opérationnelles centrales et les moyens de modifier le service défaillant.

Les contrefactuels montrent quels contrôles importent

L’analyse contrefactuelle aide à séparer le déclencheur, les conditions contributives et la réparation.

Si la surtension anormale s’était produite sans le défaut de cache

Microsoft a indiqué que les caches normaux et la régulation du trafic atténueraient la surtension. [2][4] Si cette déclaration est correcte, le service aurait dû conserver une efficacité de cache plus élevée et un travail par requête plus faible. Cela fait du défaut une condition contributive ou un candidat à la cause profonde, pas simplement un bogue de fond.

Si le défaut de cache était apparu sans surtension

Le service aurait pu avoir suffisamment de capacité de réserve pour absorber l’efficacité réduite. Cela ferait de la surtension une condition déclenchante. Le dossier public ne révèle pas la marge, de sorte que l’interaction est plus défendable que l’attribution d’un seul facteur comme cause profonde entière.

Si les nouvelles tentatives avaient été bornées immédiatement

La boucle de rétroaction aurait pu s’affaiblir. Mais un filtre de nouvelles tentatives trop large aurait pu refuser du trafic de rétablissement légitime. Le contrôle correct devrait préserver des requêtes valides représentatives et démontrer un faible taux de faux positifs.

Si chaque résolveur avait servi des réponses périmées

Certains noms stables auraient pu rester joignables, tandis que les utilisateurs à cache froid et les enregistrements modifiés auraient encore échoué. Une distribution universelle de données périmées pourrait aussi conserver un état dangereux. Ce n’est pas une réparation contrefactuelle complète.

Si les clients avaient utilisé deux fournisseurs faisant autorité

Certains noms auraient pu conserver un chemin indépendant, à condition que la délégation, les données de zone, le DNSSEC et la politique de santé soient coordonnés. D’autres dépendances partagées ou comportements de résolveur pourraient encore échouer. La diversité est une architecture testable, pas un slogan.

Si davantage de capacité périphérique avait été disponible

La capacité aurait pu retarder la saturation. Elle n’aurait pas nécessairement supprimé le défaut de cache ni classé les nouvelles tentatives. Un système plus grand avec la même boucle de rétroaction peut échouer plus tard et à plus grande échelle.

Ces contrefactuels étayent une conclusion en couches: la surtension initiale a déclenché l’événement; le défaut de cache a accru le travail par requête; le comportement de nouvelle tentative a amplifié la charge; la classification des atténuations a échoué à rompre la boucle; la concentration des dépendances a propagé l’impact; et les contrôles de rétablissement ont pris plus de temps que l’objectif de conception du fournisseur.

Ce que les preuves publiques ne peuvent toujours pas prouver

Les sources établissent un schéma utile mais laissent le dossier interne décisif indisponible.

Elles n’établissent pas:

la source, l’intention ou la propriété de la surtension de requêtes initiale;
si la surtension était une attaque coordonnée;
le volume de requêtes, le débit de paquets ou la distribution des types de requête;
les domaines et enregistrements ciblés;
l’implémentation du cache ou le chemin de code qui a échoué;
les taux de succès du cache avant, pendant et après l’incident;
le nombre ou l’emplacement des serveurs périphériques DNS touchés;
les changements de route ou de zone de captage anycast;
quels résolveurs récursifs ou clients ont produit des nouvelles tentatives;
les intervalles de nouvelle tentative, la synchronisation ou le facteur d’amplification;
la règle d’atténuation volumétrique exacte avant et après la réparation;
l’impact par service et par région;
les pertes clients, les crédits SLA ou la responsabilité juridique;
la date d’achèvement et la validation indépendante des mesures correctives;
si la même séquence déclenchante a été testée depuis.

La documentation Microsoft actuelle ne peut pas combler ces lacunes historiques. Elle décrit le service d’aujourd’hui et les pratiques recommandées. [7]-[13] Les RFC définissent le comportement des protocoles et les options opérationnelles. [14]-[22] Les rapports indépendants préservent des déclarations et des symptômes mais n’ont pas la télémétrie interne d’Azure. [2]-[6]

L’absence de détails publics ne prouve ni dissimulation ni négligence. Elle limite la confiance de toute conclusion causale ou juridique. Le constat le plus solide est que le propre compte de Microsoft identifie un défaut de cache interne, une boucle de rétroaction de nouvelles tentatives légitimes et une lacune d’atténuation. La répartition précise de la responsabilité au-delà du service contrôlé par Microsoft reste partiellement inconnue.

Une réparation devrait être auditable comme une séquence

Un programme de remédiation vérifiable préserverait un test d’incident commun plutôt qu’une liste d’améliorations déconnectées.

Reproduire

Créer une charge sûre correspondant à la séquence pertinente de requêtes et d’état de cache. Enregistrer la version du logiciel, la forme de la zone, les types d’enregistrement, l’état du cache et la topologie périphérique. Prouver que le système pré-correctif présente la baisse d’efficacité.

Mesurer

Capturer les taux de succès et d’échec du cache, le coût par requête, la latence de réponse, le taux de délais d’attente, la profondeur de file, la saturation périphérique et le volume de nouvelles tentatives. Séparer le trafic initial des nouvelles tentatives lorsque les preuves le permettent.

Contenir

Appliquer une régulation bornée des nouvelles tentatives et des contrôles du trafic anormal. Tester des noms valides connus, des états de cache froids et chauds, des réponses négatives, des réponses DNSSEC et plusieurs comportements de résolveur. Mesurer les faux positifs.

Rétablir

Démontrer que la disponibilité du service faisant autorité revient dans l’objectif de conception sans attendre uniquement la baisse du trafic externe. Confirmer le comportement anycast et de route sur des réseaux indépendants.

Vérifier les services dépendants

Sonder des noms représentatifs Azure, du plan de contrôle Microsoft et de clients depuis plusieurs résolveurs récursifs et réseaux d’accès. Distinguer le rétablissement DNS du rétablissement applicatif.

Revenir en arrière

Montrer que les contrôles d’urgence ont des propriétaires, des conditions d’expiration et une configuration réversible. Une atténuation qui reste indéfiniment peut devenir une nouvelle source de déni.

Conserver les preuves

Lier les résultats des tests aux identifiants de code, de déploiement et de configuration. Publier un résumé borné avec suffisamment de mesures pour montrer que la boucle de rétroaction particulière a été supprimée sans exposer de détails d’infrastructure sensibles.

Cette séquence répond à la question centrale: non pas si Microsoft a ajouté « plus de résilience », mais si la même interaction cache-et-nouvelles-tentatives peut encore franchir le seuil de défaillance.

Conclusion

La panne Azure DNS d’avril 2021 ne s’expliquait pas uniquement par le volume de trafic.

Microsoft a indiqué qu’une surtension anormale de requêtes a exposé un défaut de code réduisant l’efficacité des caches DNS Edge. Un service dégradé a poussé les clients à réessayer. Ces nouvelles tentatives étaient du trafic légitime, si bien que l’atténuation volumétrique ne les a pas initialement écartées. Le service s’est rétabli automatiquement, mais pas dans son objectif de conception. Microsoft a ensuite modifié la protection contre les nouvelles tentatives et indiqué qu’il réparerait le défaut de cache et améliorerait la détection d’anomalies. [2][4][5]

Cette séquence identifie un problème de responsabilité des infrastructures réseau à plusieurs couches:

La surtension était le déclencheur décrit par Microsoft, pas une attribution d’attaque prouvée.
Le défaut de cache était une condition contributive interne qui a accru le travail.
Le comportement de nouvelle tentative légitime a amplifié la charge à la frontière résolveur-autorité.
La logique d’atténuation n’a pas initialement contenu ce trafic valide agrégé.
La dépendance DNS partagée a transformé une seule défaillance de résolution en de nombreuses pannes de service apparentes.
Les métriques de rétablissement ne correspondaient pas clairement à l’expérience de chaque utilisateur.

La conclusion responsable n’est pas que les nouvelles tentatives DNS sont mauvaises, que l’anycast a échoué ou que les clients devraient toujours utiliser un second fournisseur. Chaque affirmation dépasserait les preuves.

La norme plus solide est un comportement de dégradation mesurable. Un opérateur DNS faisant autorité devrait connaître l’évolution de l’efficacité du cache sous des séquences de requêtes inhabituelles, l’effet des nouvelles tentatives légitimes sur la capacité, les atténuations qui protègent les réponses valides, la réponse des zones de captage anycast et les sondes externes qui prouvent le rétablissement. Les opérateurs de résolveurs et de clients devraient borner les nouvelles tentatives et le comportement de cache.

Les propriétaires de service devraient identifier les dépendances de nommage critiques et préserver une communication d’incident indépendante. Les clients devraient tester les décisions de continuité qu’ils peuvent réellement contrôler.

Les enregistrements, les descriptions de service et les avis de statut font partie des preuves. Ils ne sont pas le service en cours d’exécution. Le 1er avril 2021, des noms pouvaient rester correctement configurés alors que les utilisateurs ne pouvaient pas les résoudre de manière fiable. La responsabilité commence là où ces deux états divergent.

La preuve finale est un test reproductible lié à la réparation réelle: recréer la séquence, mesurer l’efficacité du cache, induire des nouvelles tentatives bornées, activer l’atténuation, préserver les réponses valides connues, se rétablir dans l’objectif de conception et confirmer les résultats depuis des réseaux indépendants. Sans ces preuves, le public dispose d’un récit plausible. Avec elles, les opérateurs peuvent montrer que la boucle de rétroaction a été refermée.