- Le 16 avril 2025, plusieurs pannes de services Zoom ont commencé par un échec de résolution du domaine zoom.us, empêchant des clients aux États-Unis et à l’international d’accéder aux services
- L’incident a été signalé à 11:25 PDT et résolu à 13:12 ; les portails web de Zoom Meetings, Zoom Phone, Zoom CX et du site web Zoom ont été affectés
- Il n’y a eu ni panne interne des produits, ni incident de sécurité ou de réseau chez Zoom, ni attaque DDoS ; la cause était une erreur de communication entre Markmonitor et GoDaddy Registry
- Les utilisateurs déjà présents dans une réunion ou un appel Zoom Phone n’ont pas été affectés, mais les demandes de démarrage, participation et planification pouvaient échouer car elles nécessitent une résolution DNS
- Zoom, Markmonitor et GoDaddy ont supprimé le blocage côté serveur pour rétablir le service, et un registry lock a été appliqué au domaine zoom.us afin d’éviter une récidive
Portée et chronologie de l’incident
- L’incident a affecté l’accès à plusieurs services Zoom en raison d’un échec de résolution du domaine zoom.us
- Le problème de service a été signalé le 16 avril 2025 à 11:25 PDT et résolu à 13:12 PDT
- Des clients aux États-Unis et à l’international n’ont pas pu accéder aux services Zoom
- Services affectés :
- Zoom Meetings
- Portail web de Zoom Phone - Global
- Portail web de Zoom CX - Global
- Portail web du site web Zoom
Cause et processus de rétablissement
- Les serveurs de noms du domaine de Zoom répondaient normalement aux requêtes
- La cause réelle était un server block chez GoDaddy Registry, qui a rendu le domaine zoom.us indisponible
- Ce blocage est dû à une erreur de communication entre Markmonitor, le bureau d’enregistrement du domaine de Zoom, et GoDaddy Registry
- En conséquence, GoDaddy Registry a mis fin par erreur au domaine zoom.us
- Pendant l’incident, il n’y a eu ni panne interne des produits Zoom, ni incident de sécurité, ni incident réseau, ni attaque DDoS
- Les utilisateurs finaux déjà connectés à une réunion Zoom ou à un appel Zoom Phone n’ont pas été affectés
- Les opérations de démarrage de réunion, de participation et de planification nécessitaient une résolution DNS et ne pouvaient donc pas s’exécuter normalement
- Zoom, Markmonitor et GoDaddy ont identifié puis supprimé le blocage côté serveur afin de rétablir le service du domaine zoom.us
- Les enregistrements DNS étant mis en cache à plusieurs niveaux et assortis d’un TTL, quelques minutes supplémentaires ont été nécessaires après la réactivation du domaine pour que le changement se propage à l’ensemble de l’infrastructure Internet
Prévention de récidive et actions pour les utilisateurs
- GoDaddy Registry et Markmonitor ont appliqué un registry lock au domaine zoom.us pour éviter qu’un incident similaire ne se reproduise
- Ce verrou limite l’application de commandes de blocage serveur au domaine zoom.us
- Les utilisateurs rencontrant encore des problèmes de connexion peuvent vider leur cache DNS puis se reconnecter
- Windows :
ipconfig /flushdns - Mac :
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Windows :
1 commentaires
Avis sur Hacker News
La valeur du service de MarkMonitor semble avoir fortement diminué. MarkMonitor se présente comme « registrar accrédité par l’ICANN et leader du secteur depuis 1999 »
La raison pour laquelle on paie cher MarkMonitor, c’est justement pour qu’il ne commette pas ce genre d’erreur en gérant des domaines critiques ; GoDaddy n’aurait pas dû avoir la moindre marge pour s’en mêler ici
Si cela posait problème, il fallait vouloir un .com exploité par Verisign
En revanche, Apple utilise « Nom-iq Ltd. dba COM LAUDE », les entités de Meta utilisent RegistrarSafe, et Nvidia utilise SafeNames
Si le même problème était arrivé à une petite startup, j’ai l’impression que GoDaddy ne lui aurait même pas répondu
Par exemple, lorsqu’une adresse physique dans le pays concerné est requise, MarkMonitor peut s’appuyer sur ses bureaux dans plusieurs pays pour satisfaire cette exigence, puis vendre le domaine ccTLD au client
J’ai quelques doutes sur la légalité d’un tel montage, mais je ne suis pas juriste
Pour convaincre mon employeur de l’époque d’abandonner Zoom, j’ai voulu voir combien de failles de sécurité je pouvais trouver en 2 à 3 heures
Avec seulement binwalk et des informations de sources publiques, j’ai trouvé 12 bugs vérifiés dans ce laps de temps ; le plus grave était que l’adresse e-mail de réinitialisation du mot de passe du compte GoDaddy de zoom.us était le compte Gmail personnel d’Eric S Yuan, le CEO
En tentant une réinitialisation du mot de passe Gmail, il n’y avait pas d’authentification à deux facteurs, seulement deux questions de réinitialisation — ville natale et numéro de téléphone — auxquelles les réponses se trouvaient dans des sources publiques, ce qui permettait d’obtenir un lien de réinitialisation et d’aller jusqu’au contrôle du domaine zoom.us
Je n’ai trouvé personne dans l’équipe sécurité capable d’expliquer la situation en anglais, et il a fallu 3 mois à Zoom pour confirmer le tout et verser un bug bounty total de 800 dollars
Au moins, cette affaire a permis de convaincre mon employeur d’abandonner Zoom
Cela devait être au tout début, quand Zoom commençait à peine à devenir populaire
GoDaddy est une organisation tellement incompétente qu’on ne devrait jamais la laisser gérer quoi que ce soit d’important
C’est précisément pour éviter ce genre de situation qu’on paie très cher MarkMonitor, et MarkMonitor aurait dû avoir un interlocuteur dédié chez GoDaddy ainsi qu’un canal de communication direct
Même si GoDaddy a traité la demande autrement que prévu, c’est aussi une grosse erreur du côté de MarkMonitor
Il y a quelques années, j’ai utilisé un domaine de premier niveau .us, mais j’ai fini par conclure qu’il ne fallait pas laisser mon domaine dépendre d’un code pays
C’est aussi pour cette raison que je n’utilise pas .io
Cela ne veut pas dire que ce genre de chose est impossible avec des domaines de premier niveau génériques, mais pourquoi confier ainsi sa marque aux mains d’un gouvernement ?
Dans ce cas, .eu pourrait être un meilleur candidat, mais il suffit de demander aux anciens propriétaires britanniques de domaines comment cela s’est passé
Les domaines de premier niveau génériques ne font qu’ajouter une couche supplémentaire d’incompétence, celle de l’entreprise qui les exploite, et le gouvernement du pays où se trouve cette entreprise peut toujours intervenir
Par exemple, .nl n’est pas non plus géré par des fonctionnaires du gouvernement néerlandais : si je me souviens bien, il est exploité par une organisation à but non lucratif lancée par quelques personnes dans les années 80
Les domaines de premier niveau « génériques » comme .com relèvent de toute façon de la juridiction américaine
Rien n’est encore décidé, mais il n’y a aucune raison de vivre avec une telle incertitude au-dessus de la tête
Comme je vis ici et que je compte y rester, utiliser un domaine national de premier niveau pour me représenter, moi et mon travail, me paraît tout à fait adapté
.com lui-même relève de la juridiction américaine et est exploité par Verisign
C’est à cause de ce genre de risque que Fastmail a acheté fastmail.com et a migré depuis son ancien domaine fastmail.fm
.fm était sympa, mais ils ont subi plusieurs pannes des serveurs .fm qui les ont mis hors ligne ; depuis le passage à .com, ils n’ont plus eu ce genre de problème
C’est surprenant de voir autant de pannes de service liées au fait de traiter avec GoDaddy
GoDaddy a racheté l’activité registre de Neustar en 2020, pendant que tout le monde avait l’attention ailleurs
Je ne suis pas client et je n’ai pas l’intention d’acheter un domaine à l’étranger, et je n’ai pas d’avis arrêté sur GoDaddy, à part que je n’aime pas son nom
J’ai entendu beaucoup d’histoires effrayantes, mais je me demande aussi si ce n’est pas une réaction réflexe immédiate
Il faudrait que les clients Zoom appellent des domaines de deuxième et troisième niveau, et que les registrars comme l’infrastructure d’hébergement soient diversifiés
Ce serait bien aussi d’avoir des adresses IP anycast de secours pour la découverte de service
Vu ce que paient des entreprises comme la mienne, on peut attendre ce niveau de préparation technique, et il est encore temps de corriger cela
#HugOps aux employés qui gèrent la crise en heures sup
Si le CEO de Zoom disait « nous aimerions recevoir des crédits SLA pour la panne mondiale que votre entreprise a provoquée », GoDaddy répondrait probablement : « Désolés. Nous pouvons vous offrir une fois un coupon de 10 dollars de réduction lors de votre prochain achat ou renouvellement. »
La plupart des entreprises espèrent qu’un simple appel Zoom d’excuses suffit à fidéliser les clients, et en pratique ça marche généralement
On n’a pas assez traité l’ampleur de l’asymétrie entre les crédits SLA et l’impact sur le chiffre d’affaires lors d’une panne d’un fournisseur donné, ni la façon dont cela devrait peser dans les décisions build vs buy
Pour y parvenir, cela signifierait qu’en temps normal, quand tout fonctionne, la marge serait très faible
Un SLA est plus utile comme moyen de sortir d’un contrat long terme avec un fournisseur peu fiable que comme compensation du chiffre d’affaires perdu lors d’une panne
GoDaddy est médiocre depuis des années, et le fait qu’ils aient bloqué l’API ACME sauf pour leurs plus gros clients a été, pour moi, le point de non-retour
Je ne leur ferai jamais confiance
Si c’est ce que l’on veut, il suffit d’acheter auprès d’un assureur une police sur mesure pour cet incident et de payer un coût annuel similaire
Et dans le build vs buy, ce que l’on construit soi-même est souvent moins bon que ce que l’on achète
Un produit acheté est continuellement corrigé grâce aux rapports de bugs de clients du monde entier, alors qu’un outil interne est rarement stress-testé à ce point et endurci sur le terrain
Il semble qu’il se soit passé quelque chose du côté de MarkMonitor. Ils ont peut-être signalé zoom.us à tort comme une usurpation de marque, déposé une plainte pour atteinte au droit d’auteur auprès de GoDaddy, qui opère le domaine de premier niveau .us, et GoDaddy aurait suspendu le domaine à la suite de cette plainte
Si MarkMonitor avait été mentionné sans aucun autre lien, la théorie de la plainte pour droit d’auteur aurait été plus plausible
Quand cette panne est survenue, j’ai d’abord pensé qu’ils avaient enfin effectué la « transition » et que quelque chose avait mal tourné
J’ai aussi entendu dire qu’aujourd’hui le compte Twitter @zoom_us avait été supprimé
Les signalements de violation du droit d’auteur peuvent être, et sont effectivement, détournés sur GitHub, YouTube, etc.
Depuis quand la présomption de culpabilité est-elle devenue la norme sociale ?
GoDaddy n’est pas l’État, mais ce n’est pas acceptable
Un humain aurait pu regarder le domaine trois secondes et voir qu’il s’agissait d’un faux positif et qu’il ne fallait pas le supprimer
Analyse de la panne par ThousandEyes : https://www.thousandeyes.com/blog/zoom-outage-analysis-april...
Par exemple, il explique ce qu’est le DNS, mais pas pourquoi la panne s’est produite ; il se contente de fournir une chronologie avec un contexte utile pour quelqu’un qui est encore en train d’apprendre ce qu’est le DNS et comment il fonctionne