Zoom.usドメインの「無効化」によるZoomサービス障害

 (status.zoom.us)
1 ポイント 投稿者 GN⁺ 2025-04-18 | 1件のコメント | WhatsAppで共有
  • 2025年4月16日に発生したZoomの複数サービス障害は、zoom.usドメインの名前解決失敗に端を発し、米国および海外の顧客がサービスにアクセスできなくなった
  • 障害はPDT 11:25に報告され、13:12に解決された。Zoom Meetingsと、Zoom Phone・Zoom CX・Zoom WebsiteのWeb Portalが影響を受けた
  • Zoom内部の製品・セキュリティ・ネットワーク障害やDDoS攻撃はなく、MarkmonitorとGoDaddy Registry間のコミュニケーションエラーが原因だった
  • すでに会議やZoom Phone通話に参加していたユーザーは影響を受けなかったが、開始・参加・予約のリクエストはDNSルックアップが必要なため失敗する可能性があった
  • Zoom、Markmonitor、GoDaddyはserver blockを解除して復旧し、再発防止のためzoom.usドメインにregistry lockを適用した

障害の範囲と時間

  • 障害はzoom.usドメインの名前解決失敗により、複数のZoomサービスへのアクセスに影響を与えた
  • サービス問題は2025年4月16日午前11:25 PDTに報告され、午後1:12 PDTに解決された
  • 米国および海外の顧客がZoomサービスにアクセスできなくなった
  • 影響を受けたサービス:
    • Zoom Meetings
    • Zoom Phone - GlobalのWeb Portal
    • Zoom CX - GlobalのWeb Portal
    • Zoom WebsiteのWeb Portal

原因と復旧プロセス

  • Zoomのドメインネームサーバーはリクエストに正常に応答していた
  • 実際の原因はGoDaddy Registryのserver blockで、zoom.usドメインが利用できない状態になった
    • このブロックは、Zoomのドメイン登録機関であるMarkmonitorとGoDaddy Registry間のコミュニケーションエラーによって発生した
    • その結果、GoDaddy Registryが誤ってzoom.usドメインを停止した状態になった
  • 障害中、Zoom内部の製品障害、セキュリティ障害、ネットワーク障害、DDoS攻撃はなかった
  • すでにZoom会議やZoom Phone通話に参加していたエンドユーザーは影響を受けなかった
  • 会議の開始、参加、予約の操作はDNSルックアップが必要なため、正常に完了できなかった
  • Zoom、Markmonitor、GoDaddyはserver blockを特定して解除し、zoom.usドメインサービスを復旧した
    • DNSエントリは複数の階層にキャッシュされ、TTLが設定されているため、ドメイン再有効化後にインターネットインフラ全体へ伝播するまでさらに数分かかった

再発防止とユーザー側の対応

  • GoDaddy RegistryとMarkmonitorは再発防止のため、zoom.usドメインにregistry lockを適用した
    • このロックは、zoom.usドメインにserver blockコマンドが適用されることを制限する
  • 接続問題が残っているユーザーは、DNSキャッシュをクリアした後に再接続できる
    • Windows: ipconfig /flushdns
    • Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

関連記事

1件のコメント

 
GN⁺ 2025-04-18
Hacker News の意見

  • MarkMonitor のサービス価値が大きく下がったように見える。MarkMonitor は自らを「1999年からの ICANN 認定レジストラであり業界リーダー」と宣伝している
    MarkMonitor に高い金を払う理由は、重要なドメインを扱ううえでこういうミスをしないようにするためであって、ここで GoDaddy が入り込む余地はないはずだった

    • GoDaddy Registry が .us レジストリを運営しているので、.us ドメインは GoDaddy の関与なしには持てない
      それが嫌なら、Verisign が運営する .com を望むべきだった
    • 大手テック企業がどのドメインレジストラを使っているのか気になって Whois を調べてみたところ、Microsoft、Google、Amazon、Tesla、Netflix、Shopify はすべて MarkMonitor を使っていた
      一方 Apple は「Nom-iq Ltd. dba COM LAUDE」、Meta 系は RegistrarSafe、Nvidia は SafeNames を使っている
    • MarkMonitor に金を払う理由は、結局のところ GoDaddy に連絡して問題を解決できる能力にあるのかもしれない
      同じ問題が小さなスタートアップで起きていたら、GoDaddy はそもそも相手にもしてくれなさそう
    • GoDaddy が .us の ルート DNS を運用している
    • MarkMonitor のもう一つの価値は、直接満たすのが難しい条件のある 国コードトップレベルドメイン（ccTLD） にアクセスできるようにする点にある
      たとえばその国の実住所が必要な場合、MarkMonitor は複数の国にオフィスを置いてその要件を満たしたうえで、顧客に ccTLD ドメインを売ることができる
      こうした仕組みの合法性は少し疑わしいが、法律の専門家ではない

  • 当時の雇用主に Zoom をやめるよう説得するため、2〜3時間でセキュリティ脆弱性をいくつ見つけられるか試してみることにした
    binwalk と公開情報だけで、その時間内に確認済みのバグを12個見つけ、最も深刻だったのは zoom.us の GoDaddy アカウントのパスワード再設定メールが Eric S Yuan CEO の個人 Gmail アカウントだったことだ
    Gmail のパスワード再設定を試すと2段階認証がなく、出身地と電話番号という2つの再設定質問だけで済み、公開資料から答えを得て再設定リンクを受け取り、zoom.us ドメインの制御権にまで到達できた
    英語で説明できるセキュリティチーム担当者を一人も見つけられず、Zoom がこれを確認して合計800ドルのバグバウンティを支払うまでに3か月かかった
    それでも、この件のおかげで雇用主は Zoom をやめることになった

    • これがいつの話だったのか気になる。数年前には Zoom は米国でセキュリティチームの人員を積極採用していて、専任のファジングチームも募集していた
      Zoom が人気を得始めた初期の頃だったのだと思う
    • 今、重罪を犯したと認めているのか？

  • GoDaddy はあまりにも無能な組織なので、重要なものを管理させてはいけない

    • GoDaddy を責めるのは簡単だが、コミュニケーション不全は双方がいて初めて起きる
      こういうことが起きないよう MarkMonitor に大金を払っているのであり、MarkMonitor は GoDaddy に専任担当者と直接の連絡チャネルを持っているべきだった
      GoDaddy が依頼と違う処理をしたとしても、これは MarkMonitor 側の大きなミスでもある
    • Hooters の店員みたいな格好をした女性たちが出てくる広告を出していた会社が、最終的に完全なピエロ車になるとは誰が想像しただろうか

  • 数年前に .us トップレベルドメインを使ったことがあったが、結局、自分のドメインを国コードに依存させてはいけないと判断した
    .io を使わない理由も同じだ
    ジェネリックトップレベルドメインでこういうことが不可能という意味ではないが、なぜ自分のブランドをそんな形で政府の手に委ねるのかと思う

    • どのトップレベルドメインであっても、一国の法律から自由ではない。.aq や .su くらいか？
      この条件では .eu のほうがより良い候補かもしれないが、かつての英国ドメイン所有者にそれがどうなったか聞けばよい
      ジェネリックトップレベルドメインは、運営会社という無能な層を追加するだけで、その会社が所在する国の政府も依然として介入できる
      たとえば .nl もオランダ政府の公務員が運営しているのではなく、記憶では80年代に数人が始めた非営利組織が運営している
    • Zoom は米国に法人を置き、従業員の大半も米国にいるので、すでに米国政府の影響下にある
      .com のような「一般」トップレベルドメインも、どうせ米国の管轄に入る
    • .io を避けたのは運が良かった。.io は廃止されるリスクすらある
      まだ決まったわけではないが、そんな不確実性を頭上に抱える必要はない
    • 自分の政府であるカナダはおおむね信頼しているし、.ca ドメインは WHOIS 情報がデフォルトで隠されているので良い
      ここに住んでいて今後も住むつもりなので、自分と自分の仕事を表すのに国別トップレベルドメインを使うのは合っていると思う
    • 文字どおりすべてのトップレベルドメインは、何らかの政府の管理下にある
      .com 自体も米国の管轄であり、Verisign が運営している

  • こうした可能性があるため、Fastmail は fastmail.com を購入し、以前の fastmail.fm ドメインから移行した
    .fm は格好よかったが、.fm サーバーの障害を何度か経験してオフラインになり、.com に移ってからはそうした問題はなかった

  • GoDaddy と取引していると発生するサービス障害がこれほど多いのは驚きだ

    • Zoom が zoom.us ドメインを取得した時点では、おそらく Neustar が .us レジストリを運営していたはずだ
      GoDaddy は、誰もが別のことに気を取られていた2020年に Neustar のレジストリ事業を買収した
    • 障害数を顧客数で割ってもそう見えるのか気になる
      私は顧客でもなく、海外でドメインを買うつもりもなく、GoDaddy については名前が嫌いという以外に確固たる考えはない
      怖い話はたくさん聞いたが、これが即時の反射反応なのかも気になる

  • Zoom クライアントが呼び出す側にはセカンドレベル・サードレベルドメインを置き、レジストラとホスティングインフラも多様化すべきだ
    サービス発見用の予備のエニーキャスト IP アドレスまであってもよい
    うちの会社のようなところが払っている費用を考えれば、その程度のエンジニアリング上の備えは期待できるし、今からでも直せばよい
    夜通し対応している従業員たちに #HugOps

    • ステータス確認ホストも zoom.us ドメインの中にあった点が特にもどかしかった

  • Zoom の CEO が「御社が引き起こした世界規模の障害について SLA クレジットを受け取りたい」と言ったら、GoDaddy は「申し訳ありません。次回の購入または更新時に使える 10 ドル割引クーポンを 1 回差し上げられます」と答えそう
    ほとんどの会社は、謝罪の Zoom 通話を 1 回すれば顧客維持には十分であってほしいと願っており、実際にもたいていはそれで通る
    特定ベンダーの障害における SLA クレジットと売上への影響の非対称性がどれほど大きいか、そしてそれを内製か購入かの判断にどう反映すべきかは、十分に論じられていない

    • SLA クレジットが失われた売上のかなりの部分を補填するように最適化することは、望まない可能性が高い
      そうするには、平常運用時の利益率がほとんどないという意味になる
      SLA は障害で失った売上を補填するというより、信頼できないベンダーとの長期契約から抜け出す手段としてのほうが有用
    • Zoom ほどの規模のサービスがなぜ GoDaddy を使っているのか分からない
      GoDaddy は何年も前からひどく、上位顧客でなければ ACME API をブロックするというやり方が、自分にとっては決定打だった
      絶対に信用しない
    • Zoom が落ちていたら、謝罪の Zoom 通話もできない
    • 対称性を取るなら、ドメイン更新費用は 20 ドル程度ではなく、賠償金を負担できるように数百万ドルであるべき
      それを望むなら、保険会社からその事故向けのオーダーメイド保険を買い、同程度の年間費用を払えばよい
      内製か購入かについても、自作したものは買ったものより悪いことがしばしばある
      購入した製品は世界中の顧客からのバグ報告で継続的に修正されるが、社内ツールがそれほどストレステストされ、実戦で鍛えられることはまれ
    • CrowdStrike の障害時にスターバックスのクーポンを提案していたのを覚えている。そういう流れなのだろう

  • MarkMonitor 側で何かが起きたように見える。zoom.us をブランドなりすましとして誤って表示し、.us トップレベルドメインを運営する GoDaddy に著作権侵害の申し立てを行い、GoDaddy がその申し立てに従ってドメインを停止した可能性がある

    • あり得る話ではあるが、MarkMonitor は Zoom のレジストラなので、MarkMonitor と GoDaddy の間のコミュニケーションミスがこのような結果を生む経路はほかにも多い
      MarkMonitor が言及されているのに他の関連性がまったくないなら、著作権侵害申し立て説のほうがもっともらしかっただろう
    • 記憶違いかもしれないが、Zoom.us が Zoom.com に置き換えられる予定だという自動サービスメールを受け取った覚えがある
      今回の障害が起きたとき、ついに「移行」したものの何かが失敗したのだと思った
      今日 @zoom_us の Twitter アカウントも削除されたという話を聞いた
    • これが事実なら、このような自動化された削除措置を拒むべき非常に明確な例だ
      GitHub や YouTube などでは、著作権侵害の申し立てが悪用され得るし、実際に悪用されている
      いつから社会的に有罪推定がデフォルトになったのかと思う
      GoDaddy は政府ではないが、これは受け入れられない
      人間がドメインを 3 秒見れば、誤検知であり削除してはいけないと分かったはずだ

  • ThousandEyes による障害分析: https://www.thousandeyes.com/blog/zoom-outage-analysis-april...

    • 記事には事実が多く並んでいるが、実際に何が起きたのかは説明していない
      例えば DNS とは何かは説明するが、障害がなぜ発生したのかは説明せず、DNS とは何でどう動くのかをまだ学んでいる人に役立つ文脈とともに時系列だけを提示している
    • .us のようなドメインへのすべての DNS クエリが、実際のネームサーバーに到達する前に単一のルートレジストリを経由するという点を、まったく知らなかった