Publié dans Internet

6

Gandi revient sur sa panne DNS d’hier

Gandi revient sur sa panne DNS d’hier

Entre 15h26 et 15h48, « deux nœuds DNS sont tombés en panne », provoquant des erreurs lors d’une requête. L’incident n’a duré que 22 minutes, mais un post mortem a été mis en ligne, une transparence appréciable.

La cause principale de la panne est un « bug logiciel » ayant entraîné l’arrêt du serveur. Pour ne rien arranger, cette panne est arrivée en même temps qu’un « incident » sur un réseau interne de l’hébergeur. Ce dernier a causé « beaucoup de bruit dans nos systèmes de surveillance, conduisant à une mauvaise interprétation des alertes déclenchées par les serveurs DNS ».

De nouvelles procédures sont mises en place afin d’éviter que cela ne se reproduise. 

6

Tiens, en parlant de ça :

dessin satirique de Flock

#Flock : de Game of Shithrones au jeu des sept différences

Moi en retard ??? Non… (Ha si…)

13:37 Flock 13
Des chercheurs en noir et blanc regardent une fiole sur laquelle est écrit "Perlimpimpin" en jaune.

[Édito] Respectez les sciences, bordel !

Demi mole

17:07 NextScience 43
Vitrée brisée

Une faille critique dans le langage Rust, Windows trinque

De la rouille, des fenêtres, une rustine

17:02 SoftSécu 28
Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

6

Fermer

Commentaires (6)


La transparence du post morten est a saluer.



Cependant, pour l’incident, ça montre un manque de connaissance. Le design, qui est fait a tête reposé en amont de l’implémentation, est clairement mal fait:




  • L’anycasting BGP, c’est pour qu’une IP soit toujours dispo. Ca protège d’une merde “niveau 1” locale, comme un serveur qui crash par exemple, le copain a coté prend le relai.

  • Si on met plusieurs plusieurs NS pour un domaine, c’est pour couvrir une merde niveau 2, c’est à dire, quand on n’a mal gérer la merde de niveau 1 au niveau local, ou qu’on perd un datacenter. Le client sait qu’il peut taper sur un second serveur.



    Anycaster les 3 IPs depuis un même serveur, et je dirais même, depuis une même zone géographique, c’est une faute de design, pas un incident.



    Le DNS, c’est l’une des rangés de parpaing qui fait parti des fondations de l’Internet. Si ca tombe, y a juste plus rien qui fonctionne. Le DNS est justement un protocole super simple et basique, qui le rend donc super robuste pour cette raison. Vouloir faire de l’over-ingénieurie au dessus, c’est le fragiliser, et voilà ce qui arrive.


Le côté « positif » c’est que sur une aussi courte durée la plupart des résolutions ont du se faire au niveau des caches des FAI (ou autres 8888 ou 1111).








ForceRouge a écrit :



Anycaster les 3 IPs depuis un même serveur, et je dirais même, depuis une même zone géographique, c’est une faute de design, pas un incident.







Ou un incident provoqué par une erreur de conception.



Je dis erreur de design, tu dis erreur de conception. Pour moi c’est la même chose hein :)


Mon propos était plutôt sur la causalité. Nous sommes tous les deux d’accord sur le fait que la conception est discutable.



Ce qui me faisait tiquer, c’est le fait que tu estimes que ce n’est pas un incident mais un défaut de conception. Un défaut de conception peut être fonctionnel sans provoquer d’incident. Ce qui n’empêche pas de le corriger aussi avant qu’il n’en provoque. (l’erreur est humaine, constater l’ano avant qu’elle ne provoque des dégâts et dresser un plan d’action pour la corriger est la bonne démarche… L’inverse serait une bêtise par contre)

C’est sur ce lien de causalité que ma remarque portait, ou alors j’ai mal interprété.








SebGF a écrit :



Mon propos était plutôt sur la causalité. Nous sommes tous les deux d’accord sur le fait que la conception est discutable.



Ce qui me faisait tiquer, c’est le fait que tu estimes que ce n’est pas un incident mais un défaut de conception. Un défaut de conception peut être fonctionnel sans provoquer d’incident. Ce qui n’empêche pas de le corriger aussi avant qu’il n’en provoque. (l’erreur est humaine, constater l’ano avant qu’elle ne provoque des dégâts et dresser un plan d’action pour la corriger est la bonne démarche… L’inverse serait une bêtise par contre)

C’est sur ce lien de causalité que ma remarque portait, ou alors j’ai mal interprété.







Ah si si, il y a bien un incident, j’ai pas été très clair en faite. Ce que je dis, c’est que ce n’est pas juste un incident, c’est un vrai problème de design.



Ce que je veux dire, c’est que si le design est fait correctement, il ne peut pas y avoir d’incident autre qu’une erreur humaine sur une action d’admin ou bug logiciel. Dans le cas présent, le problème, c’est que by-design, l’architecture était vouée a avoir un incident, c’était juste une question de temps pour savoir quand est-ce que ça allait arriver.



Je viens de vérifier avec un mtr sur un domaine que j’ai chez eux en “live dns” et c’est toujours le cas. J’ai exactement la même latence et le même traceroute sur les trois serveurs… Peut être que les IPs sont maintenant annoncées depuis des serveurs différents, mais en cas de problème local sur le datacenter, un truc un peu batard comme de la grosse perte de paquet ou alors que la session BGP reste UP alors que les applis sont down,… ca peut retomber. Alors qu’avoir des DNS répartie sur plusieurs datacenter (ce qu’ils ont en plus), ca permet de se prémunir d’un problème local au datacenter.