Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !
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 commentaires
Avatar de ForceRouge INpactien
Avatar de ForceRougeForceRouge- 17/07/20 à 11:43:30

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.

Édité par ForceRouge le 17/07/2020 à 11:45
Avatar de Totoxoros INpactien
Avatar de TotoxorosTotoxoros- 17/07/20 à 12:37:18

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).

Avatar de SebGF Abonné
Avatar de SebGFSebGF- 18/07/20 à 08:06:47

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.

Avatar de ForceRouge INpactien
Avatar de ForceRougeForceRouge- 18/07/20 à 18:34:17

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

Avatar de SebGF Abonné
Avatar de SebGFSebGF- 18/07/20 à 22:23:30

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é.

Avatar de ForceRouge INpactien
Avatar de ForceRougeForceRouge- 19/07/20 à 06:58:02

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.

Il n'est plus possible de commenter cette actualité.