Comment les Pannes DNS Causent des Temps d'Arrêt Invisibles

Les plateformes d'observabilité sont conçues pour suivre ce que font vos systèmes. Mais que se passe-t-il lorsqu'une panne survient avant même qu'une requête n'atteigne le bord de votre infrastructure ? Vos tableaux de bord signaleront avec confiance une disponibilité de 100 %, tandis que vos clients subiront une panne totale.

Le Dilemme du 'Split-Horizon'

La raison pour laquelle vos métriques mentent est due à la nature d'horizon divisé des réseaux cloud. Vos pods internes de Kubernetes résolvent les points de terminaison de service à l'aide d'un résolveur VPC privé. Étant donné que le réseau interne est intact, les contrôles de santé réussissent.

Mais les clients externes s'appuient sur la chaîne de résolution récursive de l'Internet public pour découvrir votre Ingress public.

Quand la Porte Disparaît

Une panne 'invisible' survient lorsque les enregistrements faisant autorité publics sont perturbés. Un exemple classique est la panne de Slack en 2021 : une configuration a accidentellement supprimé tous les enregistrements A pour leurs API principales.

Interne aux serveurs de Slack fonctionnaient, traitant les tâches en arrière-plan. Mais aucun nouveau client ne pouvait résoudre le domaine 'slack.com'. Internet a simplement oublié où Slack était hébergé.

Isoler l'Écart

Pour prouver cette divergence, vous pouvez écrire un script de test simple. Forcez explicitement une requête DNS contre le serveur faisant autorité public :

nslookup -debug votredomaine.com ns1.votre-fournisseur-dns.com

Si cette commande expire, votre couche faisant autorité est défaillante, peu importe ce que dit votre outil interne.

Conclusion

Lors de la conception de votre posture de fiabilité, ne vous fiez jamais à un contrôle de santé interne pour valider l'accessibilité externe.