Comment les pannes DNS causent des temps d'arrêt invisibles

Si vous avez été de garde assez longtemps, vous connaissez cette sensation. Les alertes PagerDuty s'allument, les tableaux de bord virent au rouge et les clients inondent les canaux de support. Votre base de données est saine. Vos serveurs d'application tournent. Les répartiteurs de charge signalent zéro connexion interrompue.

Alors, qu'est-ce qui est en panne au juste ?

Souvent, ce n'est pas du tout votre infrastructure. C'est le tissu conjonctif qui achemine le trafic vers votre porte d'entrée : le DNS. Tout semble sain jusqu'à ce que le trafic disparaisse. Les pannes DNS sont rarement évidentes car elles résident dans les couches situées entre votre utilisateur et votre périmètre. Voyons pourquoi cela se produit et comment vérifier votre pile de l'extérieur vers l'intérieur.

L'illusion de la disponibilité locale

La plupart des configurations de surveillance souffrent de „cécité de l'intérieur vers l'extérieur“. Vos services internes s'envoient des pings à l'aide d'adresses IP privées ou d'une résolution locale au VPC. Ils signalent une disponibilité de 100 % car, dans le jardin clos de votre fournisseur de cloud, they can communicate perfectly.

Mais du point de vue de votre utilisateur, naviguer vers votre site est un voyage en plusieurs étapes à travers l'annuaire de l'internet public. Si cette résolution échoue, votre tableau de bord de métriques internes restera joyeusement vert alors que vos revenus tomberont à zéro.

Plongée technique : La chaîne de résolution DNS récursive

To understand why DNS fails, you have to understand how it resolves. When a user types your URL, their device doesn't just "know" your IP. It starts a recursive journey across the globe:

1. Le résolveur Stub

Le système d'exploitation du client interroge le DNS configuré (généralement un FAI ou 1.1.1.1). C'est le „premier kilomètre“ du DNS.

2. Le résolveur Récursif

The ISP resolver checks its cache. If empty, it queries the Serveurs de Noms Racines for the TLD location.

3. Les Serveurs de Noms TLD

La racine pointe le résolveur vers les serveurs de noms .com ou .io. Ceux-ci sont gérés au niveau du registre.

4. Le Serveur de Noms Faisant Autorité

Enfin, la requête atteint votre fournisseur DNS (par exemple, Route53, Cloudflare). Ce n'est qu'alors que l'enregistrement IP final est renvoyé à l'utilisateur.

Chacun de ces sauts est un point de défaillance potentiel. Si vos serveurs faisant autorité perdent des paquets, les résolveurs récursifs peuvent expirer et renvoyer un SERVFAIL. Pire encore, si un serveur TLD contient des données obsolètes, votre trafic est envoyé dans le vide.

Modes de défaillance DNS courants en production

Les temps d'arrêt sont rarement causés par une seule défaillance. En matière de DNS, il s'agit souvent d'une séquence d'événements en cascade :

Mode de défaillance	Symptôme	Méthode de détection
Paralysie TTL	Correctifs mettent 24h+	Surveillance du Numéro de Série
Dérive d'enregistrement	Mauvaises IPs dans certaines régions	Vérifications Autoritatives Globales
Panne TLD	SERVFAIL global total	Validation Récursive Synthétique

L'incident DDoS de Dyn en 2016

En 2016, une attaque DDoS massive contre Dyn DNS (un fournisseur faisant autorité) a paralysé Twitter, Netflix et GitHub. L'attaque ne visait pas les entreprises, mais les serveurs de noms du fournisseur DNS. Résultat ? Les résolveurs récursifs du monde entier ne parvenaient pas à trouver la source faisant autorité, entraînant une cascade massive de SERVFAIL.

Comment déboguer les problèmes de résolution DNS

Lorsque vous suspectez un problème DNS, arrêtez d'utiliser votre navigateur. Vous devez parler directement aux sources faisant autorité. Voici le chemin de diagnostic standard :

Vérifier la réponse faisant autorité

Utilisez dig pour interroger directement vos serveurs de noms. Cela contourne toute mise en cache du FAI :

dig @ns1.your-dns-provider.com yourdomain.com A

Isoler le goulot d'étranglement avec trace

Utilisez dig +trace pour voir exactement où la chaîne de résolution se brise :

dig yourdomain.com +trace

Surveiller la latence et les erreurs DNS

Une pratique SRE mature exige la surveillance de signaux DNS de pointe. Validez la la latence p99 et les taux d'erreur depuis plusieurs points d'observation mondiaux :

Latence de résolution (P99) : Une latence élevée indique des problèmes de routage.
Taux de SERVFAIL : Des pics soudains signalent souvent une DDoS.

Renforcer votre infrastructure DNS

Traitez l'infrastructure DNS avec la même rigueur que votre base de données principal.

Conclusion

Le DNS est ennuyeux jusqu'à ce qu'il brise votre entreprise. Des outils comme Heimdall Observer existent pour détecter ces modes de défaillance avant qu'ils n'impactent vos utilisateurs finaux.