Product
Panne de l’API de Mailgun : post-mortem d’août 2016
Cet article a été initialement publié le 12 août 2016.
Résumé
Le 4 août à 22 h 20 UTC, Mailgun a été alerté de nombreux rapports d’échec de résolution DNS pour notre nom de domaine mailgun.net, qui est le nom de domaine principal que nous utilisons pour notre API. En commençant nos recherches, nous avons découvert que notre domaine avait été placé sous le statut « client hold » par notre bureau d’enregistrement de noms de domaine, Dynadot.
À 22 h 47 environ, Dynadot a réactivé le domaine et nous avons commencé à constater une augmentation du trafic vers notre domaine api.mailgun.net. Les niveaux de trafic n’ont pas atteint les seuils normaux avant 23 h 17 en raison du cache négatif des enregistrements DNS.
Détails
Une fois notre équipe alertée du problème à 22 h 20 UTC, nous avons commencé le dépannage en confirmant que nos serveurs de noms faisant autorité répondaient toujours correctement aux requêtes DNS. Nous avons confirmé que notre infrastructure DNS backend était à la fois fonctionnelle et correctement configurée, puis nous avons commencé à examiner la configuration de notre domaine avec notre bureau d’enregistrement, Dynadot.
Nous avons découvert que notre domaine avait été placé sous le statut « client hold », ce qui empêche la résolution DNS normale. Il n’y a eu aucune communication récente, ni au préalable ni juste avant que Dynadot ne prenne cette action punitive contre notre domaine.
Notre équipe d’ingénierie a immédiatement tenté de contacter le support de Dynadot par le biais de leur système téléphonique et de leur support par chat en direct. Pendant toute la durée de cet incident, nous n’avons pas pu joindre leur équipe de support technique par téléphone. Un message préenregistré informait l’appelant que tous leurs agents de support étaient occupés et qu’il fallait essayer d’appeler plus tard. Nous avons réussi à joindre un agent via leur système de chat, qui nous a informés qu’ils ne pouvaient pas résoudre le problème et que, pour lever le blocage, nous devions envoyer un e-mail à leur équipe de support. L’agent de support a insisté sur le fait que ce serait le seul moyen disponible pour nous de résoudre le problème. Pendant ce temps, nous avons également demandé à être appelés par un manager et avons tenté de faire remonter le problème, mais aucune option supplémentaire pour le résoudre ne nous a été proposée.
À 22 h 37, nous avons envoyé un e-mail à leur équipe de support et notre domaine a été réactivé environ dix minutes plus tard, à 22 h 47. Bien que le domaine ait été réactivé, nous n’avons reçu aucune autre communication de Dynadot avant le vendredi à 00 h 12 UTC, indiquant que le domaine avait été désactivé suite à des plaintes pour spam, sans toutefois recevoir la moindre information correspondante pour étayer cette affirmation.
Nous avons demandé à ce que ce problème soit remonté à un membre de leur équipe de direction et à recevoir des détails sur les plaintes reçues. Nous n’avons reçu aucun détail supplémentaire et, jusqu’à présent, nous n’avons parlé à personne de leur équipe de direction à propos de cet incident.
Actions et leçons tirées
Notre relation avec Dynadot existe depuis 2010, ce qui précède l’acquisition de Mailgun par Rackspace. Bien que nous ayons historiquement eu peu de problèmes dans la gestion de nos domaines, cet incident, et surtout l’incapacité d’obtenir des retours rapides de la part de Dynadot, ont rendu nécessaire un changement de fournisseurs de services. À ce jour, nous avons terminé la transition vers le service d’enregistrement de domaines d’entreprise de Rackspace. Ils fournissent un service en continu et contribueront à garantir que des problèmes similaires ne se reproduisent plus. Bien que nous ayons transféré notre relation commerciale, nous restons ouverts aux discussions avec Dynadot à propos de ce problème, dans l’espoir que leurs politiques et procédures puissent être mises à jour afin d’éviter de causer des problèmes à d’autres clients légitimes à l’avenir.
